An agent factory: AI agents take a GitHub issue to a pull request, with a person in charge

Problem

Every software team has more work than people. The backlog of small fixes and follow-ups grows faster than anyone can clear it, and the people best placed to decide spend their days on routine changes.

AI agents can now write working code. The hard part is everything around it:

• Trust. Who decided this change should happen? What else did the agent touch?
• Cost. An agent that retries, loops or wanders can spend money quietly, and nobody notices until the invoice.
• Attention. If every stuck agent lands on a person’s desk, that person becomes the bottleneck the agent was meant to remove.
• Adoption. If handing a task to the agent is more effort than doing it yourself, people simply do it themselves.

We met all four on our own product, a content and catalogue platform for cosmetics brands, and built a system that answers them.

Approach

We treated it as a production line with people in charge of it. Four ideas run through the whole thing.

• Agents do the work; people decide. Work starts only when a person writes a task and approves it. Nothing else becomes work: not an idea an agent had, not a failing test it noticed.
• Guards keep it safe. The agent that writes the code cannot publish it. A separate piece of plain code checks every change first: that it stays within the files the task named, holds no secrets, and leaves the system’s own safety rules alone.
• Every task is reviewed. Each change is tested against the criteria the person wrote, reviewed, and handed to a person with a plain list of what was and was not verified. A person, or a written rule a person owns, decides what goes live.
• Every task improves the next. When a task ends, the system writes down what made it harder, and a person decides which of those become improvements.

Read the diagram as text

1. Person: Writes the task (what to change, where, how to check it)
2. Person: Approves it to start
3. Agent: Checks the task is workable
4. Agent: Writes the code (in its own copy, within the files named). Otherwise: Stuck: the task is clarified, then it tries again
5. Code: Checks every change (scope, secrets, safety rules). Otherwise: Refused: a person decides
6. Agent: Tests and reviews (against the person's criteria)
7. Person: Decides what goes live (or a rule a person wrote)
8. Agent: Notes what made it harder (for the next task)

Implementation

We built it in small steps, each prompted by something that went wrong in the step before. A short retrospective after every task now proposes the next improvement, and changes nothing itself.

Make handing over the easy path. On the first day we built the system and then mostly worked around it ourselves, because handing a task over took more effort than doing it. One command to file a task, and a simple written rule for which tasks go to an agent, changed that.

Give every task a budget, and enforce it before the money is spent. Each task has one budget shared by every agent that touches it, and days and months have limits too. Money is set aside before an agent starts, so several agents working at once cannot overspend together. If an agent reports the same problem twice, the task stops rather than paying for a third attempt.

Read the diagram as text

1. Nothing changes without a person
2. A task ends
3. A short retro reads what happened
4. A proposal lands in the queue
5. A person reviews it
6. The improvement is built (with a test that proves it), then back to: A task ends

Outcome

• A large share of our day-to-day changes are now written by agents, steadily, inside limits we set.
• Our own work moved up a level. We spend our time writing good tasks, setting priorities and reviewing, rather than typing routine changes.
• Costs are predictable. Budgets are enforced before money is spent, so a bad day is a stopped task, not a surprise invoice.

Where it can go next

The same foundations open up more. These are the directions we see as realistic in the near term:

• More kinds of work. Documentation, test coverage, data checks and routine maintenance fit the same pattern: a clear task, clear criteria, a review.
• Better planning. Agents that read the roadmap and propose the next tasks, while the decision about what starts stays with a person.
• Wider safe automation. Gradually widening the kinds of change that may go live on their own, each one a written decision, as trust is earned.
• Beyond code. The same control model suits agents that prepare reports, draft content or process documents: anywhere the work can be described and checked.

What this shows

AI agents become useful in a team when people decide, in advance, what they may start, spend and publish, and the system holds them to it. The agent’s raw skill matters less than how easy it is to hand it a task, how its budget works and how honest its reports are.

What this means for your team

You do not need to build a factory from scratch. We set up the same kind of system for clients, sized to their team and their tools:

1. Pick the work. We find the tasks in your backlog that are well defined and repetitive enough to hand over.
2. Set the rules. Who can start work, what it may cost, which systems it may touch, and who approves what goes live.
3. Wire the guards. Checks the agents cannot get around, a budget enforced before money is spent, and a clear record of every change.
4. Start small and measure. One team, one kind of task, a few weeks of evidence, then widen.
5. Hand it over. Documentation and training, so your team runs it without us.

If your team has more work than people and you want AI agents to take some of it, safely and predictably, book a call. We will look at your backlog with you and tell you honestly what an agent could take on, and what it should not.

Stack

AI coding agents, Python, GitHub

Type

Internal system, built and run by us

• ai-agents
• software-delivery
• automation
• guardrails
• github