Externalized trust and the road to software factories

The allure of software factories couldn’t be more obvious: You write in the things you want, wait a little bit of time and magically you get exactly what you asked for. But to get to the promised land of robo-nirvana you have to overcome several issues, with one of the most common ones being discussed relating to scale. How do you get enough power, enough agents, enough tasks, enough parallel branches, enough PRs to solve this?

I believe this is the wrong way to think about it.

The hard part is not, and has not been for quite some time now, getting agents to write code. They already write code. They write a lot of it and oftentimes better than a lot of us, as much as it hurts to say. They write it quickly, confidently, and often well enough that our first reaction is to get out of the way.

The hard part is knowing what to trust. A software factory is not a room full of agents writing code. It is a repeatable path from intent to shipped change where every handoff has receipts, where the oversight is at just the right places for it to get approved and merged with minimal friction.

Confidence is not trust

Agents are extraordinary confidence machines. They will say “done” after changing files. They will say “tested” after running a command. They will assure you it’s “ready to ship” after summarizing a diff. The tone barely changes whether the evidence is strong, weak, missing, stale, or invented. Mind you, that is not a moral failure, it’s just part of their design. A chat model gives you a fluent answer because fluent answers are what it was trained to produce.

Software does not run on fluent answers.

Software runs on constraints, state, tests, logs, invariants, review, production behavior, and the boring trail of evidence that lets a team believe a change belongs in the system. The agent’s confidence should be treated as a useful signal, but it should not be the only trust boundary.

This is where I see a lot of agentic development discourse going sideways. We constantly ask which model is smarter or more efficient. Which one can take a more accurate prompt and write better code. We ask how big the context window is. There is a point to those questions but when we’re thinking big, of factories, the questions are too small.

Here’s a better way to think of the “factory question”: what has to be true outside the model before work is allowed to advance?

If the only answer you have is “the agent said so,” you do not have a factory. You have Cousin Greg with sudo access.

Trust has to leave the chat

A chat is a terrible place for institutional trust to live.

Chat is ephemeral, it is linear. It mixes speculation with decisions and it carries stale assumptions forward with the same typography as confirmed facts. It encourages the agent to narrate progress instead of proving it. It makes us have to scroll through prose to reconstruct what the hell happened.

That used to work when the unit of work was small, manageable, and we were the only ones watching. It breaks as soon as machines are involved.

Factories need durable state, checkpoints. They need inventory, quality gates, audit trails and a way to say this object is here, in this stage, with these inputs, these checks, these failures, and this permission to proceed.

This is nothing new. Long ago we stopped deploying by SSHing into servers and remembering what we changed. The whole thesis of IaC was based on this same principle, externalize all of the messy infrastructure into organized code, put those deployments into pipelines, move incidents into logs, decisions into ADRs, and reviews into pull requests. Some of us just assumed this was “the way” because we were used to it but the point was never ceremony for ceremony’s sake. The point was that important state should not only live in someone’s head.

I believe agentic software needs the same move.

The important state cannot live solely in the model’s context window. It has to move into systems the model can read, write, and be constrained by. By the same thinking we write unit tests by moving the state out of the actionable path, we need to push away as much of the nondeterministic process from agents from what we can rely on.

That is how I’ve started to think about it, externalized trust, as a layer around the agent that records what the work knows, what path it must follow, what evidence exists, who owns the next step, and whether the change is allowed to move forward.

It is not one tool or a better prompt. It is not a smarter AGENTS.md file though those certainly help. It is the surrounding environment that turns a nondeterministic worker into part of a deterministic delivery system.

The factory is a trust machine

When people think “software factory,” they usually think automation. I find that a more useful definition is trust production.

A factory takes raw material through a controlled process and produces an object that meets a standard. The point is not just that machines do work without supervision. The point is that the output can be trusted because the process is repeatable, observable, and constrained.

This is the missing piece in most agent setups.

An agent can take a ticket, inspect code, make changes, run tests, and open a PR. That looks like a factory from far away. Up close, the trust is still mostly in the human operator. Did the agent understand the product intent? Did it skip a step? Did it test the right thing? Did it touch a boundary it did not understand? Did it leave out the one piece of domain context that never made it into the repo? Did it stop when it should have asked a question?

If the human has to reconstruct all of that from a chat transcript, the factory has not externalized trust. It has externalized typing.

This is why I am less interested in autonomous coding demos than in the boring machinery around them. The demo shows that the agent can produce output. The harness around it decides whether that output can become software.

Memory: what does the work remember?

The first trust problem is memory.

