Principles

For product managers

Which Blueprint principles matter most for governance, approval design, and rollout decisions in agentic products.

Approval boundaries are product decisions

PMs own the approval model: which actions require explicit confirmation, which can proceed autonomously, and what triggers an escalation. The trust cluster defines when the product must stop and ask, and what form that ask should take. Getting this wrong generates either friction that erodes adoption or autonomy that erodes trust.

Delegation scope is your contract with users

The delegation cluster defines the boundary of agent autonomy, what work the agent owns, what it must surface for human decision, and how that boundary shifts as trust is established. PMs are responsible for setting that boundary correctly in the product specification, not just in the system prompt.

Key principles for product managers

Focus on: make-hand-offs-approvals-and-blockers-explicit, design-for-delegation-rather-than-direct-manipulation, optimise-for-steering-not-only-initiating, and replace-implied-magic-with-clear-mental-models. These four govern the approval contract, autonomy scope, and the user's ability to steer and correct agent behaviour.

Core principles for product managers6

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 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 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 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.

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.

Also relevant

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.

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 engineers For designers Review guide