Command Query Responsibility Segregation splits a system's write model from its read models. For agent platforms it resolves a persistent tension: runs produce one enormous append-only truth, while humans and dashboards need a dozen small, fast, purpose-built views of it.

The write side is the run: commands (StartRun, ApplyPatch,VerifyStep) validated and appended to an event log — the same event-sourced spine that gives durability and replay. The read side is projections: purpose-built views transformed from that log. A live execution view for the UI, a cost ledger per team, a findings list for security review, a knowledge-graph candidate list, a compliance export. Each projection is a small, denormalized structure rebuilt from the log at will — which is the liberating property: read models can be wrong, experimental, or deleted, because the log remains the single source of truth.

Agent systems strain monolithic state designs in a specific way: different consumers need contradictory shapes of the same history. The UI wants the last 50 steps hot and paginated; the postmortem wants full-fidelity replay; the finance dashboard wants token counts by hour. One state structure serving all three becomes the thing nobody can change. Under CQRS, each is a projection with its own lifetime and its own cache.

Field Notes

• Commands are intentions, events are facts: validate commands against current projections, but append events — the distinction is what makes replay sound.
• Projections are disposable: rebuild them offline first; a broken projection is an incident, a broken log is a catastrophe.
• Watch projection lag: eventual consistency means the UI can trail the run — surface lag in the product rather than pretending it does not exist.
• Schema the events: versioned event schemas are the contract future readers depend on; unversioned agent logs are tombstones with JSON in them.

CQRS also quietly answers the storage question every agent platform eventually faces — "do we keep all of this?" — with a better one: keep the log (cheap, cold), build the views you need (small, hot), and stop pretending one structure can serve history, dashboards, and law at once.