WorkOS Applied AI Showcase July 28 2026 - Moving to an AI-native Organization

Half of WorkOS was already shipping with AI. The other half was rewriting emails in a chat window and waiting in line for engineering help. On July 28 we put the people who closed that gap on stage at our New York office for the Applied AI Showcase: five internal tools — Horizon, Blog Bot, the wow CLI, Wallaby, and Atlas — each with a live demo, given by the person who built it.

You can watch the full event recording below:

Why this team exists

Michael Grinich opened with the uneven distribution problem. Some engineers were already building with AI. Marketing, sales, finance, operations, and recruiting had almost none. He asked a recruiter how they were using AI and the answer was rewriting emails in a chat window. That same recruiter now builds their own sub-agents inside our systems. The Applied AI team formed to embed with the non-engineering functions and turn their workflows into agents and systems.

All of this runs on the identity, security, compliance, and integration infrastructure WorkOS has been building for years, which turns out to be the same infrastructure AI needs.

The rules we set for the room

Eight to twelve minutes per talk, a live demo in every talk, slides allowed but light on text, and one joint Q&A after all five.

Horizon, and the coding agent called TARS

Sherry Ali, engineering manager for Applied AI, opened. The team had been leaning on rented coding agents and couldn't see inside any of them. When a run got stuck, debugging meant staring at a black box. Project Horizon was the decision to own the identity, the tools, and the infrastructure instead.

The agent that came out of it is TARS. It takes a message in Slack, an assignment in Linear, a GitHub tag, or a tag in the web UI, and pushes out a pull request. Runs happen in resumable sandboxes on isolated containers, so a broken run restarts instead of starting over, and internal tools reach the sandbox over MCP, which is where the team draws the line on what the agent can touch.

The demo was debugging a production incident. Sherry asked TARS to root-cause it with access to Datadog and the Horizon repository, and got back a verdict, the evidence behind it, and the relevant pull requests. The web UI shows the whole trail: which tools the run called, and how it reached the answer. TARS also has a watch mode that monitors a channel and starts an investigation whenever someone asks a question there. It lives in our triage channels.

The numbers from July: 500 completed runs and 75 pull requests opened, plus six scheduled automations running inside TARS. It also works on itself: it reads the feedback the team leaves on its runs, kicks off a triage agent, reviews its own work in a second sandbox, and opens a PR for a human to merge. Next up: retiring the rented agents, using TARS as a project manager that plans and sequences work, letting it spawn child agents, and giving those agents shared memory across runs.

Blog Bot drafts the post, a human still clicks publish

Zack Proser demoed Blog Bot, which lives in Slack for an unglamorous reason: the earlier version was a separate app with its own login, and that one extra step killed it. The target is a natural-language request in a channel people are already in, and a draft that's roughly 85% done for a human to review.

He described the thing as an editorial pipeline rather than an autocomplete pipeline. The artifact has to be grounded in sources of truth. Blog Bot reads GitHub, Slack, Linear, YouTube, and the open web, then writes to the CMS, generates cover art and inline images through a custom image model, and comments back on Linear. Then come the gates: cited facts checked for hallucinations, a voice check, every link verified to return a 200, a check against over-praising a competitor, secret scanning with GitGuardian, and a fidelity check against the original ask.

The plumbing: v2 runs on an open-source agent framework that lets you pick your deployment target, on Cloudflare, using Durable Objects and Workflows. Every change writes a new version to D1, which exists because someone once lost a draft they were working on. The AI gateway is bring-your-own-key, so no secrets sit in application code. A watchdog notices the system failing mid-run and restarts it so drafts survive.

The publish gate is the part Zack called non-negotiable. Drafts stage themselves. Going live requires a human to review and click publish, or to ask for it explicitly, and the bot never publishes on its own. Edit an approved draft and it needs another approval. Average time from idea to review-ready draft is about three minutes.

Live, on stage, he asked it to punch up a title and to generate an image of a unicorn eating a bowl of rubies using the voice interface.

The wow CLI, because chatting isn't shipping

Megan Spaulding's talk started with a complaint about the phrase AI-native, which in most companies means the engineers are AI-native. Non-engineers at WorkOS were mostly chatting with models, and got stuck the moment they needed a database, a local dev environment, hosting, or a deploy. At that point their only option was to ask the Applied AI team and wait their turn.

The first fix was a GitHub template wired up with Cloudflare and Wrangler config, so someone could copy it and get databases, jobs, workers, hosting, and deploys from square one. Watching people use it surfaced the real friction: they didn't know what cloning meant, the git environment wanted an SSH key, local dev was its own day of work, and skipping the rename script clobbered shared Cloudflare resources.

wow is what replaced it: the WorkOS internal CLI, named after our "earn the wow" operating principle, and the thing that took non-engineers from ideas to shipped tools. Megan didn't put an adoption number on wow itself, but the ceiling showed up at the San Francisco edition, where the team described Claude Day — a one-day internal hackathon of technical and non-technical pairs that shipped 39 apps to production.

Wallaby

Jacobia Johnson demoed Wallaby, the umbrella for our go-to-market automations and AI tooling. After embedding with the BDR team, we found three problems worth solving: workflows living in people's heads instead of systems, answers scattered across seven tabs of tooling, and none of it reachable from where people actually work. Wallaby answers all three — deterministic enrichment and list-building workflows, go-to-market data aggregated into one queryable place, and a REST API exposed as a dashboard, over MCP to tools like Claude, and (of course) in Slack.

In the live demo, Wallaby cross-referenced an enrichment run against our top-500 strategic accounts, looked up account ownership for support routing, and spun up a dinner event — pulling invitees from that night's attendee list and attaching the Salesforce campaign — all from a few Slack messages.

Atlas

Sherry closed the night with Atlas, our agent builder. Wallaby took multiple repos, hundreds of pull requests, and months of dedicated engineering time — and once teams saw it, everyone wanted a Wallaby of their own. Atlas collapses that build cycle into a Slack conversation: describe the agent you want, and it wires up connectors to systems like Snowflake, Notion, and Linear (including internal tools people have built themselves), gives it multiplayer memory your whole team can teach, and lets you add custom skills and even a custom face. In the demo, Sherry spun up "Wallaby Jr.," a go-to-market data analyst, taught it a new behavior with a single message, and had it querying accounts from Snowflake minutes later — no deploy required.

It even flagged that a similar agent already existed before creating the new one. 62 team agents have been built internally across every function, 20 created in the last week alone, and nearly 6,000 invocations were run— 100% of them in Slack.

The lesson we kept repeating on stage: the fancy dashboard nobody logs into loses to the agent that answers in the channel you're already in.

We're hiring on the Applied AI team and across the company. Open roles are here.