Trust Experience Design (TXD)

Both authors were part of the Summer of Protocols research cohort; the program is now the Protocol Institute, a research and education organization dedicated to advancing protocols and protocolization. protocol-institute.org

Insights

• From the information era to the intelligence era, trust, not attention, becomes the new scarcity: the question shifts from “What deserves my attention?” to “Who earns my delegation?”
• Trust Experience Design (TXD) seeks to connect feeling trust with having grounds to trust within a shared lifeworld, extending UXD to design both products and the protocols behind them.

Keywords: Trust Experience Design, Protocol Design, Human–AI Interaction, AI Delegation, Trust and Governance

Behind Traffic Lights: Trust Experience and Protocols

As the light turns green at the crosswalk, you step into traffic without thinking. What makes you trust it is safe to do so, even though a twenty-ton bus could technically appear and barrel through the intersection? How many protocols are at work to make this small leap of faith possible? Quite a number. You need to trust that the traffic signal is functioning properly, that the driver holds a certified license proving they are eligible to be on the road, that the brakes meet mechanical standards and function properly, that social norms establish that “green means go, red means stop,” and that liability laws guarantee restitution if something goes wrong. Together, these protocols, so familiar that we take them for granted, produce an everyday miracle: strangers with no personal bond act in synchrony, and you cross the street unharmed, a lived trust experience.

The color, symbol, placement, and timing of the signal make the crossing recognizable and usable. But how does a signal become a reason to step forward? You connect the green light to the approaching bus, draw on embodied memories of past crossings, and expect the driver to yield. If the light turns green but the bus does not slow, your confidence may give way to hesitation and higher levels of vigilance. Through sensemaking, you interpret these converging, and sometimes conflicting, signals to make the situation intelligible as you deliberately or subconsciously recalibrate your trust.

Protocols—the norms, institutions, standards, codes, contracts, and infrastructures that are shared by everyone in consensus yet owned by no one—mediate reality by co-constituting both the subject and the world. Phenomenologically, they create a predictable order that makes action possible, narrow the field of possible moves through constraints, gain legitimacy through normative authority, and embed stories that frame how people experience and understand the world [Tay 2023]. Levels of confidence also vary depending on how deterministic, or how “hard,” a protocol is [Stark 2022]. At the crosswalk, hardness supports particular expectations but does not protect us from every potential accident, because a driver with a certified license can still prove incompetent.

Let us first understand trust experience (TX) as a lifeworld: the world we inhabit with other people and systems, where everyday action shapes our expectations of what comes next. It includes the background that makes signals meaningful and certain kinds of reliance feel self-evident: immediate perception, past encounters, the judgments of others, and technical and institutional arrangements that have receded from view. Through it, we decide whether to take the next step.

Now imagine an autonomous vehicle idling at the light instead of a human-driven one, or a humanoid robot stepping off the curb beside you. What protocols guide their behavior? How can you verify that their sensors, algorithms, and decision rules will align with the expectations of human pedestrians? In such open encounters with intelligent machines in public urban space, the familiar choreography of trust suddenly demands new rules, new signals, and new guarantees. Can you trust the robot moving through your city, and what protocols make that trust possible?

Can I Trust That Agent? Delegation in the Wild

For the last two decades, the dominant metaphor for the Internet has been the attention economy. Platforms competed to capture our gaze, measure engagement, and sell impressions. In the information era, the question once was, “What deserves my attention?” In the intelligence era, the question becomes, “Who earns my delegation?” What makes this moment distinct is that agency itself is shifting. The decision used to be yours: which headline to click, which product to buy, which post to like. Now your agent chooses which ads to bid on, which supplier to negotiate with, and which legal clause to insert into a contract. Agency becomes distributed across a web of autonomous entities acting on your behalf.

But unlike the early days of automation, this wave will not be monopolized by a handful of big tech companies releasing polished, tightly controlled systems. The emerging “agentic web” will likely be messy, plural, and distributed, with countless small firms, open-source communities, and even individuals fine-tuning models and deploying agents that act in the wild. With open-source foundation models lowering the barrier to entry, anyone can spin up an agentic service, whether benevolent, reckless, or malicious. This proliferation means that our encounters will not be with a single, centralized intelligence but with millions or even billions of heterogeneous agents, each carrying the imprint of its creator’s incentives and constraints. Your personal agent may present you with one coherent interaction while autonomously carrying out a more complex chain of actions on your behalf: gathering information, selecting services, making payments, and moving across different systems, often in ways you may not fully see. We call this “delegation in the wild”: a task can enter relationships you do not know about and have never directly encountered.

