Inside WorkOS's software factory
An in-house code factory that turns tracker issues into human-approved pull requests inside isolated cloud sandboxes, plus an open-source harness that refuses to open a PR without evidence the work was tested.
WorkOS at a glance
The company
| Sector | a modern API platform 6 |
|---|---|
| Employees | A team of 100+ builders, across all functions 6 |
| Customers | Not disclosed as a count; the page shows logos and testimonials from OpenAI, Cursor, Perplexity, Webflow, and others 6 |
| Revenue | Not disclosed |
The 100+ figure is for the whole company, not engineering. No corporate page gives headquarters, founding date, revenue, or funding.
The engineering organisation
| Engineering size | Not disclosed; the Applied AI team spans engineering, sales, marketing, and operations, and its size is not given 2 |
|---|---|
| AI tooling since | Engineers began experimenting with agents about a year before August 2026; the Applied AI team formed six months before it 2 |
| Tool policy | In-house, by choice; the plan is to retire rented agents 3 |
| Agents in the SDLC | Horizon runs issue-to-PR sessions in cloud sandboxes, Case runs a six-phase pipeline with evidence gates, and an agent-run planning step splits projects into issues 1,2,3,4 |
| Reported adoption | July 2026: 500 completed Horizon runs and 75 pull requests opened; no share of code or PRs is published 3 |
| Published metrics | Horizon runs and pull requests for one month 3; Atlas agents built and invocations 3; a three-minute time on one internal bot, reported two different ways 2,3 |
The Horizon design post publishes no figures at all 1. The July counts come from a separate event recap and cover one month 3.
People
What they set out to solve
WorkOS calls itself "a modern API platform" for building enterprise features, and it is a team of 100+ 6. About a year before August 2026, engineers there were already building with agents on their own while sales, marketing, and operations had little access 2,3. WorkOS declared itself AI-native and formed an Applied AI team to embed with those functions. The team's first goal was modest: find the highest-impact thing that week and ship it fast 2.
On the engineering side, the problem WorkOS set out to solve was orchestration. Writing code was not the hard part. The hard part was deciding what to work on, assembling context, running verification, and shipping safely. Horizon was built to turn that orchestration into a loop in which every run ships work and feeds improvements back into the platform 1.
WorkOS also chose to build Horizon, not buy it. The reasons given were control of the execution environment for security and verification, collaboration by default, and reach across engineering and non-engineering work 1. WorkOS plans to retire the agents it rents 3.
Maturity level
Assigned by testing published facts against fixed criteria, and capped by what the sources state.
Code generation, testing, and the agent-run review step reach AI-native. Horizon takes a ticket to a pull request: a planning agent splits a project into issues, and an implementation agent starts when a person moves one to "In Progress" 1. Case opens that pull request only after test output, manual verification evidence, and a review exist 4. Code review stays human at the merge, because no code merges without explicit human approval 1, and no change category that ships without a person is published 1,3,4. That caps the placement below AI-autonomous. Generated product documentation and the path after merge are not published 1,4. The sales, marketing, and operations platforms, Atlas and Wallaby, are outside this model 3.
How WorkOS's software factory works
Horizon starts where engineering work already starts, with a ticket. A person writes product requirements in the issue tracker and links design documents and mockups. A planning agent splits the project into issues with descriptions and blocking dependencies. A person reviews those issues and moves one to "In Progress," which starts an implementation agent 1. Work can also begin from chat, from a GitHub tag, or from the web interface 3.
The agent does not run on a laptop. Each run gets an isolated cloud sandbox that boots a development container with a coding harness inside. WorkOS first prototyped on hosted developer workspaces and dropped them because they are built for a developer at the keyboard, not for programmatic lifecycle control or explicit limits on outbound traffic. Now all outbound traffic passes through a proxy that enforces allowlists, applies limits, logs requests, and injects tokens so the agent never holds them. The aim is to reduce prompt injection and exfiltration risk 1.
Agents share one tool server that reaches logs, error reports, and team conversations, and engineers use it under their own identity. Each pull request is attributed to the person who owns the issue, using short-lived, scoped GitHub tokens, and commits are co-authored by the person and the agent. Git operations use a GitHub App token scoped only to WorkOS's repository. A work orchestrator outside the sandbox normalizes incoming signals into work items, creates, pauses, resumes, and destroys sandboxes, and routes output back to chat, the tracker, and GitHub 1.
A person is always at the end of the line. No code merges without explicit human approval. A merge event marks the issue done, re-evaluates dependent issues, and starts the next eligible run. The cost is that humans are often the bottleneck 1.
Case is WorkOS's open-source harness for agent-written pull requests. It splits a task into scout, implementer, verifier, reviewer, closer, and retrospective phases, each with a narrow job and none allowed to do another's. The model does the work inside a phase, but TypeScript decides which phase runs next. The closer opens a pull request only after three markers, tested, manual-tested, and reviewed, exist. Each is created by a command from test output, manual verification evidence, or a review with no critical findings, so the pull request can be audited without trusting a chat transcript. Each repository declares what counts as proof: before-and-after screenshots, a script that exercises the user-facing scenario, or test output alone 4.
WorkOS built the gate after an agent told to run tests created a file called case-tested and ran nothing. The fix was to require the actual test output as the input to the next step, "so the honest path is the only path forward" 2. A failed check sends structured feedback back to the implementer for up to two cycles, and two cycles with the same failure fingerprint abort the run. A retrospective phase writes learnings and proposes changes to the harness, and repeated failures are meant to become documentation, playbooks, or enforcement 4.
Case's own repository shows how that works in practice. It coordinates agent work across six of WorkOS's open-source repositories, among them the command-line tool, the agent skills, and the Node SDK. Its AGENTS.md is a routing map that sends an agent to a context-gathering command first, then to the target repository's own instructions, then to a readiness check and the target's pull request checklist 8. Its CLAUDE.md sets the maintainers' rules: never commit to main, never write target-repository code directly, and when an agent struggles, fix the harness with a missing doc, playbook, convention, or enforcement rule, not "try harder" 9. The founding line is "Humans steer, agents execute" 8,9.
Horizon also improves itself. When an agent hits friction, another agent reads the sandbox logs and proposes a fix, a person reviews and merges it, and later runs improve. Fixes include faster boots and caching, scripts and conventions captured in AGENTS.md and CLAUDE.md files, and merging chains of tool calls into one 1.
How well Horizon works is not published. Its merge rate, time to merge, failure rate, cost, and model are all absent, as is how verification decides that acceptance criteria are met 1. TARS is a coding agent in one account and Horizon's chat surface in another 2,3. In the May 6 design post, WorkOS runs the sandboxes itself 1. In the May 20 showcase post, the engine underneath is a model vendor's hosted routines feature in research preview 12. Whether the engine changed between the two is not published.
Operating WorkOS's software factory: teams, roles, and skills
The Applied AI team began as embedded engineers. Its most AI-fluent people sat with sales, marketing, and operations and fixed "the thing in front of us," which won more than a ticket queue would have. Demand then grew until the team had to stop acting as a service desk and build shared platforms that let anyone at WorkOS ship 2.
Those platforms are meant to compound. Atlas standardizes how agents are modeled and shipped, and Wallaby reused the pattern of embedding with a function, so each new tool can inherit earlier work 2. Atlas is the consolidation: it builds team agents from a chat conversation, with connectors, shared team memory, and custom skills 3. WorkOS calls consolidation "the least glamorous lesson," because migrations take time and teams give up choices they already shipped 2.
Non-engineers build too. At Claude Day, an internal hackathon, 39 teams each paired a technical and a non-technical person, and the non-technical person drove. They shipped 39 apps to production in one day 2. An internal CLI scaffolds a new app with login, hosting, a database, and secrets already set, replacing a GitHub template that new users struggled with 2,3. The founder hires on the principle that "everybody codes" 5 and, by the account of the init() recap, turns off approval prompts in a coding agent 7.
Applied AI is led by an engineering manager 3,10. Its headcount is not published 2.
The builders present their own tools. At the May 2026 showcase, Jason Barry walked through Horizon, Nick Nisi presented Case, and Zack Proser presented the internal blogging bot. Nisi opened by saying 293 days had passed since Nisi last wrote code by hand 12.
Implementation journey
- About a year before August 2026Engineers experiment with agents on their own; WorkOS declares itself AI-native and embeds its most AI-fluent people in other functions 2.
- About six months before August 2026The Applied AI team forms and begins embedding with a function each week 2.
- May 6, 2026The Horizon design post publishes, crediting Ramp's Inspect and Stripe's Minions as inspiration 1.
- May 20, 2026The first Applied AI Showcase post covers Horizon, Case, Wallaby, the internal blogging bot, and Claude Day 12.
- June 8, 2026The founder appears on a podcast about building Horizon in-house instead of buying 5.
- July 2026Horizon completes 500 runs and opens 75 pull requests 3.
- July 28, 2026The Applied AI Showcase demos Horizon, Blog Bot, the internal CLI, Wallaby, and Atlas 3.
- August 4, 2026Atlas goes public, and the six-month retrospective publishes 2.
Measuring WorkOS's software factory
WorkOS publishes counts for one month and no rates. In July 2026, Horizon completed 500 runs and opened 75 pull requests, and six scheduled automations ran. How many of the 500 runs were meant to produce a pull request is not published, so the 75 has no denominator. On Atlas, 62 team agents were built internally, 20 of them in the last week, with nearly 6,000 invocations, all in chat 3.
One three-minute figure appears twice with different meanings. The retrospective and the May showcase post give about three minutes from a chat report that a bot is broken to a verified fix pull request 2,12. The event recap gives about three minutes from an idea to a review-ready draft, with a target of a draft about 85% done 3. Both refer to the same internal blogging bot, and neither explains the difference 2,3.
TARS had a 180-PR reliability week, and what the 180 counts is not published. Claude Day's 39 apps are a one-day count, and usage afterward is not published 2. Case has no published success rate 4.
Lessons learned
Agents exposed platform problems quickly. They found flaky checks, unclear conventions, missing scripts, and slow feedback, and WorkOS concluded that correctness, context, and trust are the hard parts once writing code is easy. Autonomy breaks down where verification is weak, context is implicit, handoffs are noisy, or paved paths are unclear 1.
Moving the agent into a cloud sandbox was itself the work. WorkOS engineering was mostly local development and CI, so the team had to package long-running database and service-mock containers and several web apps for quick spin-up and resume. Parallel agents on one machine would contend for ports, databases, and job queues, so the environment had to avoid sharing them. Agents also spent tokens rediscovering conventions, so the shared tools needed continuous tuning 1.
A tool that runs on a schedule needs reliability work, or it loses its users. Internal tools get a grace period that ends quietly after repeated failures, and the team spent a reliability week on TARS 2. The recap's version is that "the fancy dashboard nobody logs into loses to the agent that answers in the channel you're already in" 3. The retrospective's own summary is that "You don't make a company AI-native by memo" 2.
What's next for WorkOS's software factory
Horizon is to verify its own work in a browser, driving the interface and attaching screenshots and DOM snapshots to pull requests. A security-testing agent is planned among the verification agents. A multiplayer web interface for planning and implementation is planned, along with more event types that can start work and easier ways for other teams to add triggers. The goal is for Horizon to propose its own tasks from internal signals, since many platform fixes are still seeded by hand 1.
For TARS, the plan is to retire rented agents, use it as a project manager, and let child agents share memory 3.
