Convergent Architecture: Three Domains, One Principle
Infrastructure, software architecture, and agent systems converge on one rule: durable context matters more than disposable execution.
Infrastructure taught me that recovery depends on durable configuration. Software architecture taught me that passive artifacts can coordinate without a central orchestrator. Agent work taught me that the execution is disposable, but its accepted context can persist.
Three domains. One principle. The leverage lives in durable, reviewed state, not in any individual execution.
The Infrastructure Path
I spent years managing 100+ Kubernetes clusters in air-gapped defense environments, and I run the same discipline today as a platform engineer in defense autonomy. The lesson that stuck wasn't about containers or networking. It was about where the value lived.
A running cluster is disposable. You can tear it down and rebuild it in hours. The GitOps manifests, the network policies, the hardened configurations that took months of security reviews. Those are the intelligence. The cluster is the execution. The accumulated configuration is the context.
This changes how you think about failure. A node dies? Replace it. A cluster corrupts? Rebuild it from the manifests. The manifests are the system. The infrastructure is just the current instantiation.
Prevention over correction. Declare the desired state. Let the system converge. The intelligence lives in the declarations, not the running processes.
The Architecture Path
Building tooling across my production repos, I kept solving the same coordination problem. Agents needed to share state. The obvious answer was a central orchestrator: some service that tracks who's doing what and routes messages.
The obvious answer was wrong.
What actually worked was simpler than a central coordinator: durable artifacts with different jobs. Beads tracked work, decisions, dependencies, and evidence. Git held accepted source changes. A reviewed LLM wiki held the small set of reusable lessons worth carrying across sessions.
Beads issue → current work, decisions, dependencies, evidence
Git commit → accepted source change
LLM wiki → reviewed lesson with links back to source work
The files outlive the agent that created them, but persistence is not learning. A later agent benefits only if a planner retrieves the right artifact, checks that it still applies, and gives it enough weight to change the work.
This is the same pattern. The individual execution is disposable. The reviewed work trail remains available for inspection.
The Agent Orchestration Path
Then I started running multi-agent workflows at scale. 159 commits across a single project. Parallel workers spawned per wave. Each worker gets fresh context, executes one issue, and terminates.
The first instinct was to make each agent smarter. Give it more tools, longer context windows, better prompts. Chase the perfect execution.
That instinct was wrong too.
The breakthrough was the opposite: treat agents as unreliable components in a reliable system. Spawn parallel attempts. Filter aggressively. Ratchet progress so it can't regress. Any individual agent can fail. The system still converges.
Wave 1: Spawn 3 workers → 2 succeed, 1 fails
Commit successes. Ratchet forward.
Wave 2: Spawn 2 workers → Both succeed
Commit. Ratchet.
Wave 3: Retry failed work with fresh context
New agent, same accumulated context → succeeds
The worker is disposable. Each wave starts from the last accepted commit, while failed work remains visible in the tracker instead of silently changing the baseline.
The Convergence
Three different problems. Three different domains. The same architecture every time:
| Domain | Disposable unit | Durable, reviewed state |
|---|---|---|
| Infrastructure | Running cluster | GitOps manifests |
| Architecture | Individual agent | Filesystem artifacts |
| Orchestration | Wave worker | Ratcheted progress |
These systems share a useful engineering resemblance. It is an analogy, not a law.
The constraint: individual executions are unreliable. Nodes crash. Agents hallucinate. Workers produce garbage. Any system that depends on perfect execution is fragile.
The solution: accumulate context that survives execution failure. Manifests survive cluster death. Filesystem artifacts survive agent termination. Ratcheted commits survive worker failure.
The title borrows "convergent" because the designs arrived at a similar operational choice: preserve the state you can inspect and replace the execution you cannot rely on.
The Technique: Operationalize the Pattern
Once you see the convergence, the technique becomes obvious. Build systems that accumulate context across executions.
The specific implementation is what I call the Knowledge Flywheel: Beads keep the work and evidence; an LLM wiki keeps reviewed knowledge and its sources. The principle is narrower: make accepted context outlive execution.
On one project in early 2026, 66 sessions across 18 days produced coherent output because no single session needed the full picture. The intelligence was distributed across the accumulated context.
What the Pattern Does Not Prove
Early on, most agent executions produced garbage. Spawned, hallucinated, terminated. The instinct was to make each one smarter: bigger models, better prompts, longer context.
The fix was the opposite. Cheaper models. Shorter context. More attempts. But with a ratchet.
A good execution can produce an accepted commit. A bad execution produces a failed verdict or a bead for repair. It does not become a lesson automatically, and either result can be misread later. The reviewed artifacts make the history inspectable; they do not guarantee that the next agent performs better.
So What?
If you're building with AI agents, start Monday morning with three things:
- Put the task, dependencies, decisions, and check evidence in a Beads issue.
- Commit only accepted source changes; keep failed work visible without treating it as truth.
- Create or revise an LLM-wiki page only when review shows that the lesson is reusable, sourced, and still current.
The scarce thing is reliable, trustworthy delivery, and it comes from context that outlives any single execution. Three domains taught me the same lesson independently. That's how I know it's real.