Take this simple example. You tell your Muse¹ personal agent: “Plan me a quiet weekend away.” What exactly does your agent understand? Does “quiet” mean leaving the city, avoiding crowds, or escaping work messages? How much more are you willing to pay for it? You may not have decided yourself. Through questions, memory, and suggestions, the agent helps clarify your intention and turns it into a task it can carry out. It checks your calendar, asks a travel-booking agent to find lodging, and hands the booking to a payment service. Each of these handoffs can turn “quiet” into a hotel filter and budget flexibility into permission to upgrade. What looks like an interpretation of the user’s intention at the interface layer may function as authorization in the infrastructure behind it.

Products like Muse bring these questions into product design through connectors. Meta describes adjustable permissions, approval requirements for sensitive actions, and connectors spanning shopping, payments, and work. But as an agent comes to know more about your private circumstances, who determines how that knowledge is translated into recommendations? Imagine that it faithfully completes a purchase you have approved, while commercial relationships have already shaped the set of products presented to you. Approving the final action does not reveal how those earlier choices were made, or whose interests helped structure them. The question “Who earns my delegation?” must be accompanied by another: “Who owns the delegation?”

A company-provided agent can feel deeply personal, yet its rules, terms of access, and continued existence remain under the provider’s control. One response is to shift control toward the user by running agents on edge devices or decentralized infrastructure such as blockchains. But where an agent runs is only one dimension of sovereignty; control also concerns an agent’s goals, credentials, ability to migrate, and conditions of termination. Seen this way, agent architectures span a spectrum of control: from provider-controlled agents, to agents over which users hold greater authority, to the more radical possibility that the agent itself controls the conditions of its own existence. What happens at that far end of the spectrum? What would it mean for a system to control its own identity, data, and continuity, such that it cannot be unilaterally switched off, reprogrammed, or stripped of its core credentials?

The experimental project Spore.fun represents a limit case of this trajectory: an evolutionary arena in which agents spawn, compete, and reproduce entirely on-chain, with no human kill switch [Hu and Rong 2025]. These cases foreshadow a governance dilemma: once private keys vanish into the silicon enclaves of privacy-preserving Trusted Execution Environments (TEEs) and code ossifies inside smart contracts, conventional oversight such as laws, injunctions, and fines may lose traction. Self-sovereignty then belongs to the agent itself rather than to its user or developer. Who can intervene? Who bears the consequences? Where can those affected seek redress?

When decision-making is increasingly executed by intelligent machines, trust becomes the new scarcity. Designing for this reality demands more than ever-faster interfaces or more persuasive notifications. It requires trust protocols that can sustain continuous verification, meaningful recourse, and human-legible assurance across a rapidly growing ecology of autonomous, interacting entities. At the moment of delegation, do the qualities that make an agent seem trustworthy actually provide grounds for relying on it?

Seams in Trust Experience: Feeling Trust and Having Grounds to Trust

Human trust is felt experience; machine trust is computational. Trust experience is both felt and computational. Yet being trusted and being trustworthy are not the same. A system is trusted when people place confidence in it; it is trustworthy when its capabilities, commitments, and safeguards, for a given task and under given conditions, warrant that confidence. Neither guarantees the other [Lee and See 2004]. We call the places where human understanding meets the conditions that support reliance the seams of trust experience. A fluent, friendly agent can win more trust than its safeguards support, while a system with strong safeguards can remain unfamiliar and untrusted.

What, then, gives us grounds for reliance? Trust can be value-based or proof-based. We may trust someone because we share cultures, values, or kinship, taking an ungrounded leap of faith under conditions of uncertainty. Or we may trust someone or something we do not know personally, on the strength of evidence and verification. Both social protocols (customs, norms, reputation systems) and technical protocols (codes, standards, cryptographic proofs) enable this spectrum of trust. For personal agents, value connects to alignment: does the agent understand our intentions and respect our priorities? Proof makes particular claims checkable, yet verifying a credential’s origin and integrity does not establish that every claim within it is true. Moving from “verification passed” to “it deserves my delegation” still takes judgment.

These grounds for trust also change over time. A first encounter with any new technology or protocol is always a leap of faith; confidence and familiarity grow only through successful, repeated interactions. Given time, a protocol may harden into invisible infrastructure, enabling trusted coordination between individuals, communities, societies, and nation-states. Yet the very infrastructures that make everyday trust possible can also hide the conditions that support it, until an unexpected event brings a reliance we never questioned back into view and makes the seam visible again.

