Principles

For engineers

Which Blueprint principles matter most for agent architecture, runtime design, and implementation.

Start with delegation

The delegation cluster defines what an agent can decide on its own versus what requires a human. Engineers implement the decision boundary — but the boundary itself is a product decision. Before building autonomy, define: what actions are reversible, what side effects are externally visible, and what the blast radius of a wrong decision is.

Orchestration shapes reliability

Multi-agent systems fail in ways that single-model calls do not. The orchestration cluster addresses handoffs between agents, fallback paths when a subagent fails, and the visibility contract across a pipeline. The key principle: every agent boundary is a potential failure point — make them explicit and make failures recoverable.

Key principles for engineers

Focus on: design-for-delegation-rather-than-direct-manipulation, ensure-that-background-work-remains-perceptible, preserve-undo-retry-rollback-or-repair, and prefer-structured-outputs-and-typed-payloads. These four cover the majority of agentic architecture decisions.

Core principles for engineers4

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

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

Also in this section

For designers Review guide Start here