Principles

Start here

How to read and apply the Blueprint principles to real product decisions.

What the principles are

The Blueprint principles are decision rules, not guidelines. Each one resolves a recurring design tradeoff in agentic AI products — between autonomy and control, between speed and reversibility, between transparency and simplicity. They are organized into four clusters: delegation, visibility, trust, and orchestration.

How to read them

Start with the cluster overview to understand the design problem each cluster addresses. Then pick the 3–5 principles most relevant to what you are building. Read each principle as a constraint first, not a feature. Ask: what would break if I ignored this? That surfaces the real tradeoff.

Where to start by role

Designers: begin with the visibility and trust clusters — these shape what the agent shows and when. Engineers: start with delegation and orchestration — these define what agents can decide and coordinate. Both roles: the review guide walks through applying principles to a real feature before shipping.

Delegation

Principle 1delegation

Design for delegation rather than direct manipulation

Design experiences around the assignment of work, the expression of intent, the setting of constraints, and the review of results, rather than requiring users to execute each step manually.

Principle 5delegation

Replace implied magic with clear mental models

The product should help users understand what the system can do, what it is currently doing, what it cannot do, and what conditions govern its behaviour.

Principle 10delegation

Optimise for steering, not only initiating

The system should support users not only in starting tasks, but also in guiding, refining, reprioritising, and correcting work while it is underway.

Visibility

Principle 2visibility

Ensure that background work remains perceptible

When the system is operating asynchronously or outside the user’s immediate focus, it should provide persistent and proportionate signals that work is continuing.

Principle 3visibility

Align feedback with the user’s level of attention

The system should calibrate the depth and frequency of feedback according to whether the user is actively engaged, passively monitoring, or temporarily absent.

Principle 6visibility

Expose meaningful operational state, not internal complexity

Present the state of the system in language and structures that are relevant to the user, rather than exposing low-level internals that do not support action or understanding.

Trust

Principle 4trust

Apply progressive disclosure to system agency

Provide the minimum information necessary by default, while enabling users to inspect additional detail when confidence, understanding, or intervention is required.

Principle 7trust

Establish trust through inspectability

Users should be able to examine how a result was produced when confidence, accountability, or decision quality is important.

Principle 8trust

Make hand-offs, approvals, and blockers explicit

When the system cannot proceed, the reason should be immediately visible, along with any action required from the user or another dependency.

Orchestration

Principle 9orchestration

Represent delegated work as a system, not merely as a conversation

Where work involves multiple steps, agents, dependencies, or concurrent activities, it should be represented as a structured system rather than solely as a message stream.

Also in this section

For designers For engineers Review guide