Agentic Development, Part 6 · 12. October 2026
The Factory as a Living Contract
The image I have in mind for the factory comes from Arthur C. Clarke's Rendezvous with Rama.
What interests me in Rama is the level of automation. The human visitors encounter a world whose systems and biological robots operate around them. They are trying to understand a place that does not need them to direct its activity. About the novel.
For me, the powerful idea is that the builders' intention can remain present in the behavior of a system, even when the builders are absent.
That is a useful image for the next stage of our software factory. We are still far from Rama. But we already have work continuing after people leave, and more people producing candidates than before. The question is how that activity continues to express what the organisation actually wants.
The contract has to stay alive
In the earlier factory article, I described specifications entering and working software coming out. Operating that factory has made the work around the specification much more visible.
A candidate can satisfy a requirement and still expose a misunderstanding. A business owner can change a priority while implementation is underway. A technical decision can affect several projects at once.
We need an operating system that carries these changes through the work. I see the factory as a living contract between us and computational intelligence: what we intend, the conditions under which the agents can execute, and how we recognise an acceptable result.
The execution of that contract also has to be tracked. We need to connect the candidate to its source, the checks to the candidate, and the decision to the person who had authority to make it. Otherwise, the factory can report progress while we lose track of what that progress means.
This is why I think the factory needs to become a kind of digital twin of the organisation. To execute a roadmap well, it needs more than a backlog. It needs our capabilities, dependencies, responsibilities, current decisions, and open questions.
We are progressively building that representation. The aim is to give computational intelligence the best possible context for the work we delegate to it.
Choosing where the factory should stop and look
Imagine the reporting candidate from the previous article. The screen is taking shape, but the service behind it is still incomplete. The agent changes one component, launches the full suite, waits, then discovers that the missing service is still missing. It repairs another piece and starts the whole machine again.
The factory is busy. But a lot of that activity is inspecting work we already know is unfinished.
We have gone through several versions of our operating system to address this. We do not want the same rhythm for a prototype, an MVP, an end-to-end investigation, and a production adjustment. Choosing the wrong rhythm can cost days of tokens instead of hours of work.
In our factory, the two named development methods are Progressive Feedback and Build Fast. The project stage helps us choose between them. What changes is the placement of the feedback loops: when to check a boundary, when to finish connecting the whole path, and when to spend on broad validation.
Progressive Feedback: discover the expensive mistake early
Progressive Feedback is our default. We start with cheap local checks, then focused unit and contract tests, then integration with emulators and checks that one account cannot cross into another. We widen verification as the change earns it.
A failure sends the work back for repair at the relevant boundary. Independent work can run in parallel once its dependencies are complete. Passing a small test does not advance an incomplete change straight to acceptance.
- Implement a bounded changeRespect ownership and dependencies; parallelise independent work
- Widen the local feedbackStatic / types → unit / contract → emulator integration + isolation↺ At each failed boundary: repair → rerun affected checks before advancing
- Run complete affected-repository gatesThen build the immutable candidate in the governed delivery sequence↺ Failed gate → repair source → revalidate the changed candidate
- Preview, environment checks, independent verificationUnder the selected environment's authority; retain candidate-specific evidence
The governed sequence. The current web delivery split is shown below; preview availability alone is not acceptance.
This is useful when a wrong assumption can spread. If the reporting candidate misunderstands who is allowed to see a record, we want that feedback before we build more features around it.
Build Fast: finish the connected path, then challenge it
Sometimes the main problem is fragmentation. The database, service, and screen each look convincing on their own, but nobody has finished the useful outcome through all three.
Build Fast gives that work a bounded run in a non-production environment. Before starting, we record the scope, exclusions, source requirements, permitted mutations, completion condition, integration path, final checks, and independent reviewer. That is the contract for this run.
The agent then builds the complete path in dependency order. For work coming from an approved prototype, we first reconcile the backend fixtures with what the prototype promised. While the batch is incomplete, compilation and focused diagnostics keep it moving. Broad suites and CI wait for a coherent checkpoint instead of being restarted for every partial fix.
- Record the batch contractScope, authority, completion condition, final gates and reviewer
- Connect the complete vertical pathSource parity → database / owner → service / API → screen↺ During implementation: cheap checks → local correction → continue building
- Coherent checkpoint → consolidated validationReviewable integration; required local, CI and hosted coverage↺ Failures → grouped repair → focused recheck + required final full gate
- Verify the real development chainAuthoritative data path, source-bound evidence and independent review
A completed batch enters the normal release controls. Production effects or scope/authority violations stop the run.
The feedback arrives as a complete set of findings. We group related failures, repair them together, run the smallest checks that prove the corrections, and still run the required final full gate. We also verify that the visible result comes through the real development database and services. A convincing screen backed by a fallback is not the finished path.
This changes the cost and timing of verification. The acceptance conditions remain part of the contract. Build Fast stops if the work reaches production, exceeds its authority, or exposes a problem outside the agreed scope. Our delivery specification also bounds autonomous repair: two evidence-preserving attempts, then escalation with the failure evidence, a cause hypothesis, and options. We do not want an agent spending the night circling the same failure.
The model is one part of the factory
We have also worked with multiple LLMs and model versions. Clarifying an intention, implementing a precise change, investigating a failure, and challenging an architectural decision are different jobs.
The model choice should follow the job. More reasoning can be valuable when the agent must connect several parts of the system. A smaller, well-defined task may benefit more from fast execution and a clear check.
The useful cost is the cost of arriving at an accepted result.
A cheap call that produces several rounds of repair may be an expensive choice. A capable model can also waste a great deal of effort if the factory sends it through the wrong process.
We track the model and measured consumption where the workflow requires it, together with the work needed around the run. That gives us something to improve beyond a preference for one model. Anthropic's discussion of building effective agents makes a related point about matching the approach to the task and its cost.
The machinery became the bottleneck
As implementation accelerated, CI/CD became one of the main bottlenecks of our factory. Changing the agent's instructions was only part of the work. We also had to change what the pipeline actually waited for.
Our current web workflow separates routine development and staging delivery from full acceptance. On a routine change, critical checks run alongside deployment. Deployment does not wait for their result. Firebase App Hosting performs the frontend build; routine CI avoids building the same application again just to repeat that work.
Type checks
Critical unit testsFailure → repair → new source revision
Firebase build
Non-production rolloutRuns without waiting for quality
These lanes run in parallel. A rollout is availability, not production acceptance.
- Export protected specification contractsOnly immutable authority artifacts reach product test jobs
- Full suite + four parallel UI shardsContract, unit, integration and browser checks; production-build test harnesses↺ Findings → repair → affected checks + required final validation
Outstanding failures remain production-readiness gaps. Independent acceptance and production activation are still required.
The heavier acceptance run is explicitly started from the main branch. It includes the broader contract, unit, integration, and browser checks, with the UI suite split into four parallel groups. Failures remain gaps to resolve before production acceptance. Moving a test out of the routine delivery path does not make it pass.
That distinction matters. We can make a candidate available for development feedback while qualification is still open. Being deployed to staging tells us where the candidate is available; it does not tell us that the business outcome has been accepted.
These are the paths configured in the current workflows. They are not a claim that every hosted journey has passed. Our earlier delivery guide describes a stricter sequence, with full gates before the candidate and preview. The later web workflow decouples non-production delivery from those gates. Keeping the living contract useful also means making that evolution visible.
We reuse a passing result only while its source, dependencies, and environment still apply. Repairs invalidate the relevant evidence. Independent verification and production activation remain separate decisions. The factory has to remember all of that while choosing how quickly to move.
The same lesson applies to specifications. We kept Spec Kit and improved how we maintain requirements, decisions, plans, and tasks. Updating the canonical artifacts keeps the factory connected to the current intention. Recreating documents around every iteration makes that connection harder to follow.
Some of the most valuable work has been in these ordinary engineering details. They determine whether a more capable model produces a faster factory or spends more time waiting inside it.
Connecting the factory back to the conversation
Recently, we started automating more of intent exploration itself. This led us to build the first interface between the factory and the clarification process from Part 4.
Suppose the agent reaches a requirement whose meaning is still open. It needs to bring that question to the concerned person, explicitly, in the channel where the work is happening. The answer then needs to reach the specification so that subsequent work uses the clarified intention.
This is the connection we are trying to close. The factory discovers what it cannot resolve, people clarify it, and the contract evolves with their decision.
Our first readiness worker is implemented locally. Hosted qualification and its connection to production dispatch are still ahead. That is the current boundary of this automation.
Dashnet connects the factory to the wider context of the company. The people and relationships described in the previous article become useful here: the agent needs to know who can answer, and which answer has the authority to guide the work.
Rama also needs a world to observe
There is another boundary. Our agents can be very capable inside the systems we have connected and still know nothing about something important that happened outside them.
A conversation during a property tour may never reach a ticket, a report, or a shared drive. The model cannot reason from a signal it never received.
We have started experimenting with new ways to collect these signals, including a Friend device in real operating conditions. The current work supports deliberate recording, transcription, and review. We still need more field testing. Consent and control over the recording belong in the workflow from the beginning.
I think this private AI infrastructure will be a major part of the moat. Many organisations will have access to similar models. They will not have the same signals, the same history, or the same understanding of how those signals relate to their business.
Collecting the signal is the first step. Connecting it to useful action will be next.
Opening a door is one example of where this could lead. It remains a future direction, with its own questions of identity, permission, and confirmation that the action succeeded. The living contract extends into the physical world.
This is where Rama becomes interesting again: an environment that can observe, respond, maintain itself, and keep carrying out work. Our ambition is to connect more of the real business to that kind of continuous operation.
In my talk on autonomous contributors, I used the image of a strategy game. People define objectives, allocate resources, watch the whole system, and intervene where a decision is needed. The workers continue and signal when they need attention.
The more we connect intelligence to the signals and actions of the business, the closer we get to that operating model. The human still has to decide what is worth building and what direction the organisation should take. The factory gives that intention a way to keep moving.
Previous: From Seeds to Candidates
Cover: Rama illustration reproduced in GeekTyrant, converted to black and white. The source page does not identify the artist or provide reuse terms.