Constraint as design.

Walk through the typical AI safety architecture and you'll see the same shape repeated: capable model in the middle, constraints arranged around it. The constraints are the wrapper. The model is the value. The constraints exist because the value, unconstrained, would do things you don't want.

This is how most teams think about alignment. It is also wrong.

This post is about the difference between alignment as a wrapper and alignment as architecture — between treating the constraint as a tax you pay to ship the capable system, and treating the constraint as the shape of the capable system itself. The first framing predicts every alignment failure mode we currently see in production. The second is harder to design and impossible to bolt on later, which is why almost nobody does it.

I want to argue the second is the only one that holds at runtime.

The wrapper school

The standard alignment stack has three layers. Each layer is structurally a wrapper.

Training-time. RLHF, constitutional AI, preference optimization. You take a base model and tune its weights so that, on a distribution of prompts it might see, its outputs look more like outputs humans approve of. The base model — the capability — is still the thing. The tuning is a layer of correction applied to it.

Instruction-time. The system prompt. "You are a helpful assistant. Do not produce harmful content. If asked about X, refuse." Tens of thousands of tokens of negotiated instruction, often longer than the actual user query. The model in the middle is whatever weights came out of training. The system prompt is a wrapper around the call to it.

Inference-time. Output filters. Refusal classifiers. Safety models that read the assistant's response and decide whether to ship it. Sometimes a second LLM call to a "guard" model to grade the first call's output. Wrapper around the output of the wrapper around the call to the model.

Three layers, three wrappers. Each one is added because the previous one is known to be insufficient. The architecture admits, in its structure, that no individual layer holds. And yet the layers keep getting stacked, because the alternative — building something whose shape is the constraint — is much harder than wrapping a capability you already have.

Why wrappers fail at runtime

Three failure modes, all of them familiar to anyone shipping agent systems.

The first: training-time constraints are invisible to the model's loss landscape. When you RLHF a model, you're not teaching it the constraint. You're shifting its output distribution on a sample of cases where the constraint was demonstrated. The model doesn't learn "do not produce harmful content." It learns "given prompts that look like the ones in my preference data, prefer outputs that look like the ones humans rated up." Off-distribution, the constraint doesn't exist. Jailbreaks are not bugs in the wrapper; they are evidence that the wrapper is not the thing it pretends to be.

The second: wrappers only see outputs, not intermediate reasoning. A refusal classifier reads the final assistant message. It doesn't see the chain of thought, the tool call sequence, the intermediate planning steps. Mesa-optimization — when a model develops internal goals that diverge from the training signal — is invisible to output filters by construction. The model produces a normal-looking output. The reasoning that produced it had a goal you didn't sanction. The wrapper, watching only outputs, sees nothing wrong.

The third: single-layer wrappers vs multi-decision systems. Agent loops are not single-call systems. An autonomous agent on a thirty-step task makes thirty decisions, each of which could be the one that breaks something. A wrapper at the edge — at the final output — sees the result of all thirty decisions composed. By then, twenty-nine of them have already produced effects in the world. The wrapper that sees only the final response is wrapping the wrong unit. The unit is each decision, not the trajectory.

This is the structural pattern. The wrapper assumes a single point of contact with the world. Modern AI systems do not have a single point of contact. They have a flow.

The architectural alternative

Consider what it would mean for the constraint to be the system.

In Stripe Radar — the fraud system most often used as the analogy for what we're building — fraud detection is not a wrapper around payments. It is not a layer that sits over the payment graph reading bytes as they go past. It is the structural shape of how the payment system processes a transaction. Risk evaluation happens at every decision boundary: card-issuer call, address verification, velocity check, network signal. The constraint is distributed across the architecture. Removing any layer doesn't reveal a "real" payment system underneath; it produces a different payment system, one that processes different transactions.

You could not build Stripe Radar as a wrapper. The information needed to classify risk arrives at different layers and gets used by different layers. The right place to check velocity is not the place to check geographic mismatch. The architecture of risk evaluation is the architecture of payments, in any production-grade system.

This is the model. Translate to AI.

A system aligned by architecture has constraints baked into the boundaries between its components. Each interface between two agents, between two tiers of a planning hierarchy, between a reasoning step and a tool call, is itself a constraint. The shape of the data that passes from one component to the next is the form alignment takes at that boundary. Not "the model produced this, and we filtered it." But "the next component cannot see this until the previous component has shaped it into a form the next component can act on."

There is no edge where alignment happens. There is only the topology of the system, designed such that the constraints are the structure.

Three properties

What does this look like in practice? Three properties characterize architectural alignment, in contrast to wrapper alignment.

