Context-Driven Factories

Software factories are the frontier of agentic software development. They promise a compounding development process that gets cheaper, faster, and better every week. But most teams struggle to build factories that deliver these compounding outcomes. Their buildout stalls, or the gains are merely incremental.

We have seen this pattern before. When coding agents first arrived, it was suddenly 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. Factories are following the same path. The tempting move is to dive straight into automation, but we regularly see this fail for three reasons:

1. Workflows defined in code are brittle and cannot improve as stronger models ship.
2. Knowledge is siloed and improvements in one workflow don't benefit others.
3. Tooling comes before process design, so the team never buys in.

Our answer is context-driven factories, a method centered on defining your team’s workflows and standards in plain files that run on simple, transparent infra. This post describes what that looks like, why the common alternative struggles, and how to start.

Context-driven factories in action

A context-driven factory has two principles designed to keep decision-making out of code, let knowledge flow across tools, and make business context easy to collaborate on across the team.

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, but it does not sit in the outer loop deciding how the agent progresses through the task or what it is allowed to see.

Every workflow and standard lives in a plugin. Those plugins are checked into your repos and shared between projects with a context registry. Read a plugin and you know how the factory works. Change a plugin and you have changed the factory.

Once your team starts capturing their workflows and standards in skills, you automate them with loops. A loop is a skill you have deployed to run automatically, one that improves over time as it runs. A factory composes skills and loops into a full agentic SDLC. This path has become a mantra at Tessl: from
skills, to loops, to factory.

Context-driven factories make this journey easier for two reasons. Plain context files are easy for an agent to read and change safely, so the self-improvement step is tractable and loops can run with more autonomy. And because context is portable and reused across surfaces, loops collect signal from everywhere a skill is used and distribute improvements equally broadly.

Below, we show a context-driven factory across the three main factory surfaces:

• Ticket to PR flows
• Agentic code review
• General automations

From ticket to PR

Implementing a ticket is an ambiguous task that requires a large amount of judgment. A feature may touch one repo or three. A large change may be better shipped as a couple of stacked PRs. A copy fix should skip the heavyweight review. Engineers absorb these variations without thinking about them, and a factory has to model the same ambiguity.

Zoom

In a context-driven factory, the ticket-to-PR workflow is a set of skills:

Zoom

When someone delegates an issue to the factory, there is no extra logic or magic routing. 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, pr-shepherd takes over in the same shape: resolve CI, address review, merge when the criteria are met. When exceptions arise, the agent can handle them gracefully.

Code review

Good code review makes all your engineers better. Review is where a team's standards get applied most sharply, and if those learnings don’t disseminate across your SDLC, your factory will never compound.

Zoom

In a context-driven factory, this sharing is the default, since your code review standards live in skills that can be reused elsewhere. Add a code-review plugin and point the review entry point at it.

Zoom

Note that the design system, brand guidelines, and company brain are not in the repo. They are dependencies, resolved from the Tessl registry. Design owns the design system and publishes it. Every project that needs it declares a dependency and gets 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. This 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.

Automations

Some work runs on a schedule or trigger outside of the ticket-to-PR flow:

Zoom

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 workflow change in a pull request, and the team can debate it there before it is enforced. The process belongs to the team and is easy to review as a team.

Simple, transparent infrastructure

Context-driven factories require less infrastructure, since most of the work is an exercise in creating and improving plugins. The infrastructure that remains (sandboxes, secrets, the scheduler, etc.) is invisible, because it carries no logic.

Put it together and the whole factory is a few plugins, versioned in git or tracked as dependencies from your context registry. Because the factory is driven by skills, it’s easy to change without “breaking the factory”. Because every loop is just a skill in the repo, it’s easy for the factory to optimise itself as it runs. And because skills are portable, what one loop learns is reused by every other loop that uses those skills.

Zoom

How most people build factories, and why they fail

Most factories start from a different instinct. Engineers reach for code first, because code is what we know and it feels like the predictable choice. The bias is toward building fast and getting something working, so the slower work of writing the process down and agreeing on it with the team gets skipped. Each of the three failures below traces back to that.

Workflows defined in code are brittle

Every workflow has ambiguity. Any rule enshrined in deterministic code turns out to have exceptions, and code handles them badly. Worse, guardrails that were prudent for one model generation become an invisible straitjacket for the next, and nobody goes back to remove scaffolding that is not visibly failing.

The ticket-to-PR flow shows both problems. It almost always gets modelled as a pipeline with code at the core. Code pulls the repo and runs setup. An agent is handed the task, often tightly locked down in what it can access and do. Code pushes the PR. Webhooks fire specific agent tasks: fix CI, respond to review. After some gate, code merges the branch.

But this pipeline quickly becomes a mess of exceptions and special cases. Big features touch multiple repos. One ticket needs stacked PRs. A trivial copy change deserves a lighter review. Each one becomes a branch in the pipeline, and the pipeline hardens around whatever the models could do when it was written.

Context-driven factories default to adaptability. The agent reads the process and exercises judgment, and it gets efficiency and determinism from the tools it calls rather than from a pipeline deciding on its behalf. Context drives the work and tools are helpers, as they are for humans, not the other way around.

Knowledge is siloed

Today's SDLC works because the engineer who reviews a PR brings that same knowledge to their own development. Agents break that flow, since a different agent picks up every task and is gone when it finishes. Tools with memory features help, but they hold their learning in private state. A review tool that has learned your preferences reviews better, but your PRs do not arrive any cleaner.

Those shared learnings are the flywheel a factory has to produce, and the payoff is large. When review learnings feed back into generation, PRs arrive correct the first time. That means fewer implementation rounds and cheaper, lighter review. The same standards can then power maintenance agents that sweep the codebase on a schedule and catch the drift that slips through any individual PR. Teams that do not close this loop face a hard future: engineers burning out under the volume of agent PRs, or falling behind competitors who have made this process compound.

Context-driven factories solve this by keeping standards in plugins that every surface reads. Review, generation, and maintenance agents draw on the same files, so learnings in one place cascade everywhere automatically.

Tooling comes before process design, preventing team buy-in

Nearly every factory buildout starts with infra and tools. Wiring a few things together and watching workflows run feels like a superpower. But this approach scatters decisions and business context across tools, trapped in configuration screens, or hidden in glue code only half the team understands. There is nowhere to lay it out so the team can say yes, this is how we do this.

We learned this lesson on our own GTM team. Someone built a set of automations that crawled customer calls, generated insights, and fed them into a chain of other tools to drive prioritisation. Nobody knew exactly how the insights were generated, so whenever people disagreed they dismissed the process. The impact was limited because the team had never been brought on board. When we decided to rework the process, the policy lived in a scatter of prompt text boxes that were hard to collaborate on, and other automations relied on its output, so we were migrating a pipeline rather than editing a document.

We corrected this by 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, and the pipeline shrank to a scheduler around that file. Disagreements now improve the skill instead of discrediting the process.

Skills, to loops, to factory

Everything above comes down to structure: workflows and standards written down as plugins, shared across every tool, and agreed on by the team before they are enforced. With that structure in mind, the remaining question is how to get started. Our answer is the mantra “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, you just need 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 evolve to be more agent-native.

Context-driven factories make this natural. The skill you run by hand is a single click to deploy. But automation is the payoff at the end of the effort, not the starting point. 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.