An Agent Blueprint is a versioned declaration of one agent's permitted operating envelope. It records the agent's purpose, allowed task classes, tools, connectors, services, environments, and runtime targets, plus optional budgets and approval paths — and it deliberately does not schedule, prompt, or otherwise orchestrate the agent.
Most teams can describe what an agent is supposed to do in a design document and what it is technically able to do by reading its tool list. A Blueprint is the reviewed, machine-readable statement that reconciles the two: the envelope the runtime is actually held to at decision time.
What a Blueprint Declares
| Field | What it constrains |
|---|---|
| Purpose | The stated reason the agent exists, in plain language, for reviewers and auditors. |
| Allowed task classes | The categories of work the agent may undertake, such as refund or triage. |
| Tools, connectors, services | The specific capabilities and downstream systems the agent may reach. |
| Environments and runtime targets | Where the agent is permitted to run, so a staging agent cannot quietly act in production. |
| Budgets | Optional ceilings on tokens per turn, cost per session, and tool calls per session. |
| Approval path | The reviewers who must authorize actions that the policy layer escalates. |
| Policy branch | The published policy branch whose rules govern the agent's decisions. |
Why the Envelope Is Declared Separately
Rules and envelopes answer different questions. A policy rule answers "is this specific action allowed right now?" — it is evaluated per decision, against parameters. A Blueprint answers "what is this agent for, and what is the widest set of things it may ever attempt?" That distinction matters during review: a reviewer approving a rule change is reasoning about one decision boundary, while a reviewer approving a Blueprint is reasoning about an agent's entire mandate. Keeping them separate means an agent's scope cannot expand as a side effect of a narrow rule edit.
Source Control, Not a Console Toggle
Blueprints are authored as YAML or JSON in a repository and imported from CI or an operator workstation. Because the declaration lives in version control, every change to an agent's authority arrives as a reviewable diff with an author and a timestamp, and the deployed envelope can be reconstructed for any point in the past.
Import requires the blueprint:import scope. Only an administrator can issue that scope, and the runtime tokens a governed agent receives never carry it. This is the structural property that makes the envelope trustworthy: a governed agent cannot define, widen, or publish its own operating authority. Validation can be run locally before any network call, so a malformed envelope fails on the author's machine rather than in production.
How a Blueprint Is Enforced
- The Blueprint names a policy branch that already has a published revision; the control plane resolves that revision at import time.
- A human reviewer approves the imported draft, which records who widened or narrowed the envelope and why.
- The enforcement runtime evaluates each proposed action against the published rules, with the Blueprint bounding what the agent may attempt at all.
- Actions that breach an approval path are routed to a reviewer rather than executed — see human-in-the-loop agent approval.
- Every decision is recorded, so the operating envelope and the agent's actual behavior can be compared after the fact.
Blueprints and Compliance Evidence
Auditors rarely ask whether an agent behaved well on a given day; they ask who authorized it to act at all, and what bounded it. A reviewed Blueprint answers that directly: a named approver, a timestamped version, and an explicit list of permitted tools, environments, and budgets. Paired with AI agent governance controls at runtime, it turns "we trust the agent" into a documented, reconstructable authorization.
See how Blueprints, policy review, and evidence fit together, or start with a governed agent of your own.