Designed to Render (How)

Designed to Render (How)

A standalone third companion to The Chain of Trust (What) and The Dirty Pool (Why).


An AI assistant surfaces an answer with total confidence, clean formatting, reasonable tone, and plausible citations. The interface looks great, but the output is wrong. And the user, seeing nothing to flag distrust, acts on it. The interface did its job.

New study warns of risks in AI chatbots giving medical advice |
The largest user study of large language models (LLMs) for assisting the general public in medical decisions has found that they present risks to people seeking medical advice due to their tendency

The substrate had already failed. The user had no way to see that, because the interface is designed to render output, full stop.

A quick orientation

If you haven't read The Chain of Trust, the short version is that AI systems have three distinct layers, and trust has to hold at each one for the system to be reliable.

Action is what the system does in the world. File writes. API calls. Emails sent. Calendar blocks set. The layer where AI crosses from output into consequence, and where reversibility stops being free.
Reasoning and Delivery is where value lands. The model interprets, synthesizes, and presents. This is the layer users see. Tailored insights. Human-readable output. The layer designers spend most of their time on.
Substrate is where the data lives. Is it correct? Is it legible to the system? Is it grounded in the actual conditions of use? This is where errors compound silently. A bad substrate will produce confident wrong answers all the way up the stack.

The governance argument in The Chain of Trust is that most accountability frameworks engage only after something has already gone wrong at the Action layer. Most interfaces render the Reasoning and Delivery layer and leave the Substrate and Action layers invisible to the user. That asymmetry is feels like a poor a design choice - offering little explainability nor exact repeatability in the wild.

Hallucinations in LLMs Are Not a Bug in the Data | Towards Data Science
It’s a feature of the architecture

"When a LLM hallucinates, the internal representation does not go blank. It rotates. Both paths — correct and incorrect — travel the same distance through the model’s representation space. What separates them is direction, not magnitude. The geometry is telling you something the output logits cannot: the model knew where the right answer was. It went somewhere else." - Javier Marin

Every UI pattern we've built for AI products, the chat window, the confidence percentage, the streaming text, the suggested follow-ups, lives at Reasoning and Delivery. That's where the interface is richest. It's also the layer where trust is displayed. Trust is built at the Substrate and spent at the Action layer. The interface, for the most part, skips both.

What a harness actually is

An agent harness is the scaffolding that wraps an AI agent, the permission set it operates within, the tools it has access to, the interrupt surfaces where a human can step in, and the boundaries that determine what the agent can do without asking first. It's the governance layer made operational. Which means it's also, unavoidably, a UX problem.

Most discussions about harnesses stay on the infrastructure side, how to configure tool access, how to set up sandboxing, how to chain agents together safely. Those things matter. But the harness is also the primary interface between the agent and the user's trust. How you design it determines what the user can see, what they can interrupt, and whether they understand what they consented to.

Two implementations worth looking at

AG-UI (Agent-User Interaction Protocol) is an open standard built from practical experience rather than theoretical design. It emerged from CopilotKit's work with LangGraph and CrewAI, and the priorities are legible in the spec.

AG-UI is event-driven. While an agent runs, it emits a stream of structured events: text chunks, tool calls, state changes, reasoning steps. Tool orchestration can pause for human approval on sensitive operations, preserving session context across the interruption. The internal reasoning layer is separated from the public output, so builders can choose how much of the agent's thinking process to surface based on their UX needs. It gives you the mechanisms to implement the right level of transparency for your context, calibrated to your UX needs rather than forced to full disclosure. That's a design-aware choice, and it's structural to the protocol.

In SRA terms, AG-UI surfaces activity at the Substrate (what data and tools are being accessed), makes Reasoning visible as a progressive stream rather than a finished artifact, and treats the Action layer as a boundary requiring explicit crossing.

However, the limitations are real. In my prototype, I've noticed performance issues loading due to large shared state objects that get heavy. It brings an infrastructure immediately to the forefront of its pre-requisites, so for being in a prototype phase it may feel excessive. The documentation also assumes you already understand agent architecture reasonably well. It's a practitioner tool, built for builders (and my buddy Claude).


AutoGPT is an instructive counterexample. The project was genuinely pioneering, and the ecosystem has matured considerably since 2023. The original design reveals where agentic UX defaults go when the interface is a secondary consideration.

AutoGPT's interaction model was simple: give it a goal and watch it run. The agent decomposed tasks, browsed the web, wrote files, executed code, and generated its own prompts. The interface showed you that it was doing things. What it kept opaque was the substrate it was operating on, the actual permission boundaries, and where the cost of an action was being incurred. Early adopters reported loops, stalls, and fragile execution, because without substrate visibility, there was no way to diagnose why a confident-looking agent was spinning.

Allow human input · Issue #779 · Significant-Gravitas/AutoGPT
Duplicates I have searched the existing issues Summary 💡 A new command “Ask for input or clarification” - if running autonomously could stop and wait a specified number of seconds before going on b…

The Action layer was the specific failure point. Actions happened in the background. Reversibility was an afterthought. Human approval gates were either absent or bolted on as CLI confirmations that broke the interface flow rather than integrating into it.

What this produced was a system where trust had to be total or nothing. Either you let it run and hoped, or you interrupted it and lost context. There was no middle layer or graduated control. I imagine this clashes directly with how humans earn trust - over time, through interaction. Expecting this boolean behavior in humans is why this is a great counterexample to AG-UI.

The Action layer is the one that matters

The Action layer is where agentic systems cross from generating output into having consequences. An agent that generates a grocery list and shows it to you is operating at Reasoning and Delivery. An agent that sends the email is operating at the Action layer. The difference is irreversibility.

Interface design for agentic systems needs a coherent theory of reversibility. Which actions are reversible, at what cost, and for how long? What does the interface communicate about that before the action happens? What does the harness expose to the user before the boundary is crossed?

What the interface owes the user

The substrate question is whether the user can see the conditions under which this output was generated. Is it grounded in something useful, something validated, something that is contextualized?

💡
Data provenance is a trust affordance.

When an interface surfaces it, users can calibrate their trust to the actual quality of the substrate. When it hides it, users have no basis for calibration, and tend to default to either blanket trust or blanket skepticism. The reasoning question is how much of the agent's thinking process should be visible, and when.

This is context-dependent. Sometimes you want the full thought log; sometimes a clean summary with an expand option is the right call. The design requirement is that reasoning be available as normal operating texture, accessible during the work, not surfaced only in error states as a diagnostic tool.

The action question is what it costs to proceed, and who bears that cost. The interface has to communicate the scope of an action, its reversibility, and what "undo" looks like, if it exists. At the point of commitment. Inline, in context, before the boundary is crossed.

These are established design principles, progressive disclosure and consent flows have been in the toolkit for decades. What agentic systems add is consequence. Higher stakes, worse defaults, and a much shorter window between action and irreversibility.

A standalone third companion to The Chain of Trust (What) and The Dirty Pool (Why).

Subscribe to Of Hearts and Minds

Don’t miss out on the latest issues. Sign up now to get access to the library of members-only issues.
jamie@example.com
Subscribe