Designing human-agent relationships through trust architecture. The structural material of agentic AI and the foundation of AXD..
| Dimension | Traditional UX | Agentic Experience Design (AXD) |
|---|---|---|
| Primary material | Attention and affordance | Trust and delegation |
| User state | Present, navigating | Absent, delegating |
| Design output | Screens and interfaces | Outcomes and constraints |
| Temporal model | Session-based | Relationship-based |
| Success metric | Task completion | Trust calibration |
Trust architecture is the structural design of how trust is established, maintained, calibrated, and recovered in human-agent relationships. It is the foundational design discipline of AXD, treating trust not as an emergent property but as a designed system with specific components, interfaces, and failure modes.
Trust architecture comprises: trust formation mechanisms (how initial trust is established), trust calibration systems (how trust levels are adjusted based on evidence), trust maintenance protocols (how trust is sustained during normal operation), and trust recovery procedures (how trust is rebuilt after violations). Each component requires deliberate design.
Traditional security design focuses on preventing unauthorised access through authentication and authorisation. Trust architecture goes further: it designs the ongoing relationship between human and agent, including how trust evolves over time, how the agent earns greater autonomy, and how the system recovers from trust violations. Security is a component of trust architecture, not a substitute for it.
Trust architecture is the structural design of how trust is established, maintained, calibrated, and recovered in human-agent relationships. It is the foundational design discipline of AXD, treating trust not as an emergent property but as a designed system with specific components, interfaces, and failure modes.
Trust architecture comprises: trust formation mechanisms (how initial trust is established), trust calibration systems (how trust levels are adjusted based on evidence), trust maintenance protocols (how trust is sustained during normal operation), and trust recovery procedures (how trust is rebuilt after violations). Each component requires deliberate design.
Trust in agentic systems is not a feeling. It is not a brand attribute, a design flourish, or a user sentiment captured in a post-task survey. Trust, in the context of autonomous AI agents, is an architecture - a structural system with layers, load-bearing elements, stress tolerances, and failure modes that can be designed, tested, and maintained with the same rigour that engineers bring to the physical structures we inhabit. This essay argues that trust architecture is the foundational discipline of The metaphor of architecture is not decorative. It is precise. A building's architecture determines what the building can support, how it distributes load, where it flexes under stress, and how it fails when its tolerances are exceeded. Trust architecture in agentic AI serves exactly the same function. It determines the scope of authority a human will grant to an agent, how that authority is distributed across different domains of action, where the system flexes when unexpected situations arise, and how the relationship degrades - or recovers - when trust is violated. In traditional user experience design, trust was an outcome - something that emerged from consistent, clear, well-branded interactions over time. A user trusted an application because it worked reliably, looked professional, and did not surprise them. Trust was important, but it was not structural. A failure of trust meant a user might leave the product or choose a competitor. The consequences were commercial. In agentic systems, trust is structural because it directly determines what the system is permitted to do. The level of trust a human places in an autonomous agent defines the agent's This structural role means that trust cannot be left to emerge organically. It must be designed. And because it has layers, dependencies, and failure modes, it must be designed as an architecture - not as a single feature, a toggle, or a sentiment. The Carnegie Mellon Software Engineering Institute has identified six di