An agent should not be the source of truth for its own work

One of the rules in our architecture is that an agent can request work and report what it did, but it cannot create authoritative truth by saying something happened. “I finished the task,” “the tests passed,” and “the deployment worked” are claims until another part of the system proves them. Our governed workflows start with a typed contract describing the work and its definition of done. Commands authorize actions. The resulting events are appended to a durable log, reducers turn those events into projections, and those projections are what clients read. The chat transcript is useful operating context, but it does not own task state and it is not used as the database for the workflow. Completion uses the same separation. The worker produces evidence tied to the task, but a separate verifier evaluates it against the definition of done and authoritative downstream state. For code changes that may include the actual CI result, the merged commit, required artifacts, and a receipt stored outside the worker’s session. A worker cannot certify its own receipt just because its final message sounds confident. The practical benefit shows up after failure. If the agent session disappears or a process restarts, we do not reconstruct the workflow from whatever the model remembers. We replay the event history through the contracted reducer and rebuild the projection. If the same event sequence and reducer version produce a different state, we treat that as an architecture defect rather than normal agent variability. What owns truth in your agent system today: the agent’s working memory, a task database, an event log, or something else?