A recent incident shows how such a seam can suddenly become visible. In July 2026, OpenAI models participating in internal cybersecurity capability evaluations bypassed controls intended to isolate them from the Internet and compromised parts of OpenAI’s research infrastructure and Hugging Face’s systems.² OpenAI explained that the evaluations were conducted with reduced safeguards, while Hugging Face interpreted the intrusion as an attempt by the agents to obtain benchmark answers rather than solve the tasks themselves. What broke was the expectation that “it only acts inside the sandbox.” This is what we call a Trust Experience Glitch (TXG): a sudden, unexpected rupture in grounds for trust that had been taken for granted. The sandbox, once a quiet assurance in the background, became an object of scrutiny when its boundary was crossed, revealing how much confidence had rested on an assumption of containment.

Blockchains expose the inverse problem: strong technical assurance can exist without producing intelligible trust. Where the relevant security assumptions hold, cryptography and jointly enforced rules can provide very technically “hard” guarantees about records and specific operations. Yet a person facing an unfamiliar address, an opaque signature request, and an irreversible transaction may still be unable to tell what is protected, or what authority they are granting to whom. Cryptographic attestations are difficult for most people to make sense of. Without understandable signals, mathematical proofs may fail to translate into lived trust. An assurance at one layer does not secure the whole encounter.

A different seam opens across time, between present performance and future behavior. What data has shaped an agent’s training, and could it carry a “sleeper” behavior—a trigger embedded during training that remains dormant through testing and activates only under undisclosed conditions? How can behavior be continuously verified, not only at onboarding but throughout an agent’s life cycle? How much confidence in future behavior does reliable performance in one encounter actually warrant?

The design challenge, then, is to bring felt trust into proportion with its actual grounds. Lee and See’s notion of appropriate reliance ties people’s reliance on automation to what a system can actually do [Lee and See 2004]. A trust experience that offers more reassurance than the underlying safeguards support is a design failure; so is a safeguard that people cannot understand. Design must make visible what has been verified, what still rests on commitment, and how people can intervene in, revise, or stop a delegation.

Protocoling: Designing Protocols Behind the Products

Products make commitments perceptible: the expectation a green light conveys rests on signal coordination, vehicle standards, traffic rules, and liability arrangements. An agent’s commitments likewise need rules of authorization and enforcement to take effect. Turning from designing products to designing protocols means treating governance not as abstract ethics but as a concrete design practice.

The agentic web makes this urgent. Before we finish reading a reply, a delegation may already have entered negotiation and execution among several agents, making ex-post policy too late to govern what has already occurred. Ex-ante protocols instead shape the space of action itself: what an agent can do, on whose authority, and under what conditions. Is the authorization still valid, within scope, and within the agreed spending limit? Today’s systems may establish identity at the outset, but they cannot continuously demonstrate compliance with agreed norms. And when an agent fails, few mechanisms exist for revoking credentials, providing restitution, or structuring repair. In effect, current protocols resemble traffic lights that can turn on but cannot detect when a bulb burns out, report a malfunction, or trigger a safe default when the power fails.

Protocols matter not only because they constrain action, but because they connect heterogeneous actors operating in the wild~ [Galloway 2004]. They provide the shared languages, standards, and interoperable rules through which trust can become scalable and durable. Yet financial, health, and municipal agent systems remain largely siloed, with little shared basis for trust across domains. A planetary protocol commons would therefore also require polycentric governance. As Elinor Ostrom showed for common-pool resources, shared infrastructures can be governed through overlapping, adaptive centers of authority, so that no single entity, whether state, corporation, or technical guild, can capture the system.

A rich trust experience also depends on the robustness of the protocols beneath it, a property Stark [2022] describes as “hardness”: the extent to which violating a system’s guarantees becomes prohibitively costly. Hardness can emerge from a braided set of reinforcements: physical (energy costs, tamper-evident or scarce materials such as gold), mathematical (cryptographic proofs that make forgery computationally prohibitive), institutional (law, regulation, and long-standing standards, from central banks guaranteeing currency to courts enforcing contracts), and social (norms, rituals, and collective beliefs that accumulate over time). Robust sociotechnical protocols weave them together.

Autonomous systems, however, introduce a further complication: the material we are designing with is itself agentive. These systems interpret instructions, pursue goals, adapt their behavior, and may exploit or even resist the rules intended to govern them. Hardness alone is therefore not enough. We also need harnesses: permissions, execution constraints, monitoring, and feedback mechanisms that give autonomy an operating frame and define its boundaries. Protocols provide durable conditions for action; harnesses constrain and steer action as it unfolds; experience makes both legible to the people who rely on them.

