Definitive reference for the five IDD primitives (Agent/WHO, Context/WHAT, Behavior/HOW, Intent/WHY, Trigger/WHEN). Fields, boundary rules, orthogonality tests, conflation patterns. Use when composing, reviewing, or checking orthogonality.
Intent-Driven Design (IDD) decomposes every agent interaction into exactly five orthogonal primitives. Each primitive answers one question and one question only. Together, the five primitives form a complete grammar for describing any AI-assisted workflow. Orthogonality is the central invariant: changing one primitive never requires changing any other. If a change to one primitive forces a change elsewhere, the decomposition contains a conflation and must be refined.
The primitives are Agent, Context, Behavior, Intent, and Trigger. They map, respectively, to the questions WHO, WHAT, HOW, WHY, and WHEN. No sixth question is needed; no subset is sufficient. This document is the definitive reference for all five.
Throughout this document, an "employee onboarding redesign" project serves as the running example. In that project a product team uses multiple agents to reduce new-hire drop-off from 40% to under 20%, redesigning the sign-up flow, first-day checklist, and welcome sequence.
An Agent is the entity that performs work. It encompasses identity, capability boundaries, persona, role description, and constraints. The Agent primitive answers a single question: WHO does this?
An Agent is not a behavior, a goal, or a piece of knowledge. It is a bounded identity with a clear statement of what it can and cannot do.
In Amplifier bundles, agents live in the agents/ directory. Each agent is
declared in YAML or referenced from a bundle manifest.
| Field | Type | Required | Description |
|---|---|---|---|
name | string | yes | Unique identifier for this agent. |
role | string | yes | Human-readable description of the agent's function. |
instruction | string | yes | Core directive that defines the agent's operating identity. |
capabilities | list of strings | no | What this agent CAN do. |
constraints | list of strings | no | What this agent MUST NOT do. |
tools | list of strings | no | Tool names available to this agent. |
Agent defines IDENTITY, not behavior. The statement "careful code reviewer" conflates WHO with HOW. The agent is "code reviewer"; "careful" is a Behavior that should be declared separately and composed in. Likewise, an agent does not define goals (that belongs to Intent) or knowledge (that belongs to Context).
The litmus test: if you remove an adjective or adverb from the agent description and the identity still makes sense, the removed word likely belongs in Behavior.
Good decompositions:
A "UX researcher" agent with capabilities: [user interviews, heuristic evaluation, usability testing]. The identity is clear; the capabilities
describe capacity, not style.
A "senior frontend engineer" with constraints: [no backend changes, follow design system]. Seniority here narrows capability scope, not
behavior. The constraint "follow design system" bounds what the agent
touches, not how it works.
In the onboarding redesign, three agents are defined: ux-designer,
frontend-engineer, and qa-tester. Each has clear, non-overlapping
boundaries. The UX designer produces wireframes and prototypes. The
frontend engineer implements components. The QA tester validates against
acceptance criteria.
Bad decompositions (conflation):
"The agent should carefully review code using best practices." This mixes WHO (code reviewer) with HOW (carefully, best practices). Extract the agent as "code-reviewer" and the behavioral norms into a Behavior.
"Research agent who knows about our codebase." This mixes WHO (researcher) with WHAT (codebase knowledge). The agent is "researcher"; the codebase is Context provided to it.
"Agent that runs after deployment." This mixes WHO with WHEN. The agent's identity should stand on its own; "after deployment" is a Trigger.
Can you swap the agent without changing the Intent? If the answer is yes, the Agent-Intent boundary is clean. Can you change an agent's constraints without altering any Behavior? If yes, the Agent-Behavior boundary is clean.
Context is the knowledge, state, memory, references, working data, and environmental facts available to agents. It answers: WHAT do they know and have?
Context is passive. It does not prescribe action, dictate style, or trigger execution. It is the raw material agents consume.
In Amplifier bundles, context lives in the context/ directory: knowledge
base files, reference documents, system descriptions, and configuration.
| Type | Gathered By | Lifecycle | Examples |
|---|---|---|---|
| Auto-Detected | System inspection | Refreshed automatically | Working directory structure, git history, dependency manifests, file contents. |
| Provided | Human or configuration | Stable across session | User goals, team conventions, brand guidelines, design system tokens, architectural decision records. |
| Discovered | Agent activity at runtime | Accumulated during execution | API responses, test results, build output, interview transcripts, analytics queries. |
Each context item carries:
| Field | Type | Description |
|---|---|---|
name | string | Identifier for this piece of context. |
type | enum: auto, provided, discovered | How this context was obtained. |
content or reference | string or path | The knowledge itself, or a pointer to it. |
scope | list of agent names | Which agents can see this context. An empty list means all agents. |
Context is KNOWLEDGE, not action. "Analyze the codebase" is an Intent carried out by an Agent; the codebase itself is Context. Context does not prescribe