Most enterprises now have teams doing serious architectural work on agentic AI. The work is necessary. The conversations being had inside it — about controls, surfaces, governance models, where deterministic constraints belong and where they cost more than they earn — are the right conversations. None of this post is going to argue otherwise.
But there is a decision that sits above the architecture, and the architecture cannot make it. The decision is whether a given workload should advance to production at all, and if it should, what posture it actually calls for. That decision is yours, not the architects'. They can inform it. They cannot resolve it. And if some of the workloads being pressed toward production do not quite feel right to you — the pilots look fine, but you would not want to be the one approving the deployment — that reaction is usually tracking something the architecture conversation does not surface explicitly. This post is about what it is tracking and how to make it legible.
The Three Dimensions the Decision Turns On
Three dimensions describe a workload's situation well enough to judge it. They are not a checklist and they are not a score. They are a frame: read together, the workload's combined standing across all three is what tells you what kind of governance posture — and, ultimately, what kind of agent — the workload actually calls for.
Outcome is what the workload produces if it works. The business value it generates, the decisions it enables, the work it removes from people who would otherwise do it. Higher outcome value justifies more architectural investment to capture and protect that value. Lower outcome value does not justify heavy architecture, regardless of how interesting the workload is technically. Outcome is the dimension most often inflated in discussion, because every workload feels valuable to the team building it; it is the one most worth being honest about.
Compliance is what the workload must satisfy — the regulatory and policy burden, external to the firm, that the workload's operation must demonstrably honor. Higher compliance burden means heavier audit-readiness requirements, more constrained data handling, more structural enforcement of required sequences. Compliance is the dimension most clearly understood across the enterprise, because it is the one with the clearest external owners. It is also the dimension most easily mistaken for the whole picture. A workload that is compliant on paper is not therefore deployable.
Surety is the freshest of the three and the one most worth getting right. It is not the same as compliance. Compliance is the workload's standing legal and regulatory posture. Surety is operational: how the workload actually behaves once it is running.
By its nature, surety is only fully manifested — and only truly measured — in production. That is the honest limit of the concept, and worth stating plainly rather than working around. The point of reading for surety before production is not to measure it in advance, which cannot be done. It is to project it: to form a defensible estimate of how likely the workload is to behave the way you need it to, and how durable that behavior is likely to be. A good notional design can project the potential and the likelihood of the desired outcome. It cannot promise it.
Two properties sit inside surety, and both are projected at the notional stage and confirmed only in production.
The first is the workload's likely quietness — how rarely its operation should be expected to produce an event that triggers an investigation, a review, a post-mortem, an internal escalation. A workload can be fully compliant on paper and still generate enough incidents to make the deployment unsustainable. Investigations cost time, attention, and trust even when nothing formally violated occurred. This cost is one of the things executives feel directly, and it is rarely surfaced in the architectural conversation, because the architects are designing for compliance, not for quietness.
The second property is whether that quietness is likely to hold as the world around the workload changes — when the underlying data sources evolve, when the regulatory environment shifts, when the model underneath is updated, when the systems consuming the agent's outputs change. No architecture can be made wholly immune to change, and one built to try would usually be too brittle or too conservative to be worth deploying. What separates a serious architecture from a fragile one is whether it has been designed for adaptability: whether the parts that change at different rates have been decoupled, whether there are deliberate seams where change is anticipated, whether the safety-bearing structure is insulated from the changes that will inevitably happen elsewhere. An architecture without these properties may be quiet today and noisy six months from now, when an upstream change cascades through logic that was never designed to absorb it.
The two properties together — projected quietness, and projected durability of that quietness under foreseeable change — are what let you judge whether a workload's operational profile is real or a snapshot. Either one without the other is weak signal. An architecture projected as quiet but rigid will probably not stay quiet; one designed for change but operationally noisy does not earn the deployment in the first place.
Read together, outcome, compliance, and surety give you a way to judge any workload before it is built. They are read together, not separately. A workload with high outcome value and low compliance burden tolerates lighter governance. A workload with moderate outcome value and high compliance burden may require heavier governance than its outcome justifies, which is itself useful signal. A workload whose surety cannot be projected as durable under foreseeable change deserves far more caution than its outcome and compliance standing alone would suggest — and is often one to decline, even when the other two dimensions look strong.
This is the frame. It is not a sophisticated instrument, and that is the point: it can be applied honestly to any workload in your portfolio in less time than the architecture conversation takes to convene, and the answer is usually clearer than that conversation alone suggests.
What the Frame Looks Like Applied
A short illustration makes it concrete. Consider — illustratively, not as a case study — an agent proposed inside an insurer to draft first-pass adjudication rationales for routine claims, with a human reviewing and issuing each one.
Outcome reads high. The agent removes a large share of repetitive drafting from adjusters and frees them for the judgment-heavy cases. Real value, easy to quantify, easy to defend.
Compliance reads satisfiable. Every rationale is reviewed by a licensed adjuster before issue, data handling can be constrained to the necessary fields, and the audit trail is constructible. On paper, this workload is deployable.
Surety is where the reading turns. Projected quietness at launch might be acceptable — the agent drafts plausibly against current rules. But the adjudication rules and the upstream product catalog change every quarter, and the proposed architecture couples the drafting logic tightly to both, with no seam isolating the volatile rules from the safety-bearing logic. The honest projection is: quiet at launch, progressively noisier as each quarterly change cascades through code never built to absorb it. The durability half of surety fails.
The conclusion is not simply "no." It is more useful than that. The notional design names the specific failure: surety cannot be projected as durable as the architecture is currently scoped. That converts the no-go into a fundable condition — go, but only if the architecture is re-scoped to decouple the volatile rules from the drafting logic — rather than a vague misgiving. The decision, and its reasoning, are now legible to everyone in the room.
The Notional Design as Decision Artifact
The frame on its own is a way of thinking. What turns it into a decision instrument is the notional design, and the posture this post argues for is to produce one before committing to production architecture.
A notional design is an architectural sketch — sufficient to test the workload against the frame, not sufficient to build from. It is fast and inexpensive relative to a production design, though "fast" should be calibrated to the workload: a small one can be read in an afternoon, a consequential one takes longer, and overcompressing the work is its own failure mode. Its purpose is to surface what the architecture would have to be, and what it would have to do, to meet each of the three dimensions, and to say honestly whether that is achievable within the envelope available.
The notional design should be produced in an evaluative posture rather than a build-advocacy one. The team that would build a workload has every incentive to find a path to yes; the notional design's job is to read the workload honestly, including toward no. In practice this is a separation of incentive, not necessarily of personnel. The same architectural competence that would build the system can produce the notional design, provided it is engaged to evaluate rather than to sell the build — and where a genuinely independent reviewer is available, that is cleaner still. The principle that matters is that the person reading the workload against the frame is not the person whose quarter depends on it advancing.
What the notional design produces is the artifact you actually need. It names what the architecture would have to look like to meet the workload's compliance burden. It names the failure modes that would drive incidents, and projects whether the architecture can plausibly hold them to a level the deployment context tolerates. It names what kinds of change the architecture would have to absorb gracefully — what is likely to evolve upstream, downstream, or in the model itself, and where the seams need to sit so those changes do not propagate through the safety-bearing structure. And it tells you, with reasoning, whether all of this is achievable — or whether one dimension is not, in which case the workload is correctly a no-go, and you have the document that explains why.
The No-Go Is the Part Most Processes Handle Badly
The no-go is worth pausing on, because it is the part most current decision-making processes handle badly. In many enterprises, workloads that should not advance do not advance — but they do not advance by default. They stall. The pilot does not progress. Resources quietly shift to other priorities. The executive's sense that something was off was correct, but no artifact ever named what was off, so the workload's quiet death looks like reticence rather than judgment. Over time this pattern erodes the firm's confidence that anyone is making good decisions about which workloads to pursue — even when the actual decisions being made are sound.
The notional design converts this. A workload that should not advance gets a document explaining why, read against the frame, with the specific dimension that fails it named. The executive who declines to commission it has a defensible decision with reasoning behind it. The teams who proposed it get an honest answer rather than a silent shelving. Resources that would have gone to a workload that could not have succeeded are freed for workloads where the notional design produces a clear go.
A workload that should advance gets the same artifact with the opposite conclusion. The reading is positive across all three dimensions, the envelope is sufficient, and the document says why. The production architecture work that follows then has a clear strategic frame — what it is trying to achieve, what it must satisfy, what it must stay durable under — rather than having to derive those goals from scratch while also doing the engineering. The production work is faster and clearer because the strategic decision was made first.
The architectural work your teams are doing is necessary, and the firms doing it well are pulling ahead of the firms doing it badly. But that work is downstream of a decision the architecture itself cannot make. Many of the design pressures you are feeling — the difficult tradeoffs being escalated to you, the workloads that look right on paper but feel uncertain, the pilots that pass but do not seem ready — come from teams attempting to architect a workload that the frame would have flagged as a no-go, or as a different proposition entirely, had it been read against the frame before the architecture began.
The mature posture is to design the decision before the system. Produce the notional design for any workload being considered for production, read it against outcome, compliance, and surety together, and let the result tell you whether the production architecture work should proceed. The workloads that earn a go get clearer direction. The workloads that earn a no-go get an honest answer that respects the work that went into proposing them. And the architecture conversation, when it does happen, happens against a strategic frame that gives it shape rather than asking it to invent one.
The next post in this series returns to the architectural conversation — specifically to what one well-articulated architectural approach earns, and where it does not, for the band of workloads where the frame lands toward higher determinism. It also begins to develop the question this post has deliberately left open: not just whether a workload should advance, but what kind of agent the reading actually calls for. That post will read very differently with the frame already in mind.