Your Architecture Diagram Has No Exhaust Port

A component diagram describes what a system is made of. When the system chooses its own path at runtime, that is the parts list, and four other views are doing the work you thought the diagram was doing.

The Empire had complete technical readouts of the Death Star. Every component was catalogued. Every system relationship was documented. The plans were accurate enough that the Rebellion could study them, and accurate enough to pass any architecture review the Imperial engineering staff could have designed. The schematics were not wrong. They were simply the wrong kind of correct.

What the plans could not show was a behavior that emerged from the interaction of those components under a specific sequence of conditions: a two-meter exhaust port that connected to the main reactor along a path that only materialized when proton torpedoes entered it at a precise angle. That was not a missing part. It was a missing view. No component-level diagram surfaces a conditional sequence of conditions leading to a catastrophic failure state, because that is not what a component diagram is for.

The architect on your team has a diagram signed off last quarter. It is accurate. It passed review. Then an incident happened at 2 a.m., and nobody opened it, because the questions coming in were about which path the system took, why the model routed to that tool instead of the other, where the human-approval step was supposed to appear, and whether the confidence threshold had even been defined. The diagram could not answer any of those questions. That is not a failure of the diagram. It is a category difference in what needs documenting.

When the System Picks Its Own Path

A component diagram is a complete description of a system whose execution path is fixed. If the sequence of calls is determined by the code, then knowing the components and their relationships tells you everything about how a request moves through the system. That has been true for long enough that we stopped noticing it was a condition rather than a property.

An agentic system breaks that condition on purpose. The path through the workflow is decided at runtime, based on what the model concludes, what the tools return, and what the state contains at that moment. Two identical inputs can take different paths and both can be correct. The components are still accurate. They are just no longer sufficient.

What falls out of the diagram is everything that is a decision rather than a structure: which paths are permitted, what happens at the boundary of confidence, where a human is a named participant rather than an escalation, and what the system is allowed to do without asking. Those are architecture, and they have nowhere to live on a component view.

Picture a four-node coordination pattern. Deterministic ingress and egress at either end. Model reasoning in the middle. One conditional routing edge that sends control left or right depending on what the model returns. One confidence gate that holds execution pending a threshold check. One durable human interrupt that parks the run until a person responds. The topology is a graph, not a sequence, which is precisely the structural shift described when agentic runtimes replaced pipeline abstractions. As I wrote in Your AI Pipeline Is Already the Wrong Abstraction, the runtime topology of these systems does not behave like a queue and drawing it as one causes exactly this kind of documentation blind spot.

The component diagram of that four-node system is roughly four boxes and some arrows. It is accurate. It tells you nothing about what the confidence threshold is set to, nothing about what happens when the model falls below it, nothing about which nodes can be reached from which other nodes under which conditions, and nothing about where the audit record is written.

Every hard question about that system is invisible on its own diagram.

Four Views That Hold What the Diagram Cannot

These are not a framework. They are not a proprietary methodology. They are views an architect can draw, presented in the same register as any working practice.

The Decision and Routing View. This view shows every path the system is permitted to take, the condition on each edge, and the terminal states. It is built from the orchestration graph and answers the question that arrives before every incident: how did it get there? Without this view, the post-mortem reconstructs the routing logic from trace data after the fact. With it, the routing logic is a design artifact that was reviewed before deployment.

The Trust and Authority View. This view shows what the system may do without asking, what requires a human to proceed, where the boundary between trust domains sits, and what crosses it. This is the view a compliance or security reviewer actually needs and the one most likely to be missing entirely. The distinction between autonomous action and supervised action is an architecture decision. If you have not drawn it, you have not made it. The trust boundary question in ambient or always-on systems is particularly sharp, as the activation conditions I covered in When the Agent Wakes Up on Its Own depend entirely on this boundary being defined somewhere other than the developer's memory.

The State and Context View. This view shows what is in the state object at each stage, what is retained, what is discarded, and where context is selected rather than accumulated. Context selection is a design decision. When the system decides which prior turns to include, which retrieved chunks to pass forward, and which tool outputs to carry across stages, those are choices that shape behavior. Right now, most of those choices live in the code and nowhere else. This view makes them visible.

The Failure and Escalation View. This view shows how each stage fails, whether it fails loudly or silently, what the system does with an uncertain result, and where the audit record is written. If every failure mode is defined and accounted for, this view is short. If it is hard to draw, that is the finding. Hallucinated tool calls, infinite-loop agents, and guardrail fires are documented failure classes in 2026 agentic design patterns. They need somewhere to live in the documentation, not just in the oncall runbook.

A decision is not an event, and it will not appear in your telemetry no matter how complete that telemetry is.

The maintenance problem is real, and the answer to it is partly structural. The decision and routing view and the state view should be generated from the running system wherever the orchestration layer permits it. LangGraph, CrewAI, and Pydantic AI have all converged on graph-based models where states and transitions are explicitly represented. That representation is a generated artifact waiting to happen. Hand-drawn views belong to authority and failure design, because those are decisions that do not drift on their own.

Observability Is Not a Substitute, and It Is Not a Rival

The strongest objection to all of this is that four more diagrams will be drawn once and abandoned by the second sprint, and that the honest modern answer to a non-deterministic system is telemetry, because a trace is always current and a diagram never is. That objection is largely right, and any architect who has watched a wiki decay knows exactly how right.

A trace is the better record of what happened. It is not a record of what was permitted. Telemetry can tell you the system escalated to a human on Tuesday and it cannot tell you whether it was supposed to, because the intent was never written down anywhere the trace could reach. The confidence threshold, the authority boundary, and the escalation design are decisions, and decisions do not appear in event data no matter how much of it you collect.

The two answer different questions and the practical arrangement is to let each do its own job. Generate what can be generated, hand-draw only the decisions, and treat any view that cannot be regenerated as a candidate for deletion rather than a maintenance obligation.

This is also the architecture documentation discipline that established frameworks are learning. The extensions being built on top of C4 and the BPMN-based approaches emerging for human-agentic workflows are not discarding the base standards. They are adding the views that the base standards were never designed to carry, which is the same pattern I described in Your TOGAF Flight Plan Did Not Survive the AI Oxygen Tank: the existing frameworks are being extended, not replaced, because the vocabulary is still useful even when the notation runs out.

Somewhere there is an Imperial architect whose diagram passed review. Many of us have achieved that career outcome.

What to Do Before the Next Incident

Take the diagram that was signed off last quarter. Try to answer the trust and authority question from it alone: what can this system do without a human, and under what conditions does that change? Whatever is missing is the first view to draw. The gap is almost always there, it almost always matters, and it is almost always smaller than the work of drawing all four views at once.

Being correct and being complete have always been different reviews. The Empire's plans proved it.