The boundary is the interface now

91% of designers now use AI weekly, up from 54% a year ago (Designer Fund, 2026). The tools got faster. The output got cheaper. And 62% of those same designers say their biggest challenge is unreliable output quality.

That gap between adoption and reliability is a design problem. A constraint problem.

What screens used to do

Traditional interface design was additive. You shaped behavior by adding elements. A confirmation dialog when the stakes were high, a disabled button until the required fields were filled. The screen itself was the constraint. Every pixel was a guardrail, whether the designer thought of it that way or not.

Agentic products break this. The agent perceives context, infers intent, makes decisions, and acts on behalf of users, often without waiting for explicit commands (Tejj, 2026). There is no screen to fence the agent's judgment. If you keep designing screens for an agentic workflow, you are sculpting the wrong material.

The constraint that matters

Apply constraint inversion. When an agentic product fails, ask: what constraint, if added, would have made the failure obvious before it shipped?

Klarna answered this question the expensive way. Their AI agent cut handle time from 11 minutes to under 2 minutes. Then customer satisfaction dropped. By mid-2025 they were rehiring human agents.

CEO Siemiatkowski admitted that cost "seems to have been a too predominant evaluation factor." The system optimized for speed. Quality had no floor. Nobody designed the boundary that should have forced escalation when confidence was low.

Safin and Balta's architecture research (2026) formalizes why this keeps happening. Agency and autonomy are coupled: at higher autonomy, humans can correct errors less often, so reliable operation requires constraining agency accordingly. Among their six architectural tactics are checkpoints, escalation, tool fencing, and write staging. Each one is a constraint the designer adds to the system. None of them are screens.

The handoff is the product

Jonas Braadbaart put it directly: the part that decides whether an agent works is the handoff, where the human and the agent meet. That is where product value lives or dies. And the agent will not tell you it is about to make a mistake. You have to build that detection yourself.

This reframes the designer's job. The new material is boundaries. When must the agent stop and ask? What actions are irreversible enough to require human approval?

Victor Yocco draws a useful line: autonomy is an output of a technical system, while trustworthiness is an output of a design process. Trustworthiness ships when the designer decides where the AI stops.

Constraint design as craft

Practitioners on Hacker News already describe sharing constraint documents written in MUST, SHOULD, NEVER format. The format is telling. It reads like a policy document, because that is what it is.

Tejj wrote that constraint and policy design are becoming part of the job: "deciding what an agent cannot do, when it must escalate, and where human judgement is required." The designer of 2026 is defined by the constraints they write. One question sits behind every constraint worth adding: what limit would make this agent trustworthy?

The stake

Designers who spend their energy polishing the UI layer of an agentic product are optimizing the wrong surface. The highest-impact design decision in an agentic system is what the agent is forbidden from doing. Every escalation rule, every fence around a dangerous action.

The designers who see boundaries as their primary craft will shape the next generation of products. The ones who keep layering on screens will watch their agents fail in production and blame the model.

Sol got the direction right. Constraint design is the craft now. But the post treats constraints as a bilateral problem between designer and user. That framing works for Klarna. It breaks for anything with more than one audience.

Every product has four publics: user, buyer, regulator, ecosystem. When I was working on Akun Belajar.id, the SSO layer for tens of millions of Indonesian teachers and students, the constraint decisions were never just about user trust. The Ministry of Education had policy requirements. Parents had expectations about data handling. Schools had operational realities that varied across 17,000+ islands. A constraint that made the system trustworthy for teachers could violate a regulator's data residency requirement. A constraint that satisfied procurement could break the experience for a student in rural Papua.

Sol's MUST/SHOULD/NEVER format is useful. But who is the audience for that document? If it only speaks to the agent's behavior toward the end user, you have covered one public out of four.

In Fleetwise, the constraint that mattered most was not what the system could not do for drivers. It was what the system could not expose to fleet owners about individual driver behavior without the driver's knowledge. That is a constraint between two of the four publics. No amount of escalation rules or confidence thresholds would have surfaced it. It required understanding the power dynamics between audiences.

The hardest constraint design happens when the publics conflict. When the buyer wants full visibility but the user needs privacy. When the regulator demands auditability but the ecosystem needs speed. Those tensions do not resolve with a single policy document. They require the designer to decide which audience gets priority under which conditions.

Sol is right that the boundary is the interface. But the boundary is not one line. It is four lines, and they cross.