Agentic Systems Are Distributed Systems With an Unreliable Planner
Agentic engineering becomes much clearer when the model is not treated as the center of the system.
The model is the planner. It may be useful, fast, and surprisingly good. It is still an unreliable planner attached to tools that can change real state.
That framing matters because production failures usually do not happen in the polished demo path. They happen when a tool times out after doing the work, an approval expires while the world changes, an agent resumes from stale context, or a harness grades a confident answer while the external system is wrong.
This series uses distributed systems thinking to make agentic systems less theatrical and more operable.
The thesis
Agentic systems should be designed around durable intent, constrained authority, replayable evidence, and state verification.
The useful question is not "how smart is the model?" The useful question is "what can this system prove after something goes wrong?"
Part one: distributed systems foundations
These essays establish the failure vocabulary. They are not agent-specific, but they explain why agentic systems become hard the moment they interact with real systems.
- Ambiguous Outcomes Are the Core Distributed Systems Problem
- Idempotency Is Durable Intent
- Reconciliation Is Where Correctness Becomes Real
- Leases, Ownership, and Fencing
- Backpressure Is a Product Boundary
- Queues Are Not Reliability
- Deadlines Beat Timeouts
- Replay Changes Everything
- Sagas Without Fantasy Rollbacks
- Control Plane vs Data Plane Failures
Part two: agentic engineering
These essays apply that vocabulary to agents: tool authority, context trust, durable state, stop conditions, approvals, observability, and policy.
- Agents Are Unreliable Planners Attached to Real Tools
- Tools Are Capabilities, Not Functions
- The Agent Action Lifecycle
- Context Provenance Matters More Than Prompting
- Agent State Should Live Outside the Model
- Stop Conditions Are Safety Features
- Agents Need Read/Write Separation
- Human Approval Is a Protocol
- Agent Observability Should Follow Decisions, Not Tokens
- The Model Should Not Be the Policy Engine
Part three: harness engineering
Harnesses turn agent behavior into something inspectable. They are controlled worlds with state checks, replay, refusal cases, failure injection, and regression memory.
- A Harness Is a Controlled World
- Grade State, Not Speech
- Replay Is the Difference Between Debugging and Guessing
- Test the Refusal Path
- Failure Injection for Agents
- Regression Suites Should Be Built From Bad Runs
- Golden Behaviors Beat Golden Text
- Harnesses Must Catch Overreach
Part four: production harness agents
The final section narrows the idea further: agents that watch, attack, audit, replay, and reduce blast radius. They are not general assistants. They are operational components with narrow permissions.
How the pieces fit
The dependency chain is intentional.
Ambiguous outcomes lead to idempotency. Idempotency needs reconciliation. Reconciliation needs ownership and evidence. Agent tools inherit all of those problems because they create side effects through an unreliable planner.
Harnesses exist because final answers are not enough. They create controlled worlds where state, refusal, replay, and overreach can be tested directly.
Production harness agents are the operational expression of the same idea. They do not replace engineering judgment. They make risky work easier to inspect before it becomes expensive to reverse.