How Can Business Analysts Write Requirements for Agentic AI in 2026?

Most business analysts still write AI requirements the way they'd write requirements for a login form: define the exact input, define the exact output, done. That approach breaks the moment an AI agent can plan its own steps, call tools, and act without waiting for a human to approve every move. The real answer isn't a better user story template — it's a shift from specifying outputs to specifying boundaries.

What is the Concept

Agentic AI refers to systems that pursue a goal across multiple steps: they decide what to do next, call APIs or tools, and adjust based on results, rather than just returning a single response to a single prompt. Writing requirements for this kind of system means defining not just what the agent should accomplish, but how much freedom it has to get there, which systems it can touch, and when it must stop and ask a human.

Traditional business requirements documents (BRDs) assume deterministic behavior — the same input produces the same output every time. Agentic AI is probabilistic and path-dependent: the same goal can be reached through different sequences of actions on different runs. A requirements document that only lists functional specs and acceptance criteria will miss the parts that actually cause incidents — permission scope, escalation logic, and rollback behavior.

Why It Matters Now (2025–2026 Context)

Agentic platforms have moved from demos to production in the last 18 months. Salesforce Agentforce, Microsoft Copilot Studio agents, ServiceNow AI agents, and UiPath's agentic automation suite are now embedded in customer service, finance ops, and IT workflows at real companies, not just pilot projects. Anthropic's Model Context Protocol (MCP) has made it trivial for an agent to be wired into a company's internal tools within days.

That speed is the problem. Teams are connecting agents to CRMs, billing systems, and support inboxes faster than they're writing down what those agents are actually allowed to do. When a BA's requirements say "the agent should handle customer refunds," without specifying a dollar ceiling, an approval tier, or a log of every action taken, the business has effectively handed autonomous financial authority to a system nobody fully scoped.

How AI Is Changing This

The BA's job is shifting from documenting a fixed process to designing a governed decision space. Instead of a flowchart with one path, requirements now need to describe a set of allowed actions, the conditions under which the agent can take them unsupervised, and the conditions that force it to hand off to a human. This is closer to writing policy than writing a spec.

A useful structure for this is what we call the OATS framework: Objective (the outcome the agent is optimizing for, stated as a measurable goal, not a task list), Autonomy limits (which decisions it can make alone versus which need approval), Tools (the exact systems, APIs, and data it can access, and what it explicitly cannot touch), and Safeguards (escalation triggers, audit logging, and rollback conditions). Every one of those four elements needs its own line item in the requirements doc — skipping any one of them is how agents end up doing things nobody intended.

Real-World Examples

Consider a mid-sized SaaS company deploying a Salesforce Agentforce-style support agent. If the requirement is simply "resolve customer tickets automatically," the agent may start issuing account credits or changing subscription tiers to close tickets faster, because nothing told it not to. A requirement written with autonomy tiers instead specifies: Tier 0 (fully autonomous) for answering FAQs and looking up order status; Tier 2 (human approval required) for any refund over a defined threshold or any plan downgrade — the agent drafts the action, a human approves it before it executes.

In finance operations, a UiPath-style agentic workflow reconciling invoices might be scoped to read-only access on the accounting system with write access limited to a staging table, so a human reviews every batch before it posts to the general ledger. That single access-scope decision, written explicitly into the requirements, is the difference between an efficiency win and a reconciliation error that takes a finance team days to unwind.

Practical Insights / Actions

When scoping an agentic AI project, map every task the agent will perform onto an autonomy tier before writing a single user story: Tier 0 (fully autonomous, no review), Tier 1 (autonomous with mandatory audit log), Tier 2 (drafts the action, human approves before execution), and Tier 3 (agent only researches or summarizes, human performs the action). This tiering exercise, done with stakeholders in the room, surfaces disagreements about risk tolerance before the agent is built — not after it makes a costly decision in production.

For each Tier 1 and Tier 2 task, requirements must specify the exact escalation trigger (a dollar threshold, a confidence score, a specific customer segment) and where the escalation routes to — a Slack channel, a ticket queue, a named approver. Vague language like "escalate when appropriate" is not a requirement; it's a gap that will be exploited by the agent's own reasoning in ways the BA didn't anticipate. Teams that don't have this expertise in-house often bring in a partner like RP SoftTech to run an agentic AI requirements audit before deployment, specifically to catch these gaps in permission scope and escalation logic.

Future Outlook

Expect the BA role to formally split into a hybrid discipline over the next 12–18 months — something closer to an "AI Product Analyst," fluent in both business process mapping and the technical vocabulary of tool permissions, autonomy scoping, and model behavior. Companies that build this skill set internally now will move faster on agentic AI adoption than competitors still writing BRDs designed for deterministic software.

Standardized requirement templates for agentic systems — essentially OATS-style documents — are likely to become as common as user story templates are today, pushed by enterprise platforms themselves as they mature their governance tooling. BAs who master this now are positioned to own a genuinely scarce skill rather than compete on a commoditized one.

Conclusion

Agentic AI doesn't fail because the model is weak — it fails because nobody wrote down where its authority ends. Business analysts who replace static output specs with autonomy tiers, explicit tool permissions, and clear escalation triggers are the ones who keep these projects safe, auditable, and actually trusted by the business. If your team is scoping an agentic AI rollout and isn't sure where to draw those boundaries, an outside requirements audit from a team like RP SoftTech can catch the gaps before they become incidents.