Most agent-system stories begin after somebody has cleaned up the evidence.
You get the diagram: Architect at the top, Worker in the middle, Auditor at the end. A few arrows. A few nouns with capital letters. Everyone appears to have understood the system before building it.
That was not my experience.
Foundry began as Context Foundry, a deliberately narrow experiment. I wanted to know whether an existing Coordinator/Worker workflow could become more trustworthy if planning, implementation, and verification were separated.
The first version was not a platform. It was a read-only pilot: four selected sources, a single question, a frozen corpus, a structured evidence packet, and an independent audit.
That constraint turned out to be the whole point. The useful story is not that I made more agents. It is that the process kept exposing places where an agent could make an unjustified leap—and we had to decide whether to patch the leap or remove the assumption that created it.
The first design was intentionally boring
The original question was small:
How should the existing Coordinator/Worker model be extended into Architect/Worker/Auditor?
The answer was not complicated in principle:
Architect owns preflight, scope, acceptance criteria, dependencies, dispatch, and invalidation.
Worker is the single implementation writer for a bounded piece of work.
Auditor is independent and read-only. It checks the Worker’s receipt, final diff and status, required command outcomes, and evidence before anything is called complete.
This was not a bid to create a corporate org chart for robots. It was an attempt to prevent a very ordinary failure mode: one agent invents the plan, performs the work, narrates the work, and decides that its own narration is good enough.
The first hard rule was therefore painfully unglamorous: one active writer in a shared checkout.
The Auditor could not repair the Worker’s code and then approve it. A Kanban card was a routing record, not proof. A local commit was not delivery. An agent saying “tests passed” was not evidence until the relevant tests, the diff, and the actual destination had been checked.
Obvious? Sure. Also not obvious enough to survive implementation without being written down.
Bad start #1: I added a human gate that the work order had already answered
The early control plane required a separate human approval for the pilot corpus before the Worker could begin. It had a root card, a completion-triggered continuation hook, and a quiet hourly recovery fallback.
Very cautious. Very visible. Also redundant.
The work order already gave the Architect authority to select a bounded three-to-five-source corpus. Demanding another approval for the same bounded decision did not add safety. It converted an authorization into ceremony.
So the rule changed: once the Architect recorded the frozen corpus, work could proceed. A new review was needed only if the corpus materially changed.
That gave me the first useful Foundry rule:
A gate is not safer because it exists. It is safer only when it decides something that has not already been decided.
This matters well beyond agent systems. Duplicate approval steps make a process feel controlled while training everyone involved to treat the controls as obstacles. Eventually somebody routes around them. Fair enough, frankly.
Bad start #2: the pilot’s own source of truth failed its integrity check
The pilot hash-pinned four sources. One of them—the file that described the Foundry Phase 1 boundaries—did not match its recorded SHA-256 when the Worker inspected it.
The convenient response would have been to update the hash and continue. That is how a process that calls itself evidence-based turns into “whatever the last editor meant.”
We did not do that.
The mismatched source was excluded from the material conclusion. The remaining three matching sources were enough to support the role-model recommendation. The mismatch stayed in the record as an explicit unknown.
This was not a dramatic breach. It was more useful. It proved that a source hash is either a real constraint or decorative metadata. There is no flattering middle ground.
A frozen corpus means: this is what we said we were going to reason from. If it changes, the process must notice before the conclusion gets to borrow its authority.
The first win was stopping a loop
During the pilot, I added a completion-triggered continuation and an hourly recovery fallback. Both were reasonable for a temporary control-plane experiment.
After the Auditor returned PASS and the Architect produced the synthesis, the recovery loop was removed.
That sounds like housekeeping. It is not.
Automation has a habit of outliving the question that justified it. A temporary cron becomes “the way we do things.” A one-off monitor becomes infrastructure. Then someone is on call for a proof of concept nobody explicitly agreed to operate.
Foundry’s first terminal state included the evidence packet, independent audit, synthesis, and a read-back that the recovery job had been removed. The result did not authorize a Phase 2 monitor, health job, recursion loop, gateway, or autonomous external action.
The system got better the moment it learned to stop.
From a pilot to reusable skills
Once the role model worked as a small experiment, the next problem was ownership.
The original material drew on an existing AI.Contract workflow. But if Foundry depended on one checkout, one service, or one host, it was not really a reusable process. It was an installation detail wearing a nice hat.
So the reusable pieces moved into a source-controlled Foundry package:
versioned Architect, Worker, and Auditor profiles;
role-local skills;
a portable contract-orchestration kit;
deterministic validators and templates;
synchronization for non-secret profile assets, excluding credentials, runtime state, logs, and caches.
That last boundary became important quickly. A recovery skill may tell an agent how to investigate a stale checkout, malformed response, partial write, or wrong path. It must not quietly become permission to install a scheduler, gateway, heartbeat, cron job, or service.
A skill should make an agent less improvisational, not more powerful by accident.
The next problem was not code
At this point, Foundry had roles, skills, validators, and a basic discipline. It still had a serious hole.
A Worker could make a bounded change, run tests, and push a candidate. But who was allowed to close the external work record?
“Whoever has a token” was not an acceptable answer. That would collapse the separation of duties at the exact moment a system most wants to declare victory.
The answer became task-bound authority: narrow adapters that derive what they may do from the assigned work record, carry out one allowed operation, and read back the result.
That led to a broader rule:
Authority should be derivable from the work record, not smuggled in through a convenient shell session.
In Part 2, that principle collides with reality: a verified candidate is not necessarily delivered work; an adapter can become dangerous when the delivery policy changes; and a recovery system can miss the precise failure it was built to recover.
The diagram was the easy part. The work began when we tried to make every arrow mean something.