Distributed. Constraints exist at every tier transition, not just the input and output. A planning agent that hands a sub-task to an execution agent passes constraints in the handoff: scope of authority, irreversibility budget, escalation conditions. The execution agent that calls a tool passes constraints in the call: what the tool can return, what side effects it can produce, what gets logged. Each boundary is its own enforcement point. Removing any one of them doesn't produce a less-constrained system — it produces a system that fails differently.

Structural. The shape of the data passed between tiers is itself the constraint. Not "we filter the message after the agent writes it." But "the message format the agent is allowed to write does not have a field for the thing we don't want it to do." If you want to prevent an agent from sending arbitrary emails, you don't add a refusal classifier on top of its email tool. You design the email tool so that send requires a recipient on a pre-approved list, a subject from a controlled vocabulary, and a body that has been classified by a separate, non-agent process. The data type makes the unsafe action unrepresentable.

Multi-tier. Each layer's job is to make the next layer's job tractable. The planner's job is not to plan — it is to produce plans the executor can safely execute. The executor's job is not to execute — it is to execute in a way that produces outputs the validator can safely validate. Every component is designed in service of the component downstream of it. The reason you can trust the bottom of the stack is that everything above it has been designed to make the bottom of the stack's job possible.

This last point is the deep one. Architectural alignment inverts the usual hierarchy. The lowest, most concrete, most executable tier is not the bottom of the system. It is the reason for the system. Every layer above exists to make execution at the bottom tractable, safe, and faithful to the original intent. Governance flows downward to enable execution, not upward to constrain it.

What this means for builders

If you accept this framing, several things change.

You stop designing the model first and the guardrail second. You start with the protocol — the boundaries between components, the data shapes that flow across them, the conditions under which a component is allowed to act. The model is what fills in one slot in that architecture. It is not the architecture.

You stop hoping that RLHF will catch the cases your spec didn't anticipate. RLHF is a method for shifting a model's output distribution on the cases you trained it on. It does not generalize the way you hope. If you want a constraint to hold off-distribution, the constraint cannot live in the weights of the model that's optimizing against it. The constraint has to live in the protocol the model is acting within.

You stop adding wrappers when you see failures. The third wrapper is not going to fix what the first two didn't. The failure is structural, not parametric. The answer is to redesign the boundary, not to add another layer.

And you stop thinking about "alignment" as something separate from "system design." There is one thing. The system is the architecture. The architecture is the constraint. There is no leftover capability hiding underneath, waiting to be wrapped.

What architectural alignment costs

The honest cost is that this is much harder than wrapping. Bolting a refusal classifier onto an existing model takes a week. Designing a multi-agent system whose interfaces are themselves the alignment artifact takes the entire project. You cannot retrofit it.

You also lose some flexibility. A capable, unwrapped model can in principle do anything you can prompt it to do. A model that lives inside a tight protocol can only do what the protocol permits. For most consumer applications, that's a feature. For systems where you actually want the agent to handle the long tail of cases you didn't anticipate, it's a real constraint on what you can ship.

But the long tail is also where the unrecoverable failures live. Every dramatic agent failure I have seen in production was a case the wrapper had not been trained for and could not anticipate. The cases that the system handled poorly were the cases that the system had never been designed to handle. Architectural alignment doesn't make those cases go away. It makes the system refuse to act on them, instead of acting on them badly.

The harder claim

There is a stronger version of all this that I'll only gesture at here.

The wrapper framing assumes a clean separation between the capable system and the constraint applied to it. There is a "raw model" inside, and there is "alignment work" applied on top.

I don't think that separation is real, even in principle. The capabilities of a system are a function of the architecture that produces them. There is no "model" that exists prior to and independent of its training distribution, prompt scaffolding, tool interface, and protocol context. What you call the model is already the composite of all of those. There is no underlying capability waiting to be wrapped — the capability is the wrapping.

This is hard to internalize because it cuts against how the field talks about models. We say things like "GPT-5 can do X" as if X is a property of the model. But what we actually mean is that a particular prompt, scaffolding, and protocol context can elicit X from GPT-5 — and that swapping any of those out can make X go away. The capability is inseparable from the architecture that exhibits it.

If that is true, then alignment is not work performed on top of capability. It is the same work as capability work, viewed from a different angle. The architecture that makes the system do useful things is the architecture that makes the system not do harmful things. You cannot have one without the other.

Closing

We argue this at greater length in The Generative Limit, one of the foundational essays in our depth series. The version there is more structural and draws on a particular intellectual tradition; the version here is the engineering translation of it.

But the core claim is the same: stop designing the model first and the constraint second. Design the boundaries first. The architecture is the alignment. Everything else is plumbing.