Every fresh session starts slightly stupid. Same repo, same project, same developer, but the agent does not carry the lived history unless something brings it back. The code is there but the decisions and the path to how the code got there often are not. Why did we pick this boundary? Which convention is intentional and which one is legacy? What did review catch last time? Which approach did we reject? Which production incident made this rule exist? Which note is still valid and which one expired when the plan changed?

If that knowledge only lives in chat, it evaporates, like tears in rain. If it only lives in a giant context file, it pollutes every session whether relevant or not. If it only lives in our head, how can the agent use it unless you notice the gap?

That is why I built Memento Vault. The retrieval mechanics are interesting, but the deeper point is not memory as trivia. It is memory as trust infrastructure. Externalized knowledge.

A useful memory system does not just say “here is a fact.” It says where the fact came from, when it was captured, how certain it is, what context it applies to, and whether something newer supersedes it. Memory without epistemology is just a faster way for the machine to hallucinate with confidence.

This is the first layer of externalized trust: the work has to remember more than the agent does.

Of course we don’t save everything. Not every line of every transcript is gold. Instead you focus on the durable parts: decisions, patterns, gotchas, constraints, and the scars that explain why the system is shaped the way it is.

Process: what path must the work follow?

The second trust problem is process.

Agents will skip optional steps. This doesn’t happen because they are malicious, instead it’s because they are optimizing for completion. If the user asks for a fix, the agent wants to produce a fix, it wants to please. If the prompt says “be careful,” the agent nods and continues, then burns the house down.

“Be careful” is not a process.

A process is a path the work must pass through. Vague work gets shaped before design. Design happens before implementation. Broken behavior gets root cause before fix. Claims require evidence. Review happens before shipping. Risky transitions stop for human judgment.

That is the idea behind Beislið. It is not trying to make the model brilliant, technology has already gotten there with current model quality. Instead it focuses on making the path explicit enough that the model cannot casually skip the parts that create trust. Externalized process.

This is where the usual SDLC diagrams can become misleading. Plan, build, test, review, deploy. Those seem like nice boxes. They’re just too coarse for agents and things will slip through.

Usually inside “plan” there are many smaller decisions: is the problem clear, is the scope coherent, is this one PR or several? do we need a spec? if we need a design, what assumptions need confirmation? Same case with “test”, many smaller decisions contained within: what changed, what verification matches that change, what evidence proves it, what failed, what is pre-existing? Inside “review” are smaller decisions: is this a correctness issue, a shape issue, a stale-context issue, a security issue, a human judgment call? You get the gist.

A factory cannot depend on the agent intuiting those micro-steps. The path has to exist outside the chat.

This is the second layer of externalized trust: optional becomes skipped unless the harness makes it required.

Proof: what evidence exists?

The third trust problem is proof.

By far the layer that most workflows underbuild.

The agent says it ran tests. Did it? Which tests? From what directory? Against what branch? With what failures? Were the failures relevant or not? Can someone inspect it without replaying the whole session?

The gap between “tested” and a command log is the gap between confidence and proof.

Software factories need proof because autonomy without proof is just unreviewed, sloppy automation. The more work the agent does, the more important this evidence trail becomes. You cannot scale human-in-the-loop supervision forever, it won’t scale, so we have to move up a layer but that only works if the layer above the code is rich enough to inspect.

What ran. What failed. What changed. What was reviewed. What remains uncertain. What was intentionally not checked. What needs capture later.

One of the main purposes of Beislið is to make this part easier, though it can’t be solved by itself. It needs a steady hand and thoughtful consideration but the skeleton to hang it on is there. It’s easy to go too far and make every tiny change a museum exhibit. The work should produce enough evidence for the risk it carries, and the key is in that word, enough. A CSS tweak might need a screenshot, but not always. A migration might need dry-run logs, as long as it’s big enough. Missing evidence should be explicit, not buried under a confident summary, and with a bit of taste to make sure it won’t go overboard.

Without this proof, speed is just moving uncertainty downstream. Externalized proof.

This is the third layer of externalized trust: the system must capture evidence outside the model’s narration.

Coordination: who owns the next move?

The fourth trust problem is coordination. And interestingly this is where the software factory idea starts to break current tools.

One agent in one chat can coordinate through conversation. A few agents can coordinate with a very careful human operator. But when we scale to a swarm of agents they cannot coordinate through vibes, GitHub notifications, and a heroic engineer skimming PRs all afternoon.

At this point in May 2026 runtime is getting solved. Agents can run in worktrees, containers, VMs, cloud sandboxes or whatever isolation model you believe in. Orchestration is getting solved. Agents can start from tickets, schedules, webhooks, CI failures, dependency updates, production alerts. Triggers are not the hard part.

