How to Build an Enterprise AI Agent

A while back we replaced an internal admin dashboard with something you could talk to. An operator could type "refund that order and leave a note," and it would happen. Behind the conversation sat a focused set of tools the model could choose to call, and two of them were a refund action and a payout action. The slowest part of that project had nothing to do with teaching the model what a refund request meant. It was deciding, and then enforcing in code, when the model was allowed to actually issue one.

That's the part most guides to building an AI agent skip, and it is most of the work. You can wire a model to a reasoning loop and hand it your tools in an afternoon. The tutorials that show you how are not wrong. Their tools are just toys, a web search, a file reader, a calculator. In an enterprise the tools are the refund button, the payout button, the ticket that closes, the record that updates, the message that goes to a customer. The moment an agent can do those things, the interesting question stops being how smart it is and becomes what you're willing to let it do without asking.

We build production AI and internal tools for teams where those buttons are load-bearing, so I want to be plain about where the difficulty sits. In more than a decade of building enterprise systems, the shape has not changed. The model is the part you finish first. The machinery around what the model is permitted to do is the part you are still refining months later, and it decides whether the agent is still running next quarter or quietly switched off.

The industry is about to learn this at scale. After polling more than 3,400 organizations, Gartner expects over 40% of agentic AI projects to be scrapped by the close of 2027, and one of the three reasons it gives, next to runaway cost and unclear value, is weak risk controls. That last reason is this whole article. A team that ships an agent it cannot constrain or walk back is a team building the case for its own cancellation.

The tools are the agent

An enterprise AI agent is easy to picture as a smart model with a good system prompt. The more useful picture is a set of actions it can take, wrapped in the judgment of when to take them. I've started calling that set the action surface. It is every tool the agent can call, every system those tools reach, and the authority the agent holds over each one. The model plans. The action surface is where a plan becomes something that happened.

Value and risk live in the same place. The agent is worth building because it can do things, close a ticket or issue a refund, and every one of those is also how it can hurt you. You can't widen the value without widening the exposure, because they are the same tools.

OWASP, which maintains the widely used list of top risks in LLM applications, calls a too-wide action surface excessive agency, and it comes apart into three plain failures. The agent has tools it does not need. The tools carry more permission than they need, like a lookup function whose database login can also delete. And the agent acts on its own where the action warranted a person first. Each of those is a decision you make while building the agent, well before the model runs.

The blast radius is not hypothetical. We built a set of Trust and Safety tools for Discord, where part of the work is taking action on user accounts in bulk. A tool that can action one account is a convenience. A tool that can action ten thousand is a different kind of object, and it deserves different controls, even though the code that calls it looks nearly the same. Enterprise action surfaces are full of that asymmetry. The tool that is trivial at one scale is consequential at another, and the model does not feel the difference unless you build the difference in.

A wrong answer is now a wrong action

There is a difference between a chatbot and an agent that matters more than autonomy or intelligence, and it shows up the moment the system is wrong. A chatbot that's wrong tells you something false. You can catch it, argue with it, or ignore it. An agent that is wrong has already done something. It issued the refund, sent the message, closed the account. That error is already in your database, or in a customer's inbox, having its effect.

So the question that governs an enterprise agent is not only accuracy. It is reversibility. Before you let an agent take an action on its own, the thing worth asking is what the mistake costs to undo, and how long it runs before anyone notices. A draft it saves for review costs nothing to discard. A refund it issues can be clawed back with effort. A filing it submits to a regulator cannot be recalled at all. Those three actions might be equally easy for the model to perform, and they are nowhere near equally safe to hand over.

This is why the plainest part of the build, the log of what the agent did and why, is the safety mechanism. If every action carries a record of what the agent saw and the reasoning it followed, a wrong action is visible and can be walked back. If it doesn't, you've built something that acts in the world and keeps no account of itself, which is the gap the old automation had before anyone thought to add a model.

The authority ladder

Put those two ideas together, the action surface and reversibility, and a way to build follows. You grant an agent its authority one action at a time, and you set the level by how much a mistake there would cost. The result is a ladder with four rungs, and every tool sits on exactly one of them.

The first time we drew this out, it looked familiar. It's how you onboard a person. Nobody hands a new hire the payout button on day one. They get read access, then they draft things a manager checks, then they earn the ability to act on their own in the corners where they have shown their work. An agent earns scope the same way, through a run of observed actions that went right. The one difference is that with a person the probation is implicit, and with an agent you build the ladder on purpose and decide, for each tool, which rung it sits on today.

Start read-only, and let evidence do the promoting

The build sequence is the ladder, climbed only as fast as the evidence allows. You start the agent at the bottom, read-only, and you watch it work against real cases rather than demo ones. You keep the log. You read where it was wrong and what it would have done. Only when a given action has a body of evidence behind it, a stretch of suggestions a person approved without changing, do you consider moving that one tool up a rung. Authority is a promotion the agent earns, one action at a time, and the log is its record.

Evaluation is what makes that judgment possible, so it belongs at every rung, the instrument you read the whole way up. Without a way to measure how often the agent is right on a specific action, moving that action to a higher rung is a guess, and guessing your way up the ladder is how you land in the 40% that gets canceled.

There is a more uncomfortable version of this restraint, and one of its clearest voices is Anthropic, whose own guidance on building agents tells you to reach for the simplest design that works and to add autonomy only after a simpler one has actually fallen short. Sometimes the simplest design that works is not an agent at all. A fixed workflow, where your code decides the steps and the model only fills the parts that need judgment, is more predictable, cheaper to run, and easier to trust than a model steering itself, and for a great many enterprise jobs it is the right answer. If you are still weighing whether a custom build of any kind is warranted, that question is worth settling first, before you write a line of agent code.

The capable agent is the constrained one, later

It is tempting to measure an agent by how much it can do on its own, as if autonomy were the achievement. In an enterprise it runs the other way. The agents we trust with the most authority are the ones that earned it slowly, and their capability is the residue of that evidence rather than a starting condition.

So the most capable enterprise agent and the most constrained one are usually the same agent, a year apart. It got there by becoming trusted rather than by becoming smarter, and trust was a record of reversible actions that went right, kept long enough that you stopped checking every one. Build the record first. The autonomy is what you spend it on.

If you are looking at a workflow where an agent would need genuine authority to be worth building, that is the kind of project our AI and intelligent automation practice takes on. Bring one, and we will start by telling you which rung each action belongs on.

Frequently asked questions