Two Different Contracts: Agentic AI vs Generative AI for Enterprise Requirements

Generative AI produces something a person looks at before anything happens. Agentic AI does something, and a person may find out afterward. That single difference changes the requirements more than the technology does. A generative system needs quality criteria and a review step. An agentic system needs a written scope of access, a list of permitted actions, escalation triggers, a rollback path, and an audit log, all before it touches production. Gartner now predicts that by 2027, 40% of enterprises will demote or decommission autonomous AI agents because of governance gaps found only after a production incident. This guide sets out the two contracts, a table of what differs, and a three-question test for which one you are signing.

Introduction

The vendor deck uses the same slide for both. A chat window, a confident answer, a happy customer. Somewhere around slide nine the word "agent" appears, and the price goes up.

What the deck does not show is that the two products create different obligations for the business. One writes a draft you approve. The other cancels an order, issues a refund, or updates a record, and the approval happened when you switched it on.

The requirements for those two things are not the same document with a few extra rows. They are two different contracts.

What is agentic AI vs generative AI?

Generative AI takes an input and produces content: text, code, an image, a summary, a recommendation. A human reads the output and decides what to do with it. Agentic AI takes a goal, plans a sequence of steps, and executes them using tools and system access, often without a human reviewing each step. The output of a generative system is a thing. The output of an agentic system is a changed state in the world.

Two adjacent terms cause confusion in the same searches, so here they are briefly.

AI agent vs agentic AI. An AI agent is one system built to act toward a goal. Agentic AI is the broader property, the capacity to plan and act across steps. In practice the terms are used interchangeably, and the distinction that matters for requirements is not which word the vendor used but whether the system can take an action a human did not individually approve.

Predictive AI. Predictive AI estimates a value or a probability from historical data, such as churn risk, demand next quarter, or the likelihood a transaction is fraudulent. It produces a number, not content and not an action. It has been in enterprise use for two decades under the name analytics. Its requirements are about data quality and model monitoring, and they are well understood.

The line that changes the contract runs between generative and agentic, not between any of the others.

Key Takeaway: Ask one question of any AI product. Does it produce something a person reviews, or does it do something a person may not see? The answer picks the contract.

Weighing an agentic pilot against a generative one? Our AI Implementation practice scopes the requirements before the vendor scopes the demo. Book a free consultation.

Why is the requirements contract different?

Because the failure modes are different, and requirements exist to prevent failure modes.

When a generative system fails, it produces a bad output. Someone reads it, notices, and does not use it. The cost is the review time and the occasional bad output that slips through. When an agentic system fails, it takes a wrong action. The cost is whatever that action did, plus the time to discover it, plus the time to reverse it if it can be reversed.

Gartner's May 2026 release on AI agent governance predicts that by 2027, 40% of enterprises will demote or decommission autonomous AI agents due to governance gaps identified only after production incidents occur, and attributes the failures to organizations not distinguishing between an agent's ability to act and the scope of access it is granted.^[1] That distinction, ability to act versus scope of access, is a requirements distinction. It is decided in a document, or it is decided by an incident.

The table below is the difference in one place.

Look at the acceptance test row. Generative systems are tested the way you test a writer, on a sample. Agentic systems have to be tested the way you test a permission model, exhaustively, because the one action you did not try is the one it will take on a Saturday.

The pattern we see on enterprise AI pilots is a requirements document written for the generative contract, applied to an agentic product, because the vendor demo looked like a chat window. The pilot works. Production is where the scope of access turns out to include a system nobody listed. ID Business Analysis Canada runs an AI Readiness Assessment before pilot selection, with a business analyst producing the authority boundary for each candidate use case, so that the contract type is decided before the vendor is.

Key Takeaway: A requirements document that does not state what the system is allowed to do, and forbidden from doing, is a generative contract. Do not sign an agentic product against it.

What does the generative AI contract require?

Three things, all of them familiar to anyone who has specified a reporting or content system.

• Quality criteria for the output, in testable form. Not "accurate and helpful." A defined set of sample inputs, the expected properties of the output for each, and a scoring method a reviewer can apply consistently. Tone, length, required elements, prohibited claims.
• A review step that is real. Who reads the output before it is used, what they check, and what happens when they reject it. If the honest answer is that nobody reads it, you have an agentic system with extra steps, and it needs the other contract.
• Provenance. Where the system draws from, whether those sources are current, and whether the output can cite them. This is the requirement most often skipped and the one that decides whether the output can be relied on for anything regulated.

The generative contract is lighter, and it should be. Over-governing a summarization tool as though it could move money slows delivery and pushes teams toward unsanctioned tools. The point is not maximum control. It is control proportionate to what the system can do.

