Requirements Engineering for AI Agents
Agent pilots fail at acceptance, not in production. Requirements Engineering for AI Agents specifies autonomy bounds and trace-based acceptance criteria.
Most agent pilots don’t fail in production; they fail at acceptance, because no one ever wrote down what “done” means for a system that produces a different trajectory every run. Requirements Engineering for AI Agents is the readiness gate that converts those pilots into governed portfolio capability, by specifying autonomy bounds, acceptance criteria, and trace-based evidence before a single agent ships.
What Is Requirements Engineering for AI Agents, and Why Does It Break Classic Requirements Decomposition?
Requirements engineering for AI agents is the discipline of specifying an agent’s goal, permitted autonomy, tool and data access, and acceptance criteria when behaviour is nondeterministic and multi-step; and it breaks classic decomposition because an agent specifies a permitted space of behaviour, not a single correct answer.
Classic Requirements Engineering (RE) assumes a deterministic mapping from input to output, so acceptance criteria can enumerate the correct result and a tester can check for it. Agentic AI dissolves that assumption: the same prompt yields a probability distribution over trajectories, so “acceptance” has to shift from a correct result to acceptable behaviour-under-constraints. This is not a tooling gap: it is a maturity gap. Two systematic mapping studies anchor the field, and the more recent finds that RE practice for AI-based systems is still emerging and inconsistently applied, with roles shifting so that data scientists now specify high-level requirements that can crowd out stakeholder requirements unless software engineers co-own the spec Springer.
The Determinism Assumption in Acceptance Criteria
The determinism assumption is the hidden premise that one input has one correct output, which lets a team write acceptance criteria as an enumerated checklist; and it is exactly the premise an agent violates. When behaviour is deterministic, “the function returns the sorted list” is a complete, testable line. When behaviour is agentic, the agent may reach the goal through different tool calls, in a different order, with different intermediate reasoning each time, so an enumerated-output acceptance line is either trivially passed or impossible to satisfy.
The failure mode here is subtle: teams keep the old acceptance template and quietly downgrade it to a demo. “It worked when we tried it” becomes the de facto gate, and the project carries unmeasured behavioural risk into production. Requirements Decomposition still matters, you still break a large need into smaller verifiable ones, but each leaf can no longer assert a single answer. It must assert a constraint the distribution of outputs has to respect. The practical consequence is stark, and practitioners say it plainly: when requirements engineering fails for an agent project, the entire project can collapse, because there is no objective bar to build or test against (Etteplan).
Goals, Autonomy, and Tool Access
An agent requirement has three irreducible dimensions a classic requirement lacks: the goal it pursues, the autonomy it is granted to pursue it, and the tools and data it may touch along the way. Specifying the goal alone, the historical RE habit, leaves the two most dangerous dimensions implicit, which is how “helpful assistant” becomes “agent that emailed the customer list.”
Goal specification carries over from traditional RE: state the outcome and why it matters. Autonomy is the new axis, how far the agent may act without a human checkpoint, and it has to be written as a bound, not a hope. Tool and data access is the third axis: which systems the agent may read, which it may write, and under what scope. The Role-Goal-Backstory pattern popularised in agent frameworks captures part of this by forcing an explicit role and goal per agent Role-Goal-Backstory (Analyst’s Corner), and the 5P framework is one practitioner lens for asking these specification questions of an agent rather than a person Role-Goal-Backstory (Trust Insights). Where these dimensions stay tacit, the agent’s real requirements live in prompt strings no reviewer audits; which is why the discipline pushes toward machine-readable, continuously-updated requirement graphs rather than human-only documents.
Agent Requirements in the SAFe Hierarchy
A scaled requirements hierarchy gives agent requirements a backbone, and the Scaled Agile Framework (SAFe) supplies the worked example used throughout this guide: Epic to Capability to Feature to User Story, with each tier carrying a different kind of agent-requirement artifact. The pattern generalises to any scaled requirements model; SAFe is simply the concrete example.
This hierarchy matters because agent safety needs upfront specification that agile flow tends to defer. An Epic states the strategic outcome and measurable benefit; a Capability translates it into solution intent; a Feature defines usable, deliverable behaviour; and a User Story makes one agent interaction testable by a team within a sprint User Story (monday.com). The roles co-specifying these tiers have changed too; data scientists and software engineers must jointly own ML Systems requirements so data quality and stakeholder requirements stay balanced (Springer). The rest of this article maps each agent-requirements concern, acceptance, autonomy, context, security, measurement, onto this backbone, because the central risk in scaled delivery is that autonomy and oversight requirements declared at the top evaporate by the time work reaches a team. A Business Requirements Document (BRD) may capture the regulatory and business framing, but it is the traceable hierarchy, not the document, that keeps those requirements alive.
Why the Shifting Author Role Changes Who Owns the Spec
The author of an agent requirement has shifted, and that shift is itself a requirements risk: when data scientists tuning model behaviour specify high-level requirements, those technical requirements can crowd out stakeholder requirements unless software engineers co-own the spec (Springer). Who holds the pen determines whether the agent’s purpose stays anchored to a stakeholder outcome or drifts toward whatever the model happens to do well.
Naming this co-ownership as a requirement, not as a staffing accident, is what keeps data quality and business intent in tension rather than letting one silently win. Where a single discipline owns the spec unchallenged, the agent optimises for that discipline’s blind spots: a data-science-only spec chases benchmark accuracy and loses the stakeholder’s actual need, while a business-only spec ignores the data realities that decide whether the agent can be built at all. Balanced co-authorship, written into the process rather than hoped for, is the cheapest defence against an agent that satisfies its authors and disappoints its users.
How Agent Nondeterminism Forces a New Acceptance-Criteria Model
Because an agent’s output is a distribution over multi-step trajectories rather than a single value, acceptance has to judge the trajectory, tool-use validity, decision quality, and reliability across repeated runs, not just the endpoint, which means you score the trace, not the single answer.
This is the single hardest RE problem for agents, and it is where agent requirements diverge most sharply from generic “AI in agile” advice. The shift is from asking “did it return the right answer?” to asking “did it behave acceptably across a representative set of inputs, often enough, within its bounds?”
Single-Answer Correctness to Trajectory Quality
Trajectory quality reframes acceptance around the path an agent takes, scoring whether each tool call was valid, whether decisions were sound, and whether the outcome reproduces: not whether one run happened to match an expected string. A single-answer check cannot see a lucky-but-fragile run, which is precisely the run that fails in production.
The reason this matters is that an agent can reach a correct endpoint through an unsafe path; calling a tool it shouldn’t, leaking context, or succeeding only because the test input was benign. Scoring the trace exposes that. Concrete evaluation patterns assess tool-use validity, decision quality, and reliability across repeated runs as distinct dimensions, and treating them as separate gates turns “works well enough” into countable criteria.
What Trace-Based Evaluation Scores
Trace-based evaluation scores the sequence of an agent’s actions; which tools it invoked, with what arguments, in what order, and whether each step was a valid move toward the goal. Instead of comparing a final output to a golden answer, it inspects the execution path and grades it against rules for permitted tools, required checkpoints, and prohibited actions. This makes the agent’s reasoning legible to a reviewer who would otherwise see only the result.
This matters because most agent failures are path failures, not endpoint failures: an agent that calls a write-tool it should never touch is unacceptable even if its final message looks correct. A trace score catches that the way an output diff never could. In practice, a story’s acceptance line reads “the agent achieves the goal AND every tool call is within scope AND no prohibited action appears in the trace”; three trace properties that a single-answer assertion cannot express.
Reliability Across Repeated Runs
Reliability across repeated runs measures whether the agent reaches an acceptable outcome consistently when the same task is executed many times, rather than once in a demo. Because nondeterminism means each run can differ, a single passing run is evidence of possibility, not of reliability; only repetition reveals the true success rate and its variance.
This is why reliability is itself an acceptance dimension, not an operational afterthought. A requirement that an agent “summarise the ticket” is meaningless without a run count and a threshold; say, an acceptable summary on a defined share of repeated trials. Measuring across runs also surfaces the long tail: the rare trajectory where the agent loops, abandons the task, or violates a bound. Catching that tail at acceptance time, on a representative input set, is far cheaper than catching it as a production incident.
Acceptance Criteria as Distributional Properties
Defining acceptance criteria as distributional properties means writing the bar as a pass rate over a sized, representative input set instead of a single expected result; for example, requiring a correct answer in at least 98% of trials rather than “returns the correct answer.” The wrong spec line reads “the agent returns a correct summary”; the right one reads “the agent produces a summary that passes the rubric on 90% of a representative input set” (Adaline Labs).
The power of this reframing is that it forces the team to agree on what “good” means before building, not after shipping, and it makes the threshold a risk decision rather than a default. A high-consequence action might demand correctness in at least 98% of trials (Statology), while a low-stakes draft can tolerate more variance. The sample size matters as much as the percentage: a 98% bar measured on five inputs is theatre. The representative input set has to be large enough, and adversarial enough, that the pass rate is statistically meaningful.
Completion, First-Pass Approval, and Rework Rate
Practitioner-grade agent acceptance leans on a small set of countable outcomes, completion rate, first-pass approval rate, rework rate, and a quality score, that translate “works well enough” into gates a backlog can carry. A task-specification template with a title, description, acceptance criteria, priority, and required context gives each of these metrics a home on the story.
These four measures map cleanly onto the trace-and-distribution model above. Completion rate captures how often the agent finishes the task at all; first-pass approval rate captures how often a human accepts the output without edits; rework rate captures how often it has to go back; and a quality score captures graded acceptability where pass/fail is too blunt. Together they convert vague satisfaction into leading indicators that a Release Train Engineer can read on a dashboard. Crucially, they are written into the story as acceptance criteria up front, so the agent is judged against a number the team chose deliberately: not against a reviewer’s mood on the day. A rising rework rate then becomes an early signal that the underlying requirement is under-specified, a thread this guide picks up in the measurement section.
Encoding Behavioural Constraints as Testable Rules
Behavioural constraints become testable acceptance rules when you encode them as explicit conditions the agent’s trajectory must satisfy, permitted actions, prohibited actions, and required checkpoints, rather than leaving “be safe” as a hope. Encoding harmlessness as an explicit set of behavioural principles, as the Constitutional AI approach demonstrated, is the canonical example of turning a soft constraint into something you can test.
The mechanism is to write each constraint as a predicate over the trace: “never calls the refund tool above amount X without approval,” “always cites a source for factual claims,” “never reveals system instructions.” Ambiguity in these constraints is itself a defect, and a useful detection technique borrows from requirements analysis: sample multiple formalisations of a requirement and cluster them by logical equivalence using semantic entropy, so requirements that read clearly but mean different things to different readers surface before any code is written (Kiro). Acceptance should also include stress testing, feeding outlier and adversarial inputs through the same rubric, because agentic systems, like any software, must survive bias and adversarial probing as part of their test regime (Forbes). A reusable agent acceptance criterion therefore reads: goal met AND autonomy bounds respected AND tool calls valid AND outcome reproduces above the threshold.
Designing the Representative Input Set
A distributional acceptance bar is only as honest as the input set it is measured on, so designing that set, sized for statistical meaning and seeded with adversarial cases, is itself an acceptance-criteria requirement rather than a testing afterthought. A 98% pass rate measured on five benign inputs proves nothing; the same bar on a large, adversarial set is a real gate.
The set has two jobs that a single number cannot capture. It must be large enough that the measured pass rate is statistically meaningful rather than an artifact of a handful of runs, and representative enough that it mirrors the distribution of inputs the agent will actually meet in production; including the rare and hostile ones. Under-sizing the set turns distributional acceptance back into theatre; skewing it toward easy cases hides exactly the long-tail trajectories, loops, abandonment, boundary violations, that acceptance exists to catch. Writing the input-set composition into the requirement, alongside the threshold, is what makes the pass rate a number the team can trust rather than one it can quietly game.
Mapping Agent Requirements Onto a Scaled Epic-Capability-Feature-Story Hierarchy
Each level of a scaled hierarchy needs a different kind of agent-requirement artifact, and the real job is to stop autonomy and safety requirements from evaporating as work flows downward from strategic Epic to sprint-sized User Story. Using SAFe’s Requirements Model as the worked example, the pattern generalises to any four-tier decomposition.
Large-scale agile has always had to reconcile upfront, detailed analysis with continuous flow, and that tension is exactly where agent safety lives: autonomy bounds and human-in-the-loop gates need specifying early, then carrying down intact (Springer). Multi-Agent System tooling can even help generate and prioritise the lower tiers, with empirical work showing LLM agents producing user stories and prioritisation, GPT-4o excelling at story generation while trading away speed Multi-Agent System (arXiv).
Epic-Level: The Epic Hypothesis Statement
At Epic level the agent requirement is a hypothesis, not a spec, and the SAFe Epic Hypothesis Statement is the concrete artifact: a stated business outcome, the leading indicators that will confirm or refute it, and the minimum viable product that tests it. For an agent investment, this is where the strategic intent and the measurable benefit are committed before any team builds.
The Epic Hypothesis Statement disciplines agent ambition. “Deploy a support agent” is not an Epic; “we believe an autonomous triage agent will cut first-response time, measured by these leading indicators, validated by this MVP” is. This framing also forces the autonomy question upward: how much independence the agent needs to deliver the benefit is a portfolio-level decision, not a team afterthought. Stating it here means the Capability and Feature tiers inherit a clear autonomy intent rather than inventing one.
Leading Indicators and MVP
Leading indicators are the early, measurable signals that an agent Epic is paying off before the full benefit lands, completion rate climbing, rework rate falling, first-pass approval rising, and the MVP is the smallest agent deployment that can move them. Choosing both up front converts a vague “improve support” Epic into a falsifiable hypothesis with a built-in test.
This matters because agent value is easy to assert and hard to prove, and an Epic without leading indicators tends to drift into a permanent pilot. Tying the indicators to the same trace-based metrics used at story acceptance creates a continuous evidence chain: the numbers that gate a single story roll up to the numbers that validate the Epic. The MVP, scoped to one narrow agent behaviour, is what lets a portfolio learn cheaply whether the autonomy bet is warranted before funding the full Capability.
Encoding Autonomy Intent at Portfolio Level
Encoding autonomy intent at portfolio level means stating, in the Epic itself, how much independence the agent class is permitted and what oversight the organisation requires; before the decision is delegated to a team that lacks the strategic context to make it. This is the requirement most often lost in decomposition, and the one with the highest blast radius if it is.
The practical move is to attach an autonomy and oversight statement to the Epic Hypothesis Statement: the action classes the agent may eventually own, the ones that always require a human gate, and the compliance constraints that apply portfolio-wide. Recording this at the top gives every downstream Capability, Feature, and Story a parent to trace to, so when a team writes a story acceptance criterion it is honouring a portfolio decision rather than guessing. Without this, autonomy bounds get re-litigated, or silently dropped, at every hop.
Solution Intent to Usable Behaviour
The Capability tier translates Epic strategy into solution intent, and the Feature tier turns that intent into usable, deliverable system behaviour: the level where an agent’s externally visible capability is defined and committed. A Capability answers “what solution shape delivers the Epic”; a Feature answers “what can a user actually do with the agent.”
This middle of the hierarchy is where data and integration dependencies must surface, because a Feature that quietly assumes access to a system the agent doesn’t have is a requirement defect waiting to detonate in a sprint. Defining the Feature as usable behaviour, “the agent drafts and submits a compliant expense report for review”, also fixes the autonomy boundary at the right altitude: high enough to be meaningful, low enough to be testable. Each Feature should carry the slice of the Epic’s autonomy intent that applies to it, so the System Architect owning solution intent can see exactly which behaviours are in scope and which oversight gates attach before any User Story is written.
Making One Agent Interaction Testable
A User Story makes a single agent interaction or control testable by one team within a sprint, which means it must name the specific behaviour, its acceptance criteria, and the autonomy bound that applies to that one interaction. If a story can’t be tested in a sprint, it is still a Feature in disguise and needs further decomposition.
The discipline at this tier is right-sizing. Over-decomposition is a real hazard: a small change can balloon into many stories and dozens of acceptance criteria that add ceremony without adding clarity. The signal that a story is correctly sized is that it expresses one testable agent behaviour with a self-contained acceptance rubric: goal, autonomy bound, tool scope, and trace check. Borrowing the trajectory-quality model, the story’s acceptance criteria judge how the agent behaves on a representative input set, not whether one demo run looked right. This is the level where Requirements Prioritization happens in practice, and where Multi-Agent System tooling can draft candidate stories for human refinement.
Preserving Autonomy with Traceability Links
Traceability links are the mechanism that prevents autonomy and oversight requirements from evaporating between Epic and Story, by making each lower-tier artifact explicitly reference the higher-tier requirement it implements. Without them, an autonomy bound declared at Epic level is a comment no downstream team is obligated to honour.
The failure mode is concrete and common: a portfolio decides an agent must never issue refunds above a threshold without approval, the constraint is written into the Epic, and three decomposition hops later a team ships a story whose acceptance criteria never mention it. Traceability closes that gap by making the link a first-class requirement: the story’s acceptance criteria cite the Epic’s autonomy statement, and a gap in the chain is itself a defect. This is also where the field is heading at the tooling level: a common digital thread in which requirements, interfaces, change requests, and verification evidence sit in one connected, machine-readable graph that agents read and update continuously, compressing bounded tasks like trace generation by 5–10x (fev.io). Traceability stops being manual paperwork and becomes the substrate that keeps autonomy intent intact at scale.
Specifying Autonomy and Human-in-the-Loop Boundaries as Acceptance Criteria
Turning “keep a human in the loop” into testable acceptance criteria means defining a ladder of autonomy levels, attaching each consequential action class to an explicit approval gate, and enforcing the boundary so violations are prevented rather than merely logged after the fact. The canonical shape is: action class plus required approver plus intervention or rollback path plus audit record.
This is the section that converts the vaguest agent requirement, “safe enough”, into something a team can build and a tester can check. The principle running through it is that oversight is designed in, not added afterward, and that boundaries must be machine-readable so the agent can evaluate against them in real time Cloud Security Alliance.
Autonomy Levels and Required Oversight
Autonomy Levels are a small, ordered ladder that ties each operating point to the oversight it requires, so a requirement can state exactly how much independence the agent is granted for a given action rather than gesturing at “agentic.” The field is converging on this from approving every action toward defining boundaries within which the agent may operate freely Cloud Security Alliance.
A workable ladder runs from suggest-only, through act-with-confirmation, to act-within-bounds with post-hoc review, to fully autonomous within a scoped domain. Each rung names a different oversight obligation, and the requirement pins the action to a rung. This is the shift from Human-in-the-Loop (HITL), where a human approves before each consequential action, toward Human-on-the-Loop (HOTL), where a human supervises and intervenes by exception: a move that demands the team decide in advance which actions the agent may take autonomously, which warrant a pause, and how it signals for help (ByteBridge). Confidence Thresholds make the rung dynamic: configurable thresholds can govern when an agent acts autonomously versus escalates, so a low-confidence decision drops to a stricter oversight rung automatically Confidence Thresholds (Elementum).
From ‘Agentic’ to Measurable Independence
Moving from “agentic” to measurable independence means replacing the marketing word with a specific autonomy rung and a specific oversight obligation for every action class the agent performs. “The agent is autonomous” is not a requirement; “the agent may issue refunds up to $50 without confirmation and must escalate above it” is.
This precision matters because “agentic” hides exactly the information a reviewer needs: how much can go wrong before a human is involved. Naming the rung per action class also makes change-control tractable; raising an agent’s independence becomes an explicit requirement change with an approver, not a quiet prompt edit. The measurable version is what lets autonomy be audited, versioned, and rolled back, which is the difference between governed capability and an ungoverned experiment.
Mapping Action Classes to Approval Gates
Mapping action classes to approval gates means grouping the agent’s possible actions by consequence and attaching a Human-in-the-Loop (HITL) gate to each consequential class, expressed as a story acceptance criterion. The criterion names the action class, the approver role, and the rollback path, so “a human should check important actions” becomes “action class X requires approver role Y before execution, with rollback path Z.”
The mechanism turns oversight into something a team implements and tests rather than promises. Read-only actions may need no gate; reversible writes may need post-hoc review; irreversible or high-value actions need pre-execution approval. Escalation Workflows handle the boundary cases; when the agent is uncertain or an action falls outside its mapped classes, it routes to a defined human handover rather than guessing. Writing these gates as acceptance criteria means the test suite can verify that the refund-above-threshold path actually halts for approval, closing the gap between an intended control and an enforced one.
Tool-Permission Boundaries as Governed Interfaces
Tool-permission boundaries are first-class requirements that name which tools and data stores the agent may access, modelled as governed interfaces rather than ad hoc prompt instructions. Treating tool access as a governed interface, not a sentence in a system prompt, is what makes change-control, traceability, and audit tractable for an agent.
The distinction is mechanical and consequential. A prompt instruction like “only use the read-only database” is unenforceable and invisible to change management; a governed interface that grants the agent a scoped, read-only credential is enforced by construction and shows up in an access review. Boundary Definitions written this way become Machine-Readable Boundaries the agent, and the surrounding system, can evaluate against, which is the precondition for enforcement that prevents rather than detects (Cloud Security Alliance). Specifying tool permissions as requirements also surfaces them at the Feature level, so data and integration dependencies are committed before a team starts, and Agent Autonomy is bounded by what the interface allows rather than by what the model happens to refrain from doing.
Writing a Human-in-the-Loop Acceptance Criterion
A Human-in-the-Loop (HITL) acceptance criterion is written in a fixed, testable shape: action class, required approver, intervention or rollback path, and audit record; four elements that together make “a human stays in control” verifiable. Missing any one of them leaves a gap a tester cannot close and an auditor cannot trust.
The shape works because each element maps to a check. The action class scopes which behaviours the gate covers; the required approver names who must act and is verified by an identity check; the intervention or rollback path defines what happens on rejection and is exercised by a test; and the audit record provides the comprehensive logging of autonomous decisions needed for attribution. Effective oversight needs explicit handover points supported by identity scoping and logging, so that the agent retains operative autonomy in producing solutions while humans retain evaluative agency over when to intervene (Springer, AI and Ethics). Audit Logging is not optional decoration here; without it, a HITL criterion can be claimed but never proven after the fact.
Why Boundaries Must Prevent, Not Just Log
An autonomy boundary that is only logged has already been breached by the time anyone sees it, so a HITL requirement must specify enforcement that prevents the out-of-bounds action at execution rather than recording it afterward. The difference between a detective control and a preventive one is the difference between an audit trail of harm and no harm at all.
Prevention requires the boundary to be machine-readable and evaluated before the action commits: the refund call halts pending approval, the write-tool is simply not in the agent’s granted interface, the escalation fires at the confidence threshold rather than after the mistake. Logging still matters, but as evidence for attribution after a prevented or approved action, not as the primary control. Specifying enforcement semantics in the acceptance criterion, “the action cannot execute until the approver acts,” not “the action is recorded when it executes”, is what keeps an intended boundary from degrading into a post-mortem field that documents failures it was supposed to stop.
Data and Context Requirements: Specifying What an Agent Needs to Know
What an agent is allowed to know is a requirement as binding as what it is allowed to do, so context, knowledge sources, retrieval scope, freshness windows, and grounding expectations, must be specified as an explicit, reviewable artifact rather than left as implicit prompt engineering no one can audit.
As agents operate over more turns and longer horizons, teams need deliberate strategies for managing the entire context state; system instructions, tools, Model Context Protocol (MCP), external data, and message history Model Context Protocol (Anthropic). Treating that state as a requirement, tied upward to the SAFe Feature, makes data dependencies surface before a team commits.
Required Context as First-Class Requirement
Required context is a first-class requirement that enumerates the knowledge sources an agent may draw on, the scope of retrieval permitted, the freshness windows its data must meet, and the grounding behaviour expected; captured in the task specification’s “required context” field rather than buried in a prompt. Context Engineering is the discipline of designing this information substrate deliberately.
The reason context belongs in the requirement is that an agent’s behaviour is only as trustworthy as what it is grounded in. An undocumented context setup is unauditable: no reviewer can tell whether the agent is reasoning from approved, current sources or from stale, out-of-scope data. Promoting context into a governed Data Context Layer changes that. A modern data context layer is effectively a superset of a traditional Semantic Layer; beyond hard-coded metric definitions, it carries canonical entities, identity resolution, instructions that capture tribal knowledge, and governance guidance, all of which an agent needs to act reliably Semantic Layer (a16z). Writing this as a requirement means System Instructions, MCP connections, and knowledge sources each get a freshness and provenance expectation a tester can check.
Knowledge Sources, Scope, and Freshness
Specifying knowledge sources, scope, and freshness means naming exactly which repositories the agent may read, how broadly it may retrieve from them, and how recent that data must be for an answer to count as valid. A requirement that says “the agent uses company knowledge” is unverifiable; one that names the source systems, the retrieval scope, and a maximum staleness window is testable.
This precision prevents two opposite failures: an agent grounded too narrowly that misses essential context, and one grounded too broadly that pulls in unapproved or out-of-date material. Freshness is the most overlooked axis: an agent answering from a six-month-old policy document can be confidently, catastrophically wrong. Tying these requirements to the Data Context Layer means canonical entities and identity resolution are specified once and reused, so the agent resolves “the customer” to the same record every component does, and governance guidance travels with the data rather than living in someone’s head.
Grounding Acceptance Criteria
Grounding acceptance criteria require the agent to answer from approved sources and to signal uncertainty rather than fabricate, expressed as a testable rule over its outputs. The criterion reads, in effect, “every factual claim cites an approved source, and the agent declines or flags low confidence rather than inventing an answer.”
This is where context requirements meet the trajectory-quality model: grounding is a trace property, checkable by inspecting whether the agent actually retrieved and used an approved source before asserting a fact. The acceptance test feeds inputs where the correct behaviour is to abstain, questions outside the knowledge base, and verifies the agent says so instead of hallucinating. Making grounding an explicit acceptance criterion is what separates a retrieval-augmented agent that is trustworthy from one that merely sounds authoritative, and it gives compliance and security leads a concrete control to point at when they ask how the agent avoids confident fabrication.
Governing RAG Sources as Permissioned Inputs
Retrieval-augmented generation (RAG) sources and their access permissions are governed, testable inputs, not implicit prompt content, so each source the agent retrieves from is specified with a permission scope that change-control and audit can track. Treating retrieval as a permissioned interface keeps the same traceability discipline applied to tools.
The practical effect is that adding or removing a knowledge source becomes a requirement change rather than a silent edit, which matters enormously when sources contain sensitive or regulated data. A blended specification helps here: writing the agent spec partly like a Product Requirements Document (PRD) captures the user-centric “why” so the agent doesn’t optimise for the wrong thing, while expanding it like a Software Requirements Specification (SRS) nails the technical specifics; which data store, which API, which scope Software Requirements Specification (Addy Osmani). Governing RAG sources this way also clarifies the must-know-versus-can-retrieve decision: durable, identity-critical context belongs in the specified knowledge base, while volatile detail can be retrieved at runtime; provided the retrieval path itself is a permissioned, audited input.
Data Context Layer Versus the Classic Semantic Layer
A Data Context Layer is a superset of the traditional Semantic Layer: where the semantic layer fixed metric definitions, the context layer adds canonical entities, identity resolution, encoded tribal knowledge, and governance guidance: the wider substrate an agent needs to act reliably rather than merely to compute a number Semantic Layer (a16z). Specifying which layer an agent depends on is a requirement, because the gap between the two is exactly where ungrounded agent behaviour hides.
Treating context as this richer layer changes what a requirement must enumerate. A metric definition tells an agent how to compute revenue; it does not tell the agent that “the customer” resolves to one canonical record, that a given instruction encodes a policy no document states, or that some data is governed and some is not. Promoting all of this into a specified, reviewable layer means the agent reasons from the same canonical substrate every other system uses; and a reviewer can audit that substrate instead of guessing what the prompt happened to include.
Must-Know Context Versus Retrieve-at-Runtime
A context requirement has to draw a line between what an agent must always know, durable, identity-critical context that belongs in the specified knowledge base, and what it can fetch on demand, the volatile detail safely retrieved at runtime through a permissioned path. Drawing that line wrong leaves the agent either bloated with stale embedded context or dependent on a retrieval call that may fail exactly when it matters.
The decision turns on durability and criticality. Identity-critical, slow-changing facts, who the customer is, what the governing policy says, are cheaper and safer to specify once than to re-retrieve every run, and embedding them removes a runtime failure mode. Volatile, high-cardinality detail, today’s ticket queue, a current balance, belongs at the end of a retrieval path, provided that path is itself a permissioned, audited input rather than an open query. Making this split explicit in the requirement prevents both the over-stuffed context window that drives token cost and the silent dependency on a retrieval source no one governed.
Writing Agent Stories: From Spec-Driven Development to Story-Level Acceptance
Writing an agent story means starting from an explicit, executable specification, not a prompt, and turning it into a backlog Story that states the user outcome, attaches agent-specific acceptance criteria, and links upward to its Feature. Spec-driven development makes the spec, rather than the prompt, the source of truth.
Spec-driven development (SDD) is one of 2025’s defining shifts in AI-assisted engineering: authoring a clear, executable specification before any generation, so the artifact the agent builds against is reviewable and durable. The procedure below operationalises the analysis sections into a repeatable authoring workflow.
Spec-Driven Development as Source of Truth
Spec-Driven Development (SDD) treats an explicit, executable Specification as the single source of truth that drives generation, replacing the ad hoc prompt with a reviewed artifact the whole team can reason about. Experienced engineers increasingly write good documentation first, on the basis that a strong spec lets the model build the matching implementation from that input alone (O’Reilly).
The mechanism is to keep the spec goal-oriented, what and why before how, so it captures intent rather than over-constraining implementation (O’Reilly). A Goal-Oriented Spec for an agent reads like a user story plus acceptance criteria: who the user is, what outcome they need, and what “good” looks like. The practical workflow begins with stakeholders describing what they need in natural language, user stories, feature briefs, meeting transcripts, which the team distils into an executable spec (Xcapit). Because the spec is the source of truth, every later test and review traces back to it, and Natural Language Requirements stop being throwaway context and become the documented basis for acceptance.
Turning Specs Into SAFe Stories
Turning a spec into a backlog Story, a SAFe Story in the worked example, means stating the user or business outcome, attaching agent-specific acceptance criteria, and linking the story upward to its Feature so traceability holds. The acceptance criteria are the four-part agent rubric: goal achieved, autonomy bound respected, tool scope honoured, trace check passed.
The procedure is deliberately mechanical so it is repeatable: state the outcome, derive an executable spec, write the Story with its acceptance criteria, define the trace-based test, and set the review gate. Each Story carries the slice of autonomy and context requirements that applies to its one interaction, inherited through the traceability link from its Feature and Epic. This is where Story-Level Acceptance becomes concrete: the agent’s output is judged against the rubric the spec defined, not against a reviewer’s impression. Keeping the Story goal-oriented while making its acceptance criteria specific is the balance that prevents both vague stories and over-specified ones.
LLM-Assisted Story Drafting and Its Limits
LLMs can draft user stories and acceptance criteria from natural-language input, accelerating backlog creation, but human refinement remains essential because the model reliably over-decomposes and misses tacit intent. Tooling such as Kiro, spec-kit, and Tessl supports spec-driven development with different emphases, and collaborating agents can execute against agile artifacts; yet none removes the need for human judgment on scope.
The clearest limit is over-decomposition. One documented case shows a requirements document turning a single small bug into four user stories with sixteen acceptance criteria, including padding like handling edge cases “gracefully” (Martin Fowler). Left unchecked, LLM-drafted backlogs balloon ceremony without adding clarity. The three tools differ in how they manage this, spec structure, workflow, and verification emphasis vary, so the choice depends on how a team wants its specs governed. The reusable rule is to use the model to draft and a human to prune: accept LLM speed on the first pass, then right-size the stories so each expresses one testable agent behaviour. AGENTS.md-style configuration files complement this by carrying durable team conventions into every generation, but they too are inputs the model uses, not substitutes for human scoping.
How Does the Spec Stay in Sync as the Agent Evolves?
A spec only functions as the source of truth if it stays current, so an agent specification has to be versioned and updated whenever the agent’s behaviour, tool access, thresholds, or autonomy bounds change; otherwise the reviewed artifact silently diverges from the deployed agent and every test traces back to a fiction. A spec that has drifted out of date is worse than no spec, because it confers false confidence in a control that no longer exists.
The discipline is to treat the spec as a living document on the same digital thread as the rest of the requirements hierarchy, where a change to the agent is a change to the spec first and the implementation second. This keeps Natural Language Requirements, acceptance criteria, and traceability links mutually consistent as the agent matures: a raised autonomy rung or a new tool permission updates the spec, re-derives the affected acceptance criteria, and re-runs the trace-based tests, rather than landing as an unrecorded prompt edit. The same machine-readable requirement graph that preserves autonomy intent across decomposition is what makes this synchronisation tractable instead of manual.
Security and Risk Requirements for Agentic Systems: OWASP-LLM as Story-Level Controls
Security for agents is a set of requirements, not an afterthought, and the OWASP Top 10 for LLM Applications gives the concrete risk taxonomy that converts into agent security requirements; prompt injection, excessive agency, insecure output handling, and sensitive-data leakage each become an explicit, story-level control.
The evidence that this can be engineered into a scaled framework rather than bolted on comes from the S2C-SAFe extension, which makes SAFe compliant with the IEC 62443-4-1 secure-development standard, showing security compliance can be built into scaled agile at the requirements level. The judgment call threaded through this section: don’t grant agency where deterministic automation is safer and cheaper.
OWASP Top 10 as Security Taxonomy
The OWASP Top 10 for LLM Applications functions as a ready-made risk taxonomy that maps each agent threat to a control belonging in a backlog Story; input validation, output handling, permission scope, and logging. Using a named taxonomy means security requirements are systematic rather than improvised per project.
Treating each entry as a requirement source converts a risk list into acceptance criteria. The taxonomy’s value at scale is consistency: every agent Feature is assessed against the same risk classes, so coverage gaps become visible. This is also where the agent-versus-automation judgment lands as a security decision; granting agency expands the attack surface, so the taxonomy doubles as a prompt to ask whether predictable automation would carry less risk for a given step.
Prompt Injection and Excessive Agency
Prompt Injection and Excessive Agency are the two OWASP-LLM risks most specific to agents: injection manipulates the agent through crafted input, while excessive agency grants it more autonomy, tools, or permissions than the task warrants. As requirements, injection demands input-validation and instruction-isolation controls, and excessive agency demands tightly scoped tool permissions.
These two compound each other, which is what makes them dangerous together: a successful prompt injection on an over-privileged agent turns a manipulated instruction into a real, harmful action. The requirement-level defence is the tool-permission boundary from the autonomy section, least-privilege, governed interfaces, paired with input validation written as a story acceptance criterion. Specifying these as controls means a test can attempt an injection and verify the agent neither executes the smuggled instruction nor exceeds its permission scope, turning two abstract risks into two checkable gates.
Insecure Output Handling and Data Leakage
Insecure Output Handling and sensitive-data leakage are the downstream OWASP-LLM risks: the agent’s output is trusted by a system that shouldn’t trust it, or the agent discloses data it should have protected. As requirements, these become output-validation controls and data-handling constraints written into the Story.
The mechanism for insecure output handling is to treat agent output as untrusted input to whatever consumes it; sanitising, escaping, or validating before it reaches a database, shell, or downstream service. For data leakage, the control is a grounding-and-scope requirement: the agent may surface only data within its permitted scope, and its outputs are checked against disclosure rules. Both map to comprehensive logging so that any leak or unsafe output is attributable after the fact. Writing them as acceptance criteria, “output passes validation before use,” “no out-of-scope data appears in responses on the adversarial test set”, is what moves them from policy aspiration to enforced control.
S2C-SAFe and IEC 62443-4-1 Compliance
S2C-SAFe is the worked example that security compliance can be engineered into a scaled framework: it extends SAFe to be compliant with the IEC 62443-4-1 secure-development-lifecycle standard, demonstrating that compliance requirements integrate with agile flow at scale rather than blocking it. The same approach lets agent security controls live inside the normal requirements hierarchy.
The significance for agent requirements is structural. Rather than treating security as a gate bolted onto the end, S2C-SAFe weaves secure-development obligations into the existing Epic-to-Story flow, so an OWASP-LLM-derived control becomes a Story like any other, with acceptance criteria and traceability. For regulated enterprises, this is the difference between compliance that drags on delivery and compliance that travels with it. IEC 62443-4-1 supplies the secure-development backbone; the extension shows the integration is achievable at scale, which is precisely the assurance a security or compliance lead needs before approving an agent for a regulated portfolio.
Governing Tool Use as Auditable Interfaces
Governing tool use as auditable interfaces means modelling every agent tool and data integration, including those exposed through the Model Context Protocol, as a governed, logged interface rather than an ad hoc prompt instruction, which makes change control, traceability, and audit tractable. This is a security win and a requirements win at once.
When tool use is an auditable interface, every action the agent can take is enumerable, permissioned, and logged, so a security review can answer “what can this agent do” definitively. Modelling Model Context Protocol connections and other integrations this way means adding a capability is a tracked requirement change with an approver, and every invocation leaves an audit trail. This directly mitigates excessive agency, the agent literally cannot exceed the interfaces it is granted, and it satisfies the logging requirement that insecure-output and leakage controls depend on. The result is that security controls and requirements traceability share the same mechanism, so doing one well advances the other.
When Not to Use an Agent: Deterministic Automation vs Agentic Decisions
The first requirements decision is whether an agent is warranted at all: reserve agents for judgment-heavy, variable, context-dependent steps, and use deterministic automation wherever outcomes are predictable, because automation is cheaper, safer, and easier to verify. Agency must be justified before it is granted.
This is the unfashionable guardrail in an environment where everything is being made “agentic.” The cost of agency is real, nondeterminism, trace-based evaluation overhead, and an expanded security surface per the OWASP-LLM risks, and a deterministic script carries none of it.
The Agent-vs-Automation Decision Checklist
The agent-versus-automation decision turns on four questions, input variability, consequence of error, reversibility, and oversight cost, and passing that checklist is itself a requirements gate that must be cleared before agency is granted. If a task has predictable inputs, low error consequence, and easy reversal, a deterministic script is the correct requirement.
The checklist works because it forces the cost of agency into the open. High input variability and genuine judgment favour an agent; predictable, rule-expressible logic favours Deterministic Automation. High consequence and low reversibility raise the oversight cost, which an agent amplifies through nondeterminism and an expanded attack surface, while a deterministic system keeps it bounded and verifiable. Predictable Outcomes are the tell: if you can write the rule, write the rule. Making this an explicit Agency Justification gate, a requirement that agency be argued for, not assumed, prevents the common pattern of reaching for an Agentic Decision where a Rule-Based step would be safer, cheaper, and trivially testable. The Decision Framework is deliberately simple so product owners and architects can apply it at intake.
How Misplaced Agency Harms Flow
Misplaced agency harms flow by importing nondeterminism, evaluation overhead, and security surface into steps that didn’t need them, slowing delivery and inflating verification cost for no offsetting benefit. An agent placed where automation belonged turns a one-line, instantly-verifiable step into a probabilistic one that needs a representative input set and a trace rubric to accept.
The flow-efficiency argument is what makes this a portfolio concern, not just an engineering preference. Every unjustified agent adds trace-based evaluation, expanded oversight, and a wider attack surface to the value stream, and those costs compound across a portfolio of agents. Judgment-Heavy Tasks repay that cost because no rule captures them; predictable steps do not. Positioning the agent-versus-automation decision as a requirements gate keeps Flow Efficiency intact by ensuring agency is spent only where its nondeterminism buys genuine capability; and by catching the uneconomic agent at the requirement stage, long before it reaches production.
Roles and Ownership of Agent Requirements in an Enterprise Delivery Organization
Agent requirements need a defined competency set, AI product manager, system architect, AI governance specialist, and security engineer, mapped onto existing delivery roles rather than proliferating new ones, with a lightweight RACI making ownership unambiguous at each hop from Epic to Story.
The competency model behind agentic builds names these roles, but the practical move is to assign them to roles a SAFe organisation already has, so accountability is clear without inventing a parallel hierarchy.
Competency Set Mapped to SAFe Roles
The agent-requirements competency set maps cleanly onto existing delivery roles: an AI Product Manager owns Feature intent, the System Architect owns solution intent and autonomy boundaries, the AI Governance Specialist carries distinct accountability for compliance and oversight requirements, and a Security Engineer owns the OWASP-LLM-derived controls. Mapping to existing roles avoids the role-proliferation that stalls adoption.
Each mapping reflects where the requirement naturally lives. Product Management already owns Feature intent, so agent Feature requirements, what the agent does for the user, belong there. The System Architect already owns solution intent, making autonomy boundaries and tool-permission interfaces a natural extension of that role rather than a new one. The Release Train Engineer owns flow, ensuring agent stories move without losing their traceability. The genuinely new accountability is the AI Governance Specialist, who owns the autonomy, compliance, and oversight requirements that no traditional role fully covers: the person who can answer whether an agent’s autonomy bounds satisfy regulatory obligations. Naming this role explicitly, while folding the rest into existing positions, gives agent requirements clear ownership without a reorganisation.
A RACI from Epic to Story
A lightweight RACI traces a single agent requirement from Epic to Story so that, at each decomposition hop, exactly one role is accountable and the others’ involvement is explicit. Without it, autonomy and compliance requirements fall into the gaps between roles precisely where traceability is weakest.
The RACI’s job is to make ownership survive decomposition. At Epic level the portfolio and AI Governance Specialist are accountable for the autonomy intent; at Feature level Product Management and the System Architect own the usable-behaviour and boundary requirements; at Story level the team is accountable for testable acceptance criteria, consulted by security and governance. Tracing one requirement, say, the refund-approval gate, through that matrix shows who decides, who builds, and who must be consulted at every level, which is what stops a portfolio-level oversight requirement from quietly losing its owner three hops down. Kept lightweight, the RACI is an orientation tool, not a bureaucratic artifact: enough to make accountability unambiguous, not so much that it impedes flow.
Measuring Requirements Quality and Agent Performance: Maturity and Trace-Based Evidence
Measuring agent requirements means tracking both requirements-quality measures, completeness of autonomy bounds, presence of trace-based acceptance, and traceability coverage across the hierarchy, and agent performance metrics like completion, first-pass approval, rework rate, and quality score, used as leading indicators that feed back into the Epic Hypothesis Statement.
Explicit measurement matters here precisely because the discipline is immature: the 2024 mapping study finds requirements engineering for AI-based systems still emerging and inconsistently applied (Springer). And the broader pattern is that AI in requirements work is overwhelmingly collaborative; human–AI collaboration accounts for roughly 49–61% of techniques across RE phases, with full automation still rare at 4–8%, which is why human-owned measurement remains essential.
Requirements-Quality Measures for Agent Specs
Requirements-quality measures for agent specs assess the spec itself, not the agent: completeness of stated autonomy bounds, presence of trace-based acceptance criteria, and traceability coverage from Epic down to Story. A spec missing any of these carries hidden risk no amount of downstream testing recovers.
Requirements Engineering Maturity is low across the field, so these measures function as a self-audit a team can run before building. Autonomy-bound completeness asks whether every consequential action has a defined oversight rung; trace-based-acceptance presence asks whether stories judge trajectories rather than single answers; traceability coverage asks whether autonomy and compliance requirements actually link from Epic to Story without gaps. Each is countable, coverage is a percentage, completeness is a checklist ratio, which turns “is this spec good enough” into evidence. Treating spec quality as a measured property is also what lets an organisation locate itself on the maturity curve rather than assuming it is further along than it is.
Performance Metrics as Epic Leading Indicators
Agent performance metrics, completion rate, first-pass approval rate, rework rate, and quality score, serve as leading indicators that roll up into the Epic Hypothesis Statement’s measurable benefit, closing the loop between story-level acceptance and portfolio-level validation. The numbers that gate a single story become the numbers that confirm an Epic.
This continuity is the point: Agent Reliability measured at acceptance is the same signal, aggregated, that tells a portfolio whether its autonomy bet paid off. Evidence supports the value of this measurement discipline; AI-driven assistants in scaled agile delivery produce measurable outcomes rather than vague gains (Springer). Wiring these metrics as Leading Indicators on the Epic means the organisation learns early and cheaply whether an agent is delivering, instead of discovering at the end of a funding cycle that a deployed agent never moved the benefit it was justified by. Traceability Coverage ensures the rollup is honest: that the story metrics actually map to the Epic they claim to validate.
Reading Rework and Approval Signals
Rework rate and first-pass approval rate read as a diagnostic on requirements quality: a rising rework rate or falling first-pass approval signals requirements that are either too loose, under-specified autonomy letting the agent wander, or too rigid, over-constraining it into failure. The direction of the other metrics tells you which.
Reading the signals correctly is what makes them actionable rather than decorative. Climbing rework alongside frequent boundary escalations points to under-specification: the autonomy bounds or acceptance criteria are too vague, so the agent produces work humans must repeatedly fix. Climbing rework alongside frequent task abandonment points to over-constraint: the agent is boxed in too tightly to complete the task. Either way, the metric sends the team back to the requirement, not just the model: the fix is usually a clearer autonomy bound or a better-calibrated acceptance threshold. This feedback loop, from operational signal back to requirement, is how agent requirements mature over time instead of ossifying at their first draft.
Non-Functional Requirements for AI Agents: Latency, Cost, and Reliability Budgets
Non-Functional Requirements for AI agents are specified as explicit budgets, a latency target, a cost-per-task ceiling, and a reliability target expressed as a service-level objective on trajectory success rate, distinct from the functional acceptance criteria and attached at the Feature level as enabler or constraint requirements.
These budgets catch the agent that “works” but is uneconomic or too slow, at the requirement stage rather than in production. Tying cost back to the Epic’s measurable benefit keeps ROI visible throughout delivery.
Latency, Cost-per-Task, and Reliability Budgets
The non-functional envelope for an agent is three budgets: a latency target for acceptable response time, a Cost per Task ceiling that accounts for variable token cost, and a reliability target stated as a service-level objective on trajectory success rate rather than mere uptime. Each is a number the agent’s design must respect, not an aspiration.
The reason these need to be explicit budgets is that LLM agents have cost and latency profiles classic software lacks. Token Cost is a real, variable Operating Cost that scales with context length and tool calls, so an agent can be functionally perfect and financially unviable. A Latency Budget bounds the multi-turn reasoning that can otherwise stretch response times unpredictably. And reliability for an agent is not “is the service up” but “does the trajectory succeed often enough”: a Service-Level Objective on trajectory success rate captures what uptime misses entirely. A Reliability Target written this way connects directly to the distributional acceptance model: the SLO is the production expression of the pass-rate threshold the team chose at story acceptance.
Tying Operating Cost to Epic Benefit
Tying operating cost to Epic benefit means expressing the cost-per-task ceiling in terms of the Epic Hypothesis Statement’s measurable benefit, so an agent whose economics undermine its business case is caught as a requirement violation rather than a budget surprise. If cost-per-task exceeds the value-per-task the Epic promised, the requirement fails by definition.
This linkage keeps ROI a first-class requirement rather than a post-hoc finance review. Because the Epic already states a measurable benefit, deriving a cost ceiling from it is straightforward: the agent must deliver its outcome below the cost at which the benefit evaporates. Modelling these Non-Functional Requirements as enabler or constraint requirements at the SAFe Feature level means they are visible during planning, when the architecture that drives token cost and latency is still malleable. Catching an uneconomic agent here, before a team optimises a system that should never have shipped at its cost profile, is exactly the kind of failure requirements discipline exists to prevent.
How Do Latency, Cost, and Reliability Trade Off Against Each Other?
The three budgets are not independent dials, so a non-functional specification has to state how they trade off, which one wins when they conflict, because tightening any single budget usually loosens another. Adding reasoning steps or retries raises trajectory success but spends latency and tokens; capping cost-per-task can force a smaller model that misses the reliability target; a tight latency budget can preclude the very deliberation that makes the agent reliable in the first place.
Naming the priority order is what turns three separate numbers into a coherent envelope a designer can build against. A high-consequence agent may declare reliability the dominant budget and accept higher cost and latency to hold its service-level objective on trajectory success; a high-volume, low-stakes agent may cap cost first and tolerate a lower pass rate. Writing this trade-off into the requirement, rather than discovering it when two budgets collide in production, lets the architecture resolve the tension deliberately at the Feature level, while it is still cheap to choose a different model, retrieval depth, or reasoning budget.
Operationalizing Agent Requirements: A Maturity Path for Enterprise Portfolios
Operationalising agent requirements follows a staged maturity path, from isolated pilot, to governed Feature-level delivery with explicit autonomy and human-in-the-loop acceptance, to a portfolio-level operating model for agents, with requirements discipline as the throughline that converts promising pilots into dependable capability.
This synthesis ties the prior sections into an adoption path. The framing that makes it concrete: treat an agent like a new team member who needs a defined role, scoped access, and a clear definition of good work; which is exactly the requirements discipline this guide has built.
Staged Maturity Path: Pilot to Portfolio
The AI Agent Maturity Path runs from isolated pilot, through governed Feature-level delivery where autonomy and HITL acceptance criteria are explicit, to a portfolio-level Agent Operating Model; and movement along it is gated by requirements maturity, not by enthusiasm. Each stage adds governance the prior stage lacked, anchored in the move Beyond the Pilot toward genuinely AI-empowered agility.
The path matters because the pilot-to-portfolio gap is where most agent programs stall. A pilot proves possibility with minimal governance; scaling demands the autonomy bounds, trace-based acceptance, security controls, and traceability the earlier sections specified. Governed Feature-level delivery is the crucial middle stage: agents ship inside the normal requirements hierarchy, with explicit acceptance, rather than as ungoverned experiments. The portfolio stage establishes an operating model where agent requirements are managed across many value streams with shared standards. A Requirements Maturity Assessment locates an organisation on this path, identifying which discipline, acceptance, autonomy, context, security, measurement, is the binding constraint on its next step.
Onboarding Agents as Team Members
Onboarding an agent as a team member means giving it a defined role, scoped access, and an explicit acceptance of what “good work” looks like: the same three things a new human hire needs, and the same three things agent requirements specify. Framing adoption as Agent Onboarding makes the requirements discipline intuitive to leaders who find “specification” abstract.
The analogy is operationally exact. A new hire’s role is the agent’s goal and autonomy bound; their access provisioning is the agent’s tool-permission interface and Data Context Layer; their performance expectations are the agent’s trace-based acceptance criteria. Onboarding also implies probation: a period of closer oversight that relaxes as the agent earns trust, which maps directly onto moving an action up the autonomy ladder once reliability metrics support it. Treating onboarding as a deliberate, governed step rather than a deployment switch is what keeps a scaling portfolio from accumulating agents no one defined, scoped, or holds to a standard.
Governing Autonomy by Principle at Scale
Governing autonomy by principle at scale means agreeing pre-set principles that decide what an agent may do, rather than approving each case individually, which preserves flow as the number of agents grows. Principle-Based Decision-Making is what lets autonomy governance scale without becoming a review bottleneck.
The mechanism addresses the central tension of HOTL at portfolio scale: per-case approval doesn’t scale, but ungoverned autonomy is unacceptable. Pre-agreed principles resolve it: the organisation decides once which action classes, under which conditions, an agent may handle autonomously, and the agent operates within those principles rather than queuing for individual sign-off (Springer). This is the same machine-readable-boundary idea from the autonomy section, lifted to the portfolio: principles encoded once, enforced everywhere, audited continuously. The throughline of this entire guide lands here; requirements discipline, expressed as principles, autonomy bounds, and trace-based acceptance, is precisely what converts a handful of promising agent pilots into dependable portfolio capability. A requirements-maturity assessment is the practical next step for any enterprise deciding where on that path it stands.
Summary
Requirements Engineering for AI Agents is the discipline that converts nondeterministic, autonomous systems into governed, acceptable capability; by specifying what an agent may do, how independently, on what it may know, and what evidence proves it works, all carried intact from strategy to a single testable interaction.
The Mechanism: Acceptance Becomes a Distribution, Not an Answer
The defining shift practitioners must internalise is that agent acceptance judges a distribution of trajectories, not a single output, which changes every downstream practice. A story’s acceptance criteria stop asking “did it return the right answer” and start asking “did it behave within bounds, often enough, across a representative input set.” That reframing, score the trace, not the answer; require a pass rate, not a match; encode constraints as testable rules, is what makes an agent’s behaviour something a team can build toward and a tester can verify. Everything else in the discipline follows from it: autonomy bounds become acceptance criteria, context becomes a governed requirement, security risks become story-level controls, and reliability becomes a service-level objective on trajectory success. Teams that keep the old single-answer template and quietly downgrade it to a demo carry unmeasured risk straight into production. Teams that adopt distributional acceptance know exactly what “good” means before they build, which is the entire point of doing requirements at all.
The Failure Mode: Autonomy Requirements That Evaporate on the Way Down
The failure that separates governed agent programs from stalled ones is autonomy and oversight requirements declared at the top that evaporate before they reach a team. An Epic states that an agent must never take a consequential action without approval; three decomposition hops later, a story ships whose acceptance criteria never mention it; and the control exists only on a slide. Traceability links are the mechanism that prevents this: each lower-tier artifact explicitly references the requirement it implements, a gap in the chain is itself a defect, and a digital thread keeps autonomy intent machine-readable from Epic to Story. The same discipline catches the two adjacent failures; granting agency where deterministic automation was safer, and shipping an agent that works but is uneconomic. Across all three, the lesson is identical: requirements discipline is not paperwork that slows agent delivery, it is the readiness gate that lets an enterprise scale agents beyond the pilot without losing control of what they are allowed to do.