A software factory promises a development process that gets cheaper, faster and better every single week. Most teams building one never see that curve. Their buildout stalls, or the gains stay incremental instead of compounding.
The industry has seen this pattern before. When coding agents first arrived, it suddenly became easy to crank out features, and just as easy to end up with slop. The teams that got real value learned to separate planning from implementation, and to write down the context an agent needed before letting it build. Context-driven software factories apply that same lesson at the scale of the whole organization. Instead of encoding workflows in pipelines, you define them in plain files that run on simple, transparent infrastructure.
The loop, the harness and the factory
It helps to be precise about what a factory actually is. The atom of agentic work is the loop, one agent doing a single job on repeat. Gather context, take an action, check the result, go again. Around each loop sits a harness, the sandbox, tools, memory and gates that decide what done means. A software factory, as Addy Osmani frames it, is many harnessed loops running at once, fed by a queue of work and drained through review into production.
Every engineering organization already runs this loop in human form. Work flows from plan to build to production to feedback, and production informs the next round. What changed is that agents can now do meaningful work at nearly every phase. The question is no longer how fast an individual engineer moves through the loop. The question is how well the loop itself is designed. That design is exactly where most factory builds go wrong.
Why code-first factories stall
Most factory buildouts start from the instinct to automate immediately. Tessl, which has written extensively about this pattern, sees three recurring failures, and each one traces back to skipping the slower work of writing the process down and agreeing on it as a team.
Workflows defined in code are brittle
Engineers reach for code first because code is what they know. The ticket-to-PR flow almost always gets modelled as a pipeline. Code pulls the repo and runs setup. An agent receives the task, tightly locked down. Code pushes the PR. Webhooks fire specific agent tasks to fix CI or respond to review.
But every real workflow carries ambiguity. A big feature touches three repos. One ticket needs stacked PRs. A trivial copy fix deserves a lighter review. Each exception becomes a branch in the pipeline. Worse, guardrails that were prudent for one model generation become an invisible straitjacket for the next, and nobody removes scaffolding that is not visibly failing. The pipeline hardens around whatever the models could do on the day it was written.
Knowledge stays siloed
Today’s software development lifecycle (SDLC) works because the engineer who reviews a PR brings that same knowledge to their own development. Agents break that flow. A different agent picks up every task and disappears when it finishes. Memory features inside individual tools help, but they hold their learning in private state. A review tool that has learned your preferences reviews better, yet your PRs do not arrive any cleaner.
The payoff for closing this gap is large. When review learnings feed back into generation, PRs arrive correct the first time. That means fewer implementation rounds and cheaper, lighter review. Teams that never close the loop face engineers burning out under a flood of agent PRs, while competitors make the same process compound.
Tooling comes before process design
Nearly every factory buildout starts with infrastructure. Wiring tools together and watching workflows run feels like a superpower. But decisions and business context end up scattered across configuration screens and glue code only half the team understands. There is nowhere to lay the process out so the team can look at it and say yes, this is how we do this.
Tessl learned this on its own go-to-market team. Someone built automations that crawled customer calls, generated insights and fed them into a chain of tools to drive prioritization. Nobody knew exactly how the insights were generated, so whenever people disagreed they dismissed the process entirely. The fix was rebuilding it as a context-driven automation. The policy moved into a skill in the repo, where anyone can read it and propose a change in a pull request. The pipeline shrank to a scheduler around that file. Disagreements now improve the skill instead of discrediting the process.
The two principles of a context-driven factory
Context-driven factories keep decision-making out of code, let knowledge flow across tools and make business context easy to collaborate on. Two principles do the heavy lifting.
First, workflow definition lives in context, not code. The agent reads a description of the job and what good looks like, has the tools it needs and decides what to do next. Code is still present as scripts, CLIs and MCP tools the agent can call. It just never sits in the outer loop deciding how the agent progresses through a task or what it is allowed to see. Context drives the work and tools are helpers, exactly as they are for humans.
Second, every workflow and standard lives in a plugin. Plugins are checked into your repos and shared between projects through a context registry. Read a plugin and you know how the factory works. Change a plugin and you have changed the factory.
On top of those principles sits a simple vocabulary:
- A skill is a workflow or standard captured in a plugin, written in plain language.
- A loop is a skill deployed to run automatically, improving each time it runs.
- A factory composes skills and loops into a full agentic SDLC.
Three surfaces of a context-driven factory
From ticket to pull request
Implementing a ticket is an ambiguous task that demands judgment. A feature may touch one repo or three. A large change may ship better as a couple of stacked PRs. A copy fix should skip the heavyweight review. Engineers absorb these variations without thinking, and a factory has to model the same ambiguity.
In a context-driven factory, that workflow is a set of skills. When someone delegates an issue, an agent starts with the triage-issue skill loaded. The skill describes how this team triages, what to look at, what questions to answer and which sibling skills to move to next. Once a PR exists, a skill like pr-shepherd takes over in the same shape. Resolve CI, address review, merge when the criteria are met. There is no magic routing layer, and exceptions get handled gracefully because the agent can read the process and exercise judgment.
Code review as a shared standard
Review is where a team’s standards get applied most sharply. If those learnings never spread across your SDLC, the factory will never compound. In a context-driven factory, sharing is the default because review standards live in skills that get reused everywhere.
The design system, brand guidelines and company brain do not live in the repo. They are dependencies resolved from the registry. Design owns the design system and publishes it, and every project that needs it declares a dependency and receives the current version. When review keeps flagging a spacing pattern and the design system’s guidance gets fixed, the next implementation gets it right the first time. Review improved generation without anyone wiring the two together, because they were reading the same file all along. That is a loop in its simplest form, a skill that gets better every time it runs, with the improvement landing everywhere the skill is used.
Scheduled loops
Some work runs on a schedule or trigger outside the ticket flow. Changelogs, flaky test sweeps and drift checks belong here. A schedules entry in tessl.json turns a plugin into a loop. Anyone can open the skill to see how a changelog gets written or what counts as a flaky test. Anyone can propose a change in a pull request and the team can debate it there before it is enforced. The process belongs to the team and stays easy to review as a team.
Why context compounds where code cannot
The compounding comes from two properties of plain files. They are easy for an agent to read and change safely, so the self-improvement step is tractable and loops can run with real autonomy. And because context is portable and reused across surfaces, loops collect signal from everywhere a skill is used and distribute improvements just as broadly.
The stakes are concrete. Verification is the real constraint on any factory, since autonomy can only expand as far as you can cheaply and reliably verify output. Cortex’s benchmark data shows pull request throughput and incident volume rising in close step at organizations that automated generation without upgrading their controls. Shared written standards attack exactly that problem, because every agent and every human checks work against the same bar. The infrastructure that remains, sandboxes, secrets and the scheduler, stays invisible because it carries no logic. The whole factory becomes a few plugins, versioned in git or tracked as registry dependencies.
From skills to loops to factory
Do not try to build everything at once. Start with one or two workflows. Write the process and the standards down as skills, run them by hand and adjust until the team trusts the output. Your team is probably already doing this informally, so the job is to curate the good skills lying around. Then close the loop on that workflow and let it run and evolve. Expand from there as your processes become more agent-native.
Context-driven factories make this path natural. The skill you run by hand is a single click to deploy. Automation is the payoff at the end of the effort. The starting point is a skill your team trusts.
A factory that outlives its models
The durable value in a factory is a legible, versioned, portable record of how your organization builds software, one that gets a little better every time the factory runs.
There is an older lineage worth noting. The context-driven school of software testing argued decades ago that the value of any practice depends on its context, and that good practices exist in context while best practices do not. Context-driven factories make the same bet at the scale of the whole SDLC. A pipeline carved into code freezes your process at the capability of the models that existed when you wrote it. A factory written in plain context inherits every model improvement for free, reads the same files your team reads and improves exactly where your team decides it should.
