No, That's Not a Software Factory — Ryan Cooke, WorkOS

The familiar software-factory recipe is straightforward: put a repository in a sandbox, add a coding agent, give it a prompt, and merge the resulting pull request. Ryan Cooke, an engineer at WorkOS, opens with that recipe because it leaves an important question unanswered: does the organization actually deliver more useful software?

Counts of pull requests, percentages attributed to AI, and quantities of generated code describe production activity. They do not establish that the activity advances a customer outcome. More pull requests can make an automation system look successful while leaving the harder question—whether features reach customers sooner—unresolved. That distinction matters when building the factory itself consumes engineering time and potentially a dedicated team.

WorkOS’s ambition is to give each engineer something like a small engineering team. The consequence should be observable in delivery: more features shipped, with complex work completed faster. Cooke’s account offers qualitative experience and proposed success measures rather than numerical delivery or reliability results; it explains the design and its intended benefits without establishing their magnitude.

WorkOS began with a sandbox built on Cloudflare, a model router, and prompts. The disappointing result was how ordinary it felt. Cooke found the outcomes pretty indistinguishable from engineers driving coding agents on their laptops. Moving execution into a sandbox had not, by itself, removed enough of the surrounding work to change product delivery.

The next design question was how to put WorkOS’s engineering processes inside the factory. Engineers do more than write code: they organize projects and carry work through the steps needed to produce a product. Automating those steps required the system to participate in the tools where that work already happened.

That led to two parts with different responsibilities:

• TARS: The interface to the coding agent lives in Slack, Linear and GitHub. It also subscribes to webhooks so it can track project progress alongside its code work.
• Horizon: The infrastructure orchestration layer sits in front of an internal MCP gateway. It provides the execution infrastructure, while the gateway connects the agent to organizational tools and context.

A dependency between Linear tickets gives the factory a plan it can follow. One ticket blocks another; completing the first changes which work can proceed. Because TARS receives ticket-completion webhooks, it can pick up the next ticket automatically. Planning therefore supplies both the units of work and their execution order, reducing the need for a person to issue a fresh prompt at every handoff.

The plan can also change as implementation reveals gaps. Between completed tickets, an engineer can ask TARS to reevaluate the Linear project and identify missing work. This is a separate operation from advancing to the next ticket: advancement follows the existing plan, while reevaluation checks whether the plan still covers the project’s goal.

What connects a finished ticket to continued execution, and where can the plan be reconsidered? The diagram separates those paths. The completion event drives the next handoff; an intervening request can send TARS back to the project plan to look for gaps. The useful autonomy comes from reacting to project state, rather than treating each coding session as an isolated task.

At WorkOS, engineers carry many product responsibilities; Cooke says teams do not have product managers. Their planning ritual is a Hilltop document, a product requirements document that gathers the project’s purpose, customer needs, competitive analysis, early designs and major milestones. Consolidating those inputs gives an agent a coherent resource from which to break the project into units of work.

The PM agent automates the first pass through that ritual. A brief specification becomes a draft Hilltop; the agent adds context, reads human reviews, and breaks implementation into tickets. Humans can comment on generated tickets and refine the work throughout the process. Approval is also an event the factory understands: once the Hilltop has been reviewed and approved through Linear, the system can begin the project automatically.

The concrete example is a new API for Vaults, a product Cooke leads. He starts the project with a Slack command and a few sentences describing the goal. TARS creates the Linear project, a draft Notion document, and first passes at decision logs and open questions. The observable change is from a short request to an organized set of project resources that the lead engineer can immediately edit.

Cooke then adds specifications and fills in poorly defined areas using his knowledge of the project. The example is still awaiting its Hilltop review: completing that review ticket will let TARS detect the change and move to the next implementation stage. The review is therefore doing two jobs. It improves the product definition, and its recorded completion tells the automation when work may advance.

The benefit is partly the familiar “blank page problem.” Cooke reports that teams are doing more project-brief and Hilltop work because the agent seeds the information. The drafts can grossly overestimate a project’s scope, requiring engineers to cut substantial portions. The tradeoff is deliberate: reviewing and trimming an existing draft can be easier than creating every project primitive from scratch. Work then continues through Slack and Linear toward GitHub pull requests.

The resulting project documents are useful beyond WorkOS’s own coding agent. Engineers can point Devin at the same tickets and documentation, or let a local coding harness retrieve the material through MCP. Security colleagues can also join the project channels and weigh in. The planning work remains useful even when a different agent performs implementation.

WorkOS calls its internal MCP gateway a “context engine.” Connecting tools is only part of its job. It also builds system prompts and context that explain when to use a tool, how to navigate it, and how WorkOS organizes information inside it. Those descriptions give an agent a starting map rather than merely a list of available operations.

Snowflake makes the mechanism concrete. It is WorkOS’s main data lake, with semantic tables describing product utilization and customer conversations. The MCP tool description can list those tables, explain their contents, and direct the agent to query the appropriate tables for a particular type of question. The query still has to be written; the gateway supplies the organizational knowledge needed to choose where to write it.

How does one gateway serve both software implementation and internal analysis? The diagram shows the shared connection: multiple agent-facing workflows use the same tool access and navigation guidance. WorkOS opened the MCP server to Slack queries for data and customer analysis, then began building other internal tools on it. That reuse is why Cooke recommends investing early in a gateway that explains both the tools and the company’s information organization.

The same event-driven approach extends beyond planned features:

• Bug requests: TARS listens through webhooks to requests arriving in Slack, takes a first pass at triage, and can implement fixes and open pull requests.
• Customer support: Shared customer Slack channels provide support requests. TARS can inspect the code to help identify where a customer may be encountering a product problem.

WorkOS is also using TARS to build its own sandbox infrastructure. The motivation for moving away from some sandbox services is deeper control over session information and the ability to move workloads among parts of its infrastructure. Owning that layer becomes relevant when the factory needs to inspect how work happens, rather than simply launch an agent and collect its output.

The next planned component is a company-wide memory layer: continually useful context about what people are working on, their teams, the products they own, and how WorkOS does its work. The intended consumers include both the factory and other AI tools. This is a proposed expansion of shared organizational context, with no completed memory implementation described in the talk.

The closing measurement discussion returns to customer impact. Shipping faster is valuable only if the products remain dependable, and a tool that engineers voluntarily choose offers a different signal from one that merely generates activity. Cooke identifies three areas to watch:

• Delivery and customer impact: Does the factory help useful work reach customers?
• Reliability: Track defect rate and time to recovery to watch for instability introduced by the new workflow.
• Voluntary adoption: Look for engineers choosing TARS and cloud sandboxes over their local harnesses. Cooke treats this as an anecdotal indication that the system helps them work.

Infrastructure visibility is meant to feed a further improvement loop. Agents could examine sessions to find gaps in how engineers use the factory, identify mistakes that call for a new skill, and recognize skills that have become obsolete as the code changes. A skill written six months earlier may no longer fit the current code. Better code generation and better engineering practice are goals of this loop, rather than demonstrated self-improvement results.

“Sandboxes are great.” Opening a pull request is useful. WorkOS’s larger aim is to encode the engineering practices that carry a project from intention through planning and execution. The Vaults example makes that ambition concrete: a Slack brief creates resources, an engineer refines them, a review ticket records approval, and TARS can react to that event to continue the project.

Cooke ends with an unresolved question: authorization. WorkOS has not yet figured out how it should handle authorization for this factory, and he asks other builders how they approach it. That limits what the workflow demonstrates. Approval events can coordinate when work advances, but the talk does not supply a settled model for who may authorize the agent’s actions across its connected systems.