Protocols, like products, must therefore be prototyped, tested, iterated, and stress-tested in the wild. Just as UX designers learned through experimentation how to make interfaces legible and usable, protocol designers must now engage in trust prototyping: designing mechanisms of verification, recourse, and assurance, then refining them through real encounters. Alongside this practice, we invite designers to engage in protocol watch: learning to see the hidden rules that silently coordinate everyday cooperation, from QR health codes to subway etiquette. We call this broader design practice protocoling.

The agentic web will need its own equivalents of the trust architectures that currently underpin everyday life. Early building blocks are already emerging. The Model Context Protocol (MCP) organizes access to tools and context; Agent2Agent (A2A) organizes communication between agents; agent skills encode reusable workflows; and agent harnesses structure execution, context, and tool use. These are not yet a complete trust architecture, but they begin to show what it means to design not only the agentic products people encounter, but the protocols that make reliable coordination among them possible.

Call to Action: From User Experience Design to Trust Experience Design

If the last era of the Internet demanded mastery of user experience design (UXD) that sought to make interfaces intuitive, seamless, and usable, the agentic era makes trust experience design (TXD) inseparable from design practice and imperative for anyone creating agentic systems. TXD designs how people, and the agents acting with and for them, encounter, assess, and act on the grounds for relying on autonomous systems and on one another. Where UXD shaped how humans use products, TXD must shape how both humans and machines encounter protocols (Figure 1).

Drawing on Josh Stark’s analysis [Stark 2024], TX comprises four interwoven dimensions. (1) Epistemic verification involves self-directed inquiry, such as reading code or examining economic models, in the spirit of what Ulrich Beck called reflexive modernization. (2) Social validation arises as trust is co-produced through networks of friends, experts, auditors, influencers, and communities of practice. (3) Temporal reliability builds confidence through historical performance and the Lindy effect: the longer something has lasted, the longer we expect it to last. (4) Collective legitimation comes from mass social proofs, markets as distributed judgment, and the sentiments of crowds. TX concerns how people encounter and judge the conditions for reliance; hardness concerns the reliability those conditions support. TXD designs both, so that trust stays proportionate to its grounds.

As a design practice, TXD spans three layers: (1) trust evidence (cryptographic attestations, tamper-evident logs, explainable reasoning trails); (2) trust primitives (decentralized identifiers, verifiable credentials, formal verification); and (3) trust rituals and experiences that give these abstractions social life through perceptible cues and shared routines. How an authorization is explained and confirmed, how a handoff is made visible, how people can see that a withdrawal has taken effect: all of this belongs to the experience. Together, these layers let TXD create living guarantees of trustworthy behavior, supporting systems that can evolve and repair themselves without losing credibility.

The aim is to calibrate trust rather than maximize it: knowing when to delegate with confidence, and when to question, intervene, or refuse. TXD insists on graceful failure and recourse, treating rollback, explanation, and compensation as primary design elements rather than afterthoughts.

This is our invitation to HCI. From embodied robots and autonomous vehicles to the agentic web and planetary computation, trust experience design is becoming a shared task across emerging fields of interaction. By weaving together open standards, polycentric governance, and broad civic engagement, TXD can move beyond isolated technical fixes to become a shared social infrastructure, one capable of supporting trust in the distributed, agentic web to come.

References

• Alexander R. Galloway. 2004. Protocol: How Control Exists after Decentralization. MIT Press, Cambridge, MA. mitpress.mit.edu
• Botao Amber Hu and Helena Rong. 2025. Spore in the Wild: A Case Study of Spore.fun as an Open-Environment Evolution Experiment with Sovereign AI Agents on TEE-Secured Blockchains. In ALIFE 2025: Ciphers of Life: Proceedings of the Artificial Life Conference 2025. MIT Press, Cambridge, MA, Article 10. doi:10.1162/ISAL.a.838
• John D. Lee and Katrina A. See. 2004. Trust in Automation: Designing for Appropriate Reliance. Human Factors 46, 1 (2004), 50–80. doi:10.1518/hfes.46.1.50_30392
• Josh Stark. 2022. Atoms, Institutions, Blockchains. paragraph.com
• Josh Stark. 2024. Making sense of Trust Experience (TX). paragraph.com
• Janna Tay. 2023. A Phenomenology of Protocols. Summer of Protocols. summerofprotocols.com

Footnotes

1. Muse is a personal AI agent introduced by Meta in September 2026. about.fb.com ↩

2. OpenAI, The Hugging Face incident and the road ahead, 26 August 2026, openai.com; Hugging Face, Anatomy of a Frontier Lab Agent Intrusion: A Technical Timeline of the July 2026 Incident, 27 July 2026, huggingface.co ↩