The hard part is stage state or in other words managing the context.

Who owns this work right now? Is it being planned, implemented, verified, reviewed, blocked, abandoned, superseded? What evidence is required to leave this stage? Which agent produced the last artifact? Which human decision is the current constraint? Can another agent safely pick this up? What happens if two agents reach for the same file? What happens if review finds a shape problem, not a bug? What happens if the agent is correct locally and wrong globally?

GitHub is not built for that. Linear is not built for that. They are human coordination tools. They are useful, but they are not the primitive agents need when hundreds of small transitions start happening in parallel.

I recently watched a very good talk by Lou Bichard here where he has a good phrase for this: the missing primitive for agent swarms. His argument is that runtime, orchestration, and triggers are mostly, or at least in the process, handled. Coordination is not. Agents need a way to ask something like: have I completed this part of the lifecycle, and may I proceed?

That question is the factory in miniature.

Not “am I done?” The agent will always have an answer for that.

“Has the external system accepted the evidence required for this stage?”

That suggests some kind of coordination ledger, state machine, or CLI gateway. I am less attached to the shape than to the responsibility. This coordination layer needs leases, stage transitions, handoff notes, verification receipts, escalation paths, and human approval gates. It should be boring and predictable in the way deployment systems are boring. Boring is what trust feels like after the novelty wears off.

This is the fourth layer of externalized trust: agents need shared state through shared context. Externalized coordination.

Execution: can the factory be observed?

The fifth trust problem is execution.

Once agents run in the background, the interface changes. You are no longer pair-programming with a model. You are operating a system of workers.

That means the questions change too.

What is running and where? What branch or workspace does it own? How long has this been stuck and wasting my tokens? What should be archived because it might matter later?

That is the direction behind Rondo. It is early, but I believe my instinct is clear: agent execution needs observability. Not because dashboards are fun (they are), but because invisible automation cannot be trusted at factory scale. Externalized execution.

Execution has to become inspectable. Runs need traces. Agents need identities. Workspaces need isolation. Token burn needs budgets. Failures need reasons. Handoffs need artifacts. The operator needs to see the line, not just the final PR.

This is the fifth layer of externalized trust: background work has to become operational infrastructure.

The human does not disappear

This all sounds like science fiction so allow me to take a step back. The usual software factory framing often sounds like the human disappears, like we’ll be out of a job, of a purpose in software development.

I do not think that is right. At least not for the work that matters. We just need to move our work somewhere else.

Less typing every line and more defining gates. Less remembering every decision and more curating the knowledge that should survive. Deciding where ambiguity requires judgment.

That is not a smaller role, it’s just a different one.

A lot of engineers will hate this framing because it sounds like management and I totally get that. I love coding. I do not want to become a dashboard jockey for mediocre robots. But the alternative is worse: pretending the old trust model still works while agents quietly produce more code than humans can responsibly inspect will lead to chaos and slop.

If agents increase output, trust work has to increase by the same amount. The question is whether that trust work is manual, implicit, and exhausting, or externalized, inspectable, and reusable.

The factory should not eliminate judgment. It should reserve judgment for the places where judgment matters.

What survives model change

There is another reason I like this framing: it is durable.

Models will and have changed. Over the last few months context windows have grown and APIs get more powerful. Today’s best coding agent will become tomorrow’s compatibility problem. A lot of harness code will age badly. Some of mine definitely will.

But externalized trust survives better.

A vault and the knowledge it contains will be useful even if the model changes. A short constitution of coding standards will be essential for onboarding. Verification logs will be especially useful when that orchestration framework changes. The more a piece of infrastructure captures real knowledge, real process, real evidence, or real state, the more likely it is to survive the current generation of tools.

That is where I have been spending effort. Not on making the prompt more ornate or on stuffing every convention into context. And definitely not on worshipping whichever model is winning this month.

The path I am building toward

The projects I have been using to experiment and learn might look separate from the outside.

Memento is memory. Beislið is process. Rondo is execution. The proof and coordination pieces are still forming.

But they are all circling around the same idea.

Externalized trust.

The work should remember. The process should constrain. The proof should be captured and the coordination should be explicit. Execution should be observable.

That is how I think we get to software factories that deserve the name.

Not factories because agents write code quickly. Factories because work can advance through a system that knows what happened, what is required, what is proven, and when a human needs to decide.

The model writes.

The harness earns trust.

The factory will naturally happen when that trust becomes external, durable, and repeatable. We just have to build for it.