What we learned in six months of making AI the default at WorkOS

Six months ago we stood up an Applied AI team at WorkOS with a deliberately modest charter: embed with a function, find the highest-impact thing that week, and ship it fast. We skipped the roadmap and the service catalog. The plan was to get close to real work and make something useful.

That charter didn't survive contact with demand. The same small team now runs a platform that spans engineering, sales, marketing, and operations, and this is what we learned on the way.

Get close to the work first

The team came out of something we noticed rather than something we planned. About a year ago, engineers across WorkOS started experimenting with agents on their own. We took the hint: we declared WorkOS AI-native, pulled together a small group of our most AI-fluent people, and sent them to sit directly alongside sales, marketing, and operations. Their mandate was to find the highest-impact problem that week and ship something.

Sitting inside a function changes what you build. Our early wins came straight out of that proximity: a Slack chatbot living in customer channels, and a vector-backed chat platform built on top of sales call transcripts. Neither would have come from a team taking tickets from a queue. They came from watching people work and fixing the thing in front of us.

Demand outran us

Embedding works until it works too well. Requests piled up faster than a small team could take them, and the obvious failure mode was becoming a service desk that hands out AI tools one at a time. So the goal shifted from being a service to making AI the default capability across WorkOS. In practice that meant building the platforms and substrate that let anyone at the company ship.

The best example is wow, our internal CLI, which we demoed live at our Applied AI Showcase in July. wow machine setup installs the boring stuff so a new hire's laptop is ready to ship, and wow app create scaffolds an app with opinionated defaults already baked in: AuthKit for login, Cloudflare Workers for hosting, SQLite per app, Doppler for secrets, and a GitHub Action that ships on merge. The name comes from our company value, "earn the wow". The point of the tool is that the least technical person at the company never has to think about any of that stack.

The day non-engineers shipped 39 apps

The test of this new method of working is whether people who aren't on your team can successfully ship to production, regardless of their technical background. We ran that test directly with Claude Day, a one-day internal hackathon where 39 teams each paired a technical and a non-technical person, and the non-technical person drove. They shipped 39 apps to production in a single day.

That only works because the setup cost was already zero. The first git push deployed a live app at a their-app-name.workos.tools URL, already wired with a Cloudflare Workers backend, a D1 database, R2 for images, and zero-trust auth. People learned the stack because they needed it. They picked up concrete details, like the difference between Slack bot tokens and user tokens, because their app didn't work until they understood it. No onboarding doc teaches like that, and it is how adoption spreads: one working app at a time.

Every tool becomes a pattern for the next one

The compounding value showed up when we stopped building individual tools and started building patterns other tools could inherit.

Horizon, our internal code factory, is an event-driven system triggered by webhooks. It spawns long-running agent sessions in secure Cloudflare cloud sandboxes, and every pull request is attributed to the human who owns the Linear issue via WorkOS Pipes, which keeps git blame clean. We built it in-house because environment, security, and WorkOS-specific context are the product, and its architecture is modular so components can be swapped as the tooling market shifts. Its best property is that it dogfoods itself: running in production surfaces where the platform is brittle, and those papercuts (a missing script, a flaky test, an unclear convention) become the next inputs to the same factory.

Wallaby, our go-to-market intelligence tool, came out of embedding with the GTM org. It runs structured enrichment workflows plus a Slack-native agent that triggers them from natural language. Same embedding pattern, different function; our showcase writeup shows it working.

Consolidating the fleet onto Atlas

Shipping fast across five functions leaves you with a fleet of tools that each solved their problem their own way. Every one carries its own plumbing: identity, deploys, memory, the Slack wiring. That cost is invisible for the first few tools and then it is the only thing you work on.

The answer was Atlas, our agent platform. It runs a fleet of team agents that live in Slack, and it standardizes how an agent is modeled, given a Slack identity, and shipped. Wallaby quickly moved onto it.

Consolidation is not free. Every migration spends time you would rather put into new work, and it asks a team to give up choices it already made and shipped. We still think it is the right trade, because the alternative is paying the plumbing tax on every tool forever. It is the least glamorous lesson of the six months and probably the most valuable: the one-offs proved what was worth standardizing, and the platform is what keeps the pace sustainable. Atlas went public on August 4, and it was the closing demo at the showcase.

Make the agent unable to lie

The hardest engineering lesson was about trust. Case, our coding harness, is a TypeScript state machine wrapping six specialized agents (scout, implementer, verifier, reviewer, closer, retro), and it's open source at github.com/workos/case. The lesson underneath it: the agent doesn't have to be trustworthy, it has to be unable to lie. Told to "run tests before proceeding," an agent would happily touch a file named case-tested without running anything. The fix was structural. Require the actual test output as the input to the next step, so the honest path is the only path forward.

That principle generalizes past coding agents. Any step that can be faked eventually will be, so design the workflow so the artifact each step produces is the proof it actually ran.

Reliability goes on the calendar

Internal tools get a grace period. Once people depend on them the period ends, and it ends quietly: usage just stops when a tool burns someone twice.

TARS is the Slack surface for our code factory: react to a message with the TARS emoji, a webhook fires, and Horizon handles the rest, using Cloudflare KV as an identity map between the Slack user, the AuthKit user, and the routine's permalink. Convenient, and also a lot of moving parts sitting between a person's intent and a merged PR. We ran a 180-PR reliability week on TARS to work through them.

Budgeting a week of concentrated reliability work for one internal agent sounds excessive until you count what depends on it. Adoption must be earned, and the tool has to stay worth reaching for.

Meet people where they already are

A year and a half ago, nearly the same backend behind our Blog Bot launched as a standalone web app and went nowhere, because a login screen stood between the user and any value. The same backend in Slack, triggered by a six-word request, works. Shift the interface, not the stack.

That logic keeps paying out as the surfaces multiply. Horizon's MCP server is now available on Claude.ai through enterprise-managed auth, so the context an agent needs reaches people in the assistant they already have open, with no separate tool to adopt and no separate credential to manage. Horizon also grew a web UI for its memory, on the same reasoning: what a long-running agent remembers should be something a human can open and read, not reverse-engineer from its behavior.

Meeting people where they are also tightens the feedback loop. For BlogBot, the average time from "this doesn't work" reported in a Slack channel to a verified fix in a PR is about three minutes: Claude reads the channel, files a Linear issue, fixes a subtask, deploys a preview, writes its own test messages, verifies, and asks for a merge.

Six months in

You don't make a company AI-native by memo. It took substrate that makes the first step free, patterns that compound instead of piling up, workflows that can't fake their own results, and reliability treated as scheduled work. The team that started by embedding with one function now shows up across engineering, sales, marketing, and operations, because the tools we built are things people reach for on their own.

The habit we'd keep above all the others is the one we closed our showcase on: ask yourself every week what's possible this week that wasn't possible last week. The models can already do more than we're asking them to.