An agent lacks context, so we add a document. It forgets a rule, so we add a check. A task comes up often, so we create a command. These responses can be useful. As they accumulate, however, it becomes difficult to know what still helps, what conflicts and what costs more than it contributes.
Organising an agentic software factory therefore also means knowing how to simplify. The aim is to enable agents to contribute to the product under conditions the team understands and controls.
Our experience here concerns software development agents. The principles of access, control and responsibility also apply to other uses, but their implementation needs to suit the work being delegated.
Start with the task and its boundaries
Before choosing an orchestration approach, we can describe what an agent needs to accomplish. What change do we expect? What information does it need? How will we know it has finished? When should it ask for a decision?
A clearly bounded task often makes it possible to start with a simple setup. If the agent fails, it becomes easier to examine the cause: missing information, insufficient access, an unsuitable tool, an ambiguous instruction or the model’s capabilities.
The answer is not always another agent. An automated check may be enough to detect a recurring error. An example in the specification may resolve an ambiguity. A question to a person may settle a disagreement that several agents would only rephrase.
Provide access to useful context
Context includes product intent, decisions already made, technical constraints and the current state of the work. Loading everything into every conversation can make the whole setup costly and difficult to maintain.
A more useful arrangement distinguishes shared rules, product-specific information and the material needed for the task. The agent needs to be able to find the relevant source, and the team needs to know which one takes precedence when two documents conflict.
Skills can bring together instructions and resources for a recurring activity. Commands make certain operations easier to initiate. Tool connections provide access to data or actions. Each of these elements needs a clear function and someone responsible for maintaining it.
The issue becomes apparent when resuming a session: what remains to be done, what has been checked and what has been decided? An accurate progress note may avoid more rework than another layer of orchestration.
Define access around the actions available
An agent that can read a repository, run tests and propose a change does not need the same permissions as one authorised to deploy. Access needs to match the task and its possible consequences.
Information received from a document or tool may contain malicious instructions. It needs to be treated as data to examine, not as new authorisation. OWASP’s guidance on AI agents covers these injection risks and the restriction of permissions, among other issues.
Human approval also needs to be designed. If someone receives too many requests, or poorly explained ones, they may end up approving them mechanically. They need to see what will change, what the action entails and the evidence needed to decide.
Add checks that provide different evidence
A test, a code review and a browser trial do not detect the same defects. The right combination depends on the product. Repeating the same analysis several times can be expensive while preserving the same blind spots.
In our development work, reviews have also shown that findings need to be assessed before being corrected. Some block a release. Others are debatable, already covered or outside the scope. Addressing them all immediately can expand the work and introduce new regressions.
Time spent examining reports is part of the factory’s cost. We need to look at errors detected, false alarms and rework avoided. A process that produces more reports than a team can understand needs revisiting.
Work in parallel when the tasks allow it
Several agents can make progress on separate tasks. This requires isolated workspaces, sufficiently clear scopes and a way to integrate the results.
When tasks depend heavily on one another, coordination can cancel out part of the benefit. Two agents changing the same design decision at the same time introduce differences that will need resolving later.
Anthropic’s work on long-running development environments, published in March 2026, illustrates how the environment and division of work influence results. It describes an engineering experiment, not an ideal number of agents to replicate.
Maintain the factory as part of the product
A model change can make a setup less useful. A new constraint may require another check. A rule inherited from an incident may become too broad.
The team needs to be able to make these changes without losing what worked. Rerunning a few representative tasks before and after a change helps compare results, costs and the burden of checking. Actual incidents add to this set.
At The Spark, we build this way of working progressively with teams, starting from their products. Our Rethink your organisation offer connects the agentic software factory with responsibilities and the product lifecycle. For a concrete example of how these elements come together in a real product, see our account of building The Playground.