Five Frameworks for Specifying Systems That Act on Their Own
Introduction: The Requirements Gap Nobody Is Filling
For four decades, requirements engineering has rested on a quiet assumption: software does what it is told, in the order it is told, every time. The user story, the use case, the process flow, and the acceptance criterion all presume a system whose behavior is fully determined by its specification. Agentic AI systems — software agents that plan, select tools, take multi-step actions, and adapt to what they observe — break that assumption at its foundation. An agent is not specified by enumerating its steps, because the agent chooses its own steps.
The scale of this gap is documented, not speculative. A 2025 review of 395 papers on large-language-model solutions in software engineering found that coding-adjacent activities dominate the research agenda while human-intensive activities — requirements engineering foremost among them — remain the least explored [1]. The AI Agent Index, an MIT-led effort to document deployed agentic systems, found that most publicly deployed agents lack documented safety evaluations, disclosure mechanisms, and identity controls — evidence that agents are shipping faster than the practices for specifying and governing them [2]. Meanwhile, systematic mapping studies of requirements engineering for AI-based systems consistently report immature practices, missing quality attributes, and a shortage of usable frameworks for practitioners [3].
This gap is a professional opportunity for business analysts and product owners. Someone in every delivery organization must translate the question 'what should this agent be allowed to do?' into reviewable, testable, auditable specifications. Data scientists rarely own that question; regulators increasingly demand that someone does. The obligations are no longer optional: the EU Artificial Intelligence Act imposes binding requirements for risk management, logging, human oversight, and technical documentation on high-risk systems, with general applicability from August 2026 [4], and the NIST AI Risk Management Framework asks organizations to govern, map, measure, and manage AI risk across the lifecycle [5]. Both frameworks presume an artifact that connects intended behavior to observed behavior. That artifact is a requirements specification — and producing it is what business analysts do.
This article proposes five practitioner frameworks for specifying agentic systems: the Agentic Requirements Stack, the Autonomy Boundary Canvas, Tool Contract Specification, the Escalation and Handoff Matrix, and the Agentic Traceability Ledger. Each is illustrated through a running hypothetical case. None requires the analyst to write code; all require the analyst to think differently about what a requirement is.
Why Traditional Requirements Break for Agents
Empirical research established years ago that machine learning inverts the requirements relationship. Vogelsang and Borg, interviewing data scientists about requirements practices, found that the shift from coding to training demands new elicitation and specification techniques, because system behavior emerges from data rather than from stated rules [6]. Amershi and colleagues, studying software teams at a major technology company, identified fundamental differences in how AI systems are specified, built, and maintained compared with conventional software — including the entanglement of data, model, and behavior that makes modular specification difficult [7]. Those findings concerned predictive models that classify or score. Agentic systems add three further breaks.
First, the unit of specification changes. A user story specifies an interaction; an agent requires a delegation. 'As an operations analyst, I want exceptions matched to resolution playbooks' says nothing about what the agent may do on its own authority when the playbook is ambiguous. Second, the space of behaviors is open-ended. Techniques in which models interleave reasoning and action — selecting tools and reacting to intermediate results — mean the execution path is constructed at run time, not design time [8]. Enumerating flows is impossible in principle; the specification must instead constrain the space of acceptable behavior. Third, verification becomes probabilistic. Research on agent benchmarks has shown that evaluation practices routinely overstate capability — agents that top leaderboards can be needlessly costly and fail to generalize, because accuracy alone is a misleading acceptance measure [9]. A specification that cannot be verified deterministically must define its own statistical standard of evidence.
International standards have not caught up. ISO/IEC/IEEE 29148, the reference standard for requirements engineering, defines well-formed requirements as verifiable statements of system capability — guidance that remains necessary but silently assumes the verification is repeatable [10]. A Guide to the Business Analysis Body of Knowledge (BABOK) equips analysts to specify solutions and validate that they deliver value, but its techniques inventory predates autonomous systems [11]. The practitioner is left to improvise. The five frameworks below are an attempt to replace improvisation with method.
A Running Hypothetical: The Meridian Case
To ground the frameworks, consider a hypothetical mid-sized asset manager, Meridian Analytics, that operates an investment data platform consolidating security master, pricing, and position data for institutional portfolios. Meridian's data operations team fields several hundred data-quality exceptions daily — price breaks, stale identifiers, mismatched corporate actions. Leadership approves a pilot: an AI agent that triages exceptions, investigates likely causes across internal systems, resolves routine breaks, and escalates the remainder. Meridian is fictional, and deliberately ordinary: the scenario contains nothing exotic, which is precisely why it is useful. Every framework below is applied to it.
Framework 1: The Agentic Requirements Stack
The first framework reorganizes what a 'complete' specification means. Traditional functional requirements answer one question — what should the system do? An agentic specification must answer six, arranged as layers, each building on the one beneath it.
Figure 1. The Agentic Requirements Stack: six layers of specification, from goal definition to audit.
- Layer 1 — Goal specification: What outcome is the agent accountable for, under what constraints, measured how? Goals replace step-by-step functional flows.
- Layer 2 — Autonomy boundaries: What may the agent do without asking, what requires approval, and what is prohibited outright? (Framework 2.)
- Layer 3 — Tool contracts: For each system the agent can touch, what actions are permitted, with what preconditions and side effects? (Framework 3.)
- Layer 4 — Escalation and handoff: Under what conditions does control return to a human, and in what form? (Framework 4.)
- Layer 5 — Memory and data rights: What may the agent retain across sessions, learn from, and disclose? Data entitlements become behavioral requirements.
- Layer 6 — Audit and traceability: What must be recorded so that any action can be reconstructed and defended after the fact? (Framework 5.)
The stack functions as a completeness checklist. At Meridian, the analyst discovers through it that the pilot's draft specification — three pages of feature descriptions — addresses only Layer 1, and partially. Nothing states whether the agent may write corrections directly to the security master (Layer 2), whether it may call the pricing vendor's API and at what rate (Layer 3), what happens when its confidence is low (Layer 4), whether it may remember one client's exception patterns when triaging another's (Layer 5), or what log evidence would satisfy an auditor asking why a price was changed (Layer 6). Five of six layers were invisible to a feature-oriented requirements lens. That is the norm, not the exception.
Framework 2: The Autonomy Boundary Canvas
The single highest-value artifact an analyst can produce for an agentic system is an explicit, stakeholder-approved statement of the agent's authority. The Autonomy Boundary Canvas structures that conversation into three columns: what the agent may act on independently, what it must ask about, and what it must never do.
Figure 2. The Autonomy Boundary Canvas: may act, must ask, must never.
The canvas earns its value through the arguments it forces. 'May act' entries require thresholds: at Meridian, stakeholders agree the agent may auto-resolve price breaks below a defined materiality threshold where the correction matches a vendor-confirmed value — and may not auto-resolve anything touching client-reportable positions. 'Must ask' entries require a named approver and a defined channel, or they are theater. 'Must never' entries deserve special scrutiny, because they encode the risk appetite of the institution: no writes outside approved datasets, no external communications, no action on its own guardrails. Elicitation techniques the profession already owns — facilitated workshops, scenario analysis, decision modeling [11] — transfer directly; what changes is the artifact they produce.
Analysts should treat the canvas as a living contract. Each 'must ask' entry is a candidate for future promotion to 'may act' once evidence accumulates — which means the canvas doubles as the agent's graduation plan, with autonomy expanding by documented decision rather than by drift. Governance reviews of the canvas map cleanly onto the human-oversight obligations that Article 14 of the EU AI Act imposes on high-risk systems [4].
Framework 3: Tool Contract Specification
Agents act through tools — APIs, database queries, ticket systems, messaging endpoints. Every tool the agent can invoke is a capability grant, and each grant deserves the same specification rigor an analyst would apply to a system interface. A tool contract specifies seven elements, and the discipline resembles interface specification the profession already practices, extended with two fields that traditional interface specs omit: reversibility and blast radius.
- Purpose: What the tool does, in one sentence a risk reviewer can understand.
- Inputs: Input schema and validation rules; malformed calls are rejected, not repaired silently.
- Preconditions: Conditions that must hold before invocation — entitlement checks, data freshness, environment state.
- Side effects: Every state change the call produces, including secondary effects such as downstream notifications.
- Reversibility class: Reversible, compensable (undoable via a further action), or irreversible. This single field drives escalation design.
- Blast radius: The worst plausible consequence of misuse, stated concretely — 'incorrect price propagates to client reporting,' not 'data quality impact.'
- Usage constraints: Rate limits, time-of-day windows, and volume caps.
At Meridian, drafting contracts for the agent's eleven candidate tools reshapes the design. Three tools turn out to be irreversible as proposed; two are redesigned to write to a staging area that a human promotes, converting them to compensable. One vendor API lacks the entitlement granularity the precondition requires, surfacing a procurement issue months before it would have surfaced in production. None of this required machine learning expertise — it required an analyst asking specification questions that engineering treats as implementation detail.
Framework 4: The Escalation and Handoff Matrix
'Human in the loop' is the most cited and least specified phrase in AI governance. A requirement that says 'a human reviews agent decisions' is unverifiable until it states which decisions, which human, with what information, and with what authority. The Escalation and Handoff Matrix turns the slogan into a specification by classifying every agent action along two axes: business impact and irreversibility.
Figure 3. The Escalation and Handoff Matrix: impact and irreversibility jointly determine the oversight mode.
Low-impact, reversible actions run autonomously and are logged. High-impact but reversible actions run with notification and a defined undo window. Irreversible but low-impact actions queue for approval in batch. High-impact irreversible actions escalate fully: the human decides, and the agent's role is to assemble the decision package — evidence, options, and its own recommendation with a stated confidence. For each escalation, the specification defines the handoff payload: what the human sees, how long they have, and what the default is on timeout. A handoff without a specified payload merely relocates the failure from the agent to an uninformed human — the analyst's job is to specify the handoff as carefully as the autonomy.
The matrix also gives quantitative teeth to oversight. At Meridian, the analyst adds two verifiable requirements on top of it: escalation coverage (the fraction of novel-scenario classes that correctly route to a human in test suites) and approval latency (the service-level target for 'must ask' decisions, without which the operations team would quietly pressure the agent's thresholds upward to relieve queue pain). Both are measurable; both belong in the specification, not in a policy binder.
Framework 5: The Agentic Traceability Ledger
Traceability in classical business analysis links requirements to designs, tests, and releases. Agentic systems demand a fourth linkage: from requirement to runtime evidence. Because the agent's behavior cannot be exhaustively verified before deployment, verification continues in production — and the specification must define what evidence production will yield. The Agentic Traceability Ledger extends each requirement with four fields: the policy or control it implements, the evaluation that tests it pre-release, the runtime signal that monitors it post-release, and the log evidence that would demonstrate compliance to an auditor.
This is the framework that converts regulatory text into analyst work products. The EU AI Act's logging and record-keeping obligations for high-risk systems [4], and the measurement function of the NIST AI RMF [5], both presuppose exactly this chain — intended behavior, tested behavior, observed behavior, recorded behavior — yet neither tells an organization who builds the chain. At Meridian, the ledger requirement 'every auto-resolved exception must be reconstructable: triggering data, tools invoked, values before and after, and the boundary rule that authorized the action' is a single row. It is also, functionally, the difference between an AI pilot the compliance function tolerates and one it sponsors.
Analysts who have implemented requirements traceability matrices will recognize the mechanics. What changes is the direction of proof: a traditional matrix demonstrates that everything specified was built; the ledger demonstrates that everything the agent did was specified. The second claim is the one regulators, clients, and internal risk committees will ask for.
What the Meridian Case Adds Up To
Run the five frameworks in sequence and the hypothetical pilot changes shape. The Stack exposes five missing layers of specification. The Canvas converts an unbounded mandate into thresholded authority with a graduation path. Tool contracts eliminate three irreversible actions and surface a procurement gap. The matrix replaces 'human in the loop' with routing rules, coverage targets, and latency SLAs. The ledger makes every action reconstructable. Nothing in that list is a model architecture decision; all of it is requirements work. The pilot that emerges is narrower than the one leadership imagined — and vastly more likely to survive contact with audit, regulation, and its own failure modes.
Getting Started Without a Mandate
Few analysts will be handed an agentic governance charter; most will encounter an agent pilot already in motion, specified as a feature list. The practical entry point is diagnostic, not doctrinal. Take the pilot's existing documentation and score it against the six layers of the Stack — a one-hour exercise that produces a gap table no sponsor enjoys ignoring. Then run a single ninety-minute workshop on the Autonomy Boundary Canvas with the pilot's business owner, its riskiest stakeholder, and one engineer. In the author's experience of adjacent specification work, the canvas conversation is the moment the room discovers it has been assuming three different agents: the sponsor imagined an assistant, engineering was building an operator, and compliance was pricing an intern. Surfacing that disagreement before deployment is the cheapest risk reduction available in AI delivery.
Sequence the remaining frameworks by risk rather than by completeness. Tool contracts come next wherever any action is irreversible; the escalation matrix follows once boundaries exist to escalate against; the traceability ledger can begin as three added columns on the existing requirements register rather than a new tool purchase. None of this requires budget approval, new titles, or permission from the research community — which is precisely the point. Frameworks that need a transformation program to adopt do not get adopted; frameworks that fit inside next sprint's refinement session do.
Implications for the Profession
Three conclusions follow. First, agentic requirements work is business analysis, not a new discipline: elicitation, specification, validation, and traceability all persist, applied to a new class of system with new failure modes. The profession's standards bodies will need to extend technique inventories [11], but practitioners need not wait for that to happen. Second, the analyst's comparative advantage is precisely the layer the research community has left thinnest [1][3]: the translation of organizational intent, risk appetite, and regulatory obligation into reviewable specifications. Third, timing matters. Binding obligations arrive with the EU AI Act in August 2026 [4]; evaluation research is converging on the view that unverified agent capability claims do not hold up [9]; and deployed agents demonstrably outrun their documentation [2]. The organizations that close this gap will do it with analysts who can specify autonomy — and the analysts who can do so will have made themselves difficult to replace.
Conclusion
Agentic AI does not eliminate requirements; it raises the price of not having them. When software chooses its own steps, the specification of boundaries, contracts, escalations, and evidence becomes the primary control surface an organization has. The five frameworks offered here — Stack, Canvas, Tool Contracts, Escalation Matrix, and Traceability Ledger — are starting points, deliberately tool-agnostic and ready to be adapted to local governance structures. The invitation to the profession is direct: the least-explored problem in agentic software engineering is the one business analysts have spent forty years learning how to solve.
Author: Mohanaraman Namasivayam
Mohanaraman Namasivayam is a Senior Business Analyst at a global investment management software company, where he has spent over 17 years managing enterprise investment data platforms serving institutional clients. His work spans real-time market data pipelines, enterprise data warehousing, and the requirements practices that connect regulatory obligation to platform capability. He is an MBA candidate at Boston University Questrom School of Business and a CBAP candidate with the International Institute of Business Analysis. He writes on applied AI, data governance, and the evolving business analysis profession. Contact: [email protected]
Disclaimer: The views expressed are the author's own. All case examples in this article are hypothetical composites constructed for illustration; they do not describe any specific organization, product, or client engagement.
References
[1] Hassan, A. E., et al. (2025). Toward Agentic Software Engineering Beyond Code: Framing Vision, Values, and Vocabulary. arXiv:2510.19692. (Reports requirements engineering among the least-explored activities in a review of 395 LLM-for-SE papers.)
[2] Casper, S., et al. (2025). The AI Agent Index. Massachusetts Institute of Technology. arXiv:2502.01635. https://aiagentindex.mit.edu
[3] Ahmad, K., Abdelrazek, M., Arora, C., Bano, M., & Grundy, J. (2023). Requirements engineering for artificial intelligence systems: A systematic mapping study. Information and Software Technology, 158, 107176.
[4] European Union (2024). Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). Official Journal of the European Union. Arts. 9, 12, 14; general applicability 2 August 2026.
[5] National Institute of Standards and Technology (2023). Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100-1; and NIST (2024). Generative AI Profile, NIST AI 600-1.
[6] Vogelsang, A., & Borg, M. (2019). Requirements engineering for machine learning: Perspectives from data scientists. IEEE 27th International Requirements Engineering Conference Workshops (REW), 245–251.
[7] Amershi, S., Begel, A., Bird, C., DeLine, R., Gall, H., Kamar, E., Nagappan, N., Nushi, B., & Zimmermann, T. (2019). Software engineering for machine learning: A case study. IEEE/ACM 41st International Conference on Software Engineering: SEIP, 291–300.
[8] Yao, S., Zhao, J., Yu, D., Du, N., Shafran, I., Narasimhan, K., & Cao, Y. (2023). ReAct: Synergizing reasoning and acting in language models. International Conference on Learning Representations (ICLR).
[9] Kapoor, S., Stroebl, B., Siegel, Z. S., Nadgir, N., & Narayanan, A. (2024). AI agents that matter. arXiv:2407.01502.
[10] ISO/IEC/IEEE 29148:2018. Systems and software engineering — Life cycle processes — Requirements engineering. International Organization for Standardization.
[11] International Institute of Business Analysis (2015). A Guide to the Business Analysis Body of Knowledge (BABOK Guide), v3. IIBA, Toronto.
[12] Anthropic (2024). Building effective agents. Anthropic Engineering. https://www.anthropic.com/research/building-effective-agents