Key Takeaway: For generative systems, specify the output and the reviewer. If there is no reviewer, you are in the wrong contract.

What does the agentic AI contract require?

Five clauses, written before the system has production access, each one a section in the requirements document.

• Scope of access. Which systems, which records, which fields, read or write. Named, not described. "Customer data" is not a scope. "Read on the CRM contact object, write on the case status field only" is.
• Permitted actions. The complete list of things the system may do, each tied to a business rule. Everything not on the list is forbidden by default, and the acceptance test proves the refusal.
• Escalation triggers. The conditions under which the system must stop and hand off to a person. Value thresholds, confidence thresholds, record types, customer segments. This clause is where the business decides how much autonomy it is buying.
• Rollback path. For each permitted action, how it is reversed, by whom, within what time. Some actions cannot be reversed. Those need a human approval step, and the requirement says so.
• Audit log. Every action, the input that triggered it, the reasoning or rule applied, the outcome, and the identity the system acted under. Queryable, retained, and reviewed on a schedule.

Notice that none of these five is about model quality. They are about authority. A more capable model does not make any of them less necessary, and a less capable one does not make them more so. They are the same clauses you would write for a new employee with system access, which is the useful way to think about it.

Key Takeaway: The agentic contract is an authority document. Write it as you would write the access rights and approval limits for a new hire.

How do you decide which contract you are signing?

Three questions, asked of the product as it will run in production, not as it ran in the demo.

• Does it change anything outside its own output? Sends, updates, creates, deletes, approves, purchases. If yes, agentic.
• Does a person see the change before it happens? If every action waits for a human click, the system is generative with a suggestion layer, and the lighter contract applies. If some actions proceed without a click, agentic.
• Can the change be undone? If yes, the rollback clause is a design task. If no, the action needs a mandatory human approval step regardless of what the vendor recommends.

Many products are honestly both. A support assistant that drafts replies is generative. The same product with a toggle that lets it send replies and issue credits under a threshold is agentic the moment the toggle is on. The requirements should cover both states, and the toggle itself is a requirement with an owner.

Key Takeaway: Assess the product in its most autonomous configuration, not its demo configuration. The contract has to hold when someone turns the toggle on.

Frequently Asked Questions

What is the main difference between agentic AI and generative AI?Generative AI produces content that a person reviews and decides how to use. Agentic AI plans and executes actions against systems, and a person may only see the result. The technical difference is tool use and multi-step planning. The practical difference is that agentic systems change state without individual approval, which is why their requirements are about authority and reversibility rather than output quality.

Is agentic AI more risky than generative AI?The risk is different in kind rather than simply larger. A generative failure is a bad output, caught at review. An agentic failure is a wrong action, discovered afterward, with a cost that depends on what the action did and whether it can be reversed. The risk is manageable when the scope of access, permitted actions, escalation triggers, rollback path, and audit log are specified before production. It is unmanaged when they are not, whatever the model's capability.

How do we start scoping an agentic AI requirement in our organization?Start by writing the authority boundary for one candidate use case before looking at vendors: scope of access, permitted actions, escalation triggers, rollback, and audit. ID Business Analysis Canada does this as an AI Readiness Assessment, with a business analyst producing the boundary document and a use case ranking based on how reversible each candidate's actions are, so the first pilot is one where a wrong action can be undone. Vendor selection happens after the boundary is written, against it.

Do we need a business analyst for an AI implementation?If the system will take actions, yes, because the five authority clauses are business decisions expressed as requirements, and they have to be traced to business rules, data owners, and approval limits that already exist in the organization. That is analysis work. For a purely generative tool with a real review step, the requirements are lighter and a product owner with a good acceptance-criteria discipline is often enough.

Conclusion

The technology comparison is interesting and mostly beside the point. What the business signs up for is different: an output to review, or an action to trust. The second one needs a written authority boundary, and the incident that reveals a missing one is expensive.

If you are evaluating an AI product and the requirements document has quality criteria but no clause on what the system is forbidden from doing, ID Business Analysis Canada's AI Implementation practice produces the authority boundary as the first deliverable of an AI Readiness Assessment. Book a free consultation and bring the vendor deck.

Sources

1. Gartner, Gartner Says Applying Uniform Governance Across AI Agents Will Lead to Enterprise AI Agent Failure, press release, May 26, 2026. https://www.gartner.com/en/newsroom/press-releases/2026-05-26-gartner-says-applying-uniform-governance-across-ai-agents-will-lead-to-enterprise-ai-agent-failure