How to Write a Business Case for an AI Agent, Honestly

A business case for an AI agent is a short document that names one role, the problem it addresses today, the approval boundaries it works within, and the observable evidence that will show whether it is useful. Build it from what you can watch and count inside your own team, not from savings estimates borrowed from elsewhere. A proposal that a skeptical colleague can check is far more likely to be approved than one that promises a large number.

Key takeaways

• Propose one clearly bounded role, not a general ambition to use AI across the company.
• Replace estimated savings with observable criteria: what the agent covers, how long work waits, how much a reviewer corrects, and where it escalates.
• Describe what the agent may read, draft and send, and where a person must approve, before anyone asks.
• Include a trial period in which the agent works without authority, so the evidence comes from your own work.
• State in advance what result would make you adjust, pause or stop. It makes the proposal more credible, not less.

What should a business case for an AI agent contain?

Decision makers rarely reject a proposal because the technology sounds unlikely. They reject it because the document leaves their questions unanswered. Most of them ask the same few things, in roughly this order: what work is this, who is accountable for it, what can go wrong, how will we know it is working, and what does it take to run and to stop.

A useful case answers each of those in plain language, usually in a page or two:

• The role: one sentence describing the work the agent takes on, and the person who owns that work today.
• The current situation: how the work is done now, where it waits, and what you have observed rather than assumed.
• The context it needs: which documents, systems and history the agent must reach to do the job.
• The boundaries: what it can read, what it can draft, what it can send or change, and who approves what.
• The success criteria: observable signals, with a named person who will check them.
• The risks and the stop conditions: what you will do if the agent is wrong, slow or unused.
• The running cost of ownership: who maintains it, reviews it and answers for it after launch.

If you can fill each item with something specific, you have a case. If three or four items are blank, you have an idea, and the missing items are your next piece of work. The AI implementation readiness checklist is a good way to find the gaps before you present.

Why should you avoid inventing savings figures?

The usual instinct is to open with a number: hours saved, cost avoided, capacity gained. The trouble is that the number rests on assumptions nobody has checked, such as how long a task really takes, how often the agent will be right, and how many people will use it. When one colleague challenges one assumption, the entire figure collapses, and your credibility goes with it.

An invented figure also creates a promise. Months later, someone will ask you to demonstrate it, and you will be defending an estimate you made before the agent existed. That is a bad position for a champion to be in.

A more honest approach is to describe the baseline in terms people can verify. Where does the work queue up? How long does a request sit before someone touches it? How often does a handoff lose context? How often does a reviewer rewrite a draft? These observations come from your own team and can be rechecked by anyone. They also give you something to compare against once the agent is running.

Cost deserves the same discipline. Instead of a promised saving, state what you will measure: the total running cost divided by the tasks the agent actually completes. The article on measuring cost per completed task explains why per-message figures mislead, and how to measure AI workflow ROI without hype covers what to claim and what to leave out.

How do you pick the one role to propose?

Broad proposals fail because nobody can say what success looks like. A narrow role can be observed, reviewed and corrected. The role should be something a new employee could be trained on in a short document, with a clear owner on your side.

Use this as a decision guide. A role is a good first candidate when most of these are true:

• The work repeats every week, so evidence accumulates quickly.
• There is a written source of truth for the answers: a policy, a price list, a procedure, a folder of past examples.
• A person already reviews the output, so review does not have to be invented.
• Mistakes are recoverable: a wrong draft costs a few minutes, not a lost client.
• One named person feels the pain of the current process and will check the results.
• The inputs arrive through channels the agent can reach without workarounds.

If the work fails on the source of truth, fix that first. An agent that has to guess is an agent that will confidently produce the wrong thing. The guides on giving an agent a reliable source of truth and on preparing company documents are practical starting points.

Also ask whether the work needs an agent at all. If the steps never vary, a fixed workflow may be cheaper and more predictable. Saying so in your proposal shows you weighed the options.

Which observable criteria can you put in the proposal?

Good criteria are things a person can see in the work itself, without a dashboard full of estimates. They should be few, written before the trial starts, and agreed with the person who will judge them. Here are the ones that tend to hold up:

• Coverage: of the requests that fit the role, how many did the agent handle or prepare, and how many did it correctly leave alone.
• Waiting time: the gap between a request arriving and a first useful response, read from timestamps that already exist.
• Reviewer effort: how often a reviewer accepts a draft as is, edits it lightly, or rewrites it. A simple three-way tally is enough.
• Escalation quality: when the agent stops and asks a person, does it hand over the decision with the context attached, or a mess to untangle. See human escalation for AI agent failures.
• Boundary adherence: did the agent stay inside its permissions, with no action it was not allowed to take.
• Real use: are the named people actually working with it, and if not, what are they telling you.
• Cost per completed task: running cost divided by finished work, tracked over time.

For each criterion, write who checks it, how often, and where the evidence lives. A criterion with no checker is a wish. The [FinOps unit economics](https://www.finops.org/framework/capabilities/unit-economics/) material is a helpful reference for tying cost to a unit of delivered work, and the [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) offers a neutral vocabulary for the risk section.

A step-by-step plan for writing the case

You can draft the document in a few focused sittings. Work in this order, because each step feeds the next:

• Step one: describe the work as it is done today. Sit with the person who does it and write down the real steps, not the official ones.
• Step two: record a baseline by hand for a short period. Note when requests arrive, when they are first answered, and what gets reworked. Keep it plain.
• Step three: choose the single role and write its boundaries. List what the agent reads, drafts and sends, and mark every point where a person approves. The article on where an agent should stop and ask can guide this.
• Step four: write the success criteria from the list above, and name the person who checks each one.
• Step five: propose a trial in which the agent drafts and a person decides. Running it before it has authority, as described in shadow mode for AI agents, produces evidence from your own work.
• Step six: write the risks in operational terms. What happens if a draft is wrong, a connection expires, or a document is out of date.
• Step seven: name the owner after launch, the review rhythm, and the conditions for adjusting, pausing or stopping.
• Step eight: ask a colleague outside the project to read it and mark every sentence they cannot verify. Remove or rewrite those sentences.

The last step matters most. Every claim that survives a skeptical reader is a claim you will not have to defend later.

What does this look like in practice? An illustrative scenario

The following is an illustrative scenario, not a real client.

An office manager at a small services company notices that quote requests sit in a shared inbox until someone has a free hour. She proposes an agent that prepares first replies. For a few weeks she logs, by hand, when each request arrives and when the first reply goes out, and she keeps a note of which replies needed the owner to step in.

Her proposal does not contain a savings figure. It says: the agent reads the price list and the last few similar quotes, drafts a reply, and never sends anything. A person reviews each draft. Success means that for the requests the agent covers, first replies go out the same business day, that the reviewer accepts most drafts with light edits in her own judgment, and that every request the agent cannot handle reaches the owner with the relevant history attached. Stop conditions: if reviewers keep rewriting drafts from scratch, or if the team stops opening the drafts, the trial is paused and the cause is reviewed.

The owner approves because the proposal is small, checkable and reversible. Nobody had to believe a forecast.

How does a managed approach handle this?

Be Human structures a first engagement around exactly these elements: one useful role, the memory and tools it needs, the approval boundaries, and an observable success criterion agreed up front. Once the agent is running, managed operations can include monitoring, recurring evaluations, integration maintenance, permission review, incident response and controlled improvements, so the evidence in your business case keeps being collected rather than going stale. The agent keeps its own identity, memory and accounts under human control. For a wider view of what the recurring work involves, see what managed AI services include.

Frequently asked questions

How long should an internal business case for an AI agent be? One to two pages is usually enough. If the role, boundaries, criteria and stop conditions fit on that, a busy decision maker can read it in one sitting. Put supporting detail, such as the baseline notes, in an appendix.

What if my manager insists on a financial number? Offer the unit you will measure, such as running cost per completed task, and explain that the figure will come from the trial rather than a forecast. You can also describe the current cost of delay in plain terms, for example requests that wait overnight. Avoid presenting a guess as a result.

Who should own the agent after approval? Name one person on the business side who owns the role and its results, and one person responsible for access and permissions. If you work with an external partner, the partner handles operations, but accountability for the work stays with your team. The lightweight governance guide shows how to keep this simple.

What should we do if the trial results are mixed? Treat mixed results as information. Look at which criteria held and which did not, adjust the context, tools or boundaries, and run the trial again for the same role. If the evidence still does not support the case, stopping is a legitimate and inexpensive outcome of an honest proposal.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.