Harnesses, Loops and Factories

At first, the teams we work with asked Claude or Copilot to fix a small bug or write a test. Then they gave agents tools to debug production systems, so the agent could track down the cause of a failure and propose the fix itself. Now some leave an agent working towards a goal for several hours before anyone looks at the result. We've watched teams make that whole journey and the next step is to scale it up. At that point the team's job changes and they become responsible for designing the system of work that agents operate within and the guard rails around it.

The harness

An agent is basically a model plus the harness and tools around it. The harness governs how the model can act: the tools it can call, the context it is given about the codebase and the task and the limits on what it may touch. The first coding assistants were a more advanced form of autocomplete - they saw the file you had open and could offer the next few lines. Claude Code, Copilot's agent mode and Cursor gave the model a terminal, the test suite, the logs and a set of permission rules so it can make a change, run it and see whether it worked.

The harness is where most of a team's effort goes today. The decisions around what the agent can access, what it is allowed to change and when to hand back to a person. That work keeps its value as models change because the tools, context and permissions are not model specific.

Loops

A loop is the agent going round the cycle of change, run and check until something tells it to stop. Anthropic's Claude Code team set out four kinds of loop:

• Turn-based hands over the check. This is the familiar back and forth of a chat: the agent checks its own work and then stops for your next instruction.
• Goal-based hands over the stop condition. You set the finish line (e.g. every test passing) and the agent keeps going until it gets there or runs out of turns.
• Time-based hands over the trigger. The agent runs on a schedule e.g. checking a pull request every five minutes to address new review comments and fix whatever is failing in CI.
• Proactive hands over the prompt itself. Schedules, goals, skills and pre-approved permissions combine so the agent picks up well-defined work like incoming bug reports or a long migration without anyone asking each time.

Most teams we work with are building loops for personal use with agents working towards a finish line for hours at a time. This is great for personal productivity but what we are repeatedly seeing across organisations is that everyone is working slightly differently and productivity varies wildly. So how do we scale up the good work that individuals are doing and make it something teams own together? 

Factories

The emerging popular term for the next leap is a software factory - many loops running at once across the backlog with work arriving from Jira/Linear, Slack/Teams, bug reports, production events and failed deployments. This does not mean that people have been automated away or software delivery runs from start to finish with nobody involved. For me, building your own factory is about scaling loops to deliver software more effectively, guided by our collective expertise but not replacing it. It's also not something you buy off the shelf as then you lose the ability to create something uniquely tailored to your business or product(s).

If today it is mostly individuals designing loops for their own work then scaling that up means a team designs the loops and workflows together. They decide which work goes to agents, with each agent getting just enough autonomy and context to complete its task then hands the result back to a person for review or approval. Those decisions add up to a system of work with guard rails around it curated by the people who know the codebase and the business. Where we've seen this be most effective is when the factory is treated as an internal platform with observability, cost controls and governance built in so teams can focus on the product decisions.

The alternative is known as a dark factory where code ships that no human has read but for this is not the reality for the majority of businesses because someone has to stay accountable for every change.

Practical applications for a factory

A software factory builds on the engineering practices a team already has. What makes one engineer productive with an agent today is good context, clear specs, reliable tests and CI. A factory turns those into loops the whole team can run and measure. The work that suits it best is repetitive but varies too much from case to case for traditional automation to handle.

There are three kinds of work that fit that description well:

• Large-scale migrations: Framework upgrades, cloud and API migrations and SDK swaps repeat the same kind of change across many repos or services. A factory turns each one into a consistent pull request that a person can review.
• Security automation: Dependency patches, SAST findings and pen test results are fixed as they are detected and raised as pull requests. Each fix also gets a security-focused review before it merges.
• Legacy modernisation: Agents reverse-engineer specs from the old system and write multiple layers of tests that pin down how it behaves. The rewrite then happens a piece at a time behind those tests applying modernisation best practices.

Where to start

Start small with loops for the tasks your team does most often, like triaging a crash or fixing a failing test. Each one teaches you what an agent needs to see, what it may change and where a person signs off.

Once those loops are reliable, move on to larger workflows. Code coordinates several agents and runs the steps that must happen the same way every time, like running the tests and opening a pull request. Keep it independent of any one harness so you can bring in open weights models too.

Only then think about whole programmes of work - running workflows across many assets and tracking which are done, blocked or waiting for attention.

We're helping a number of our customers build their own factory tailored to their business. If you'd like to talk through where your team could start, get in touch.