What is an enterprise agent?
On this page
It’s Thursday evening. You need to be in Chicago on Monday for a customer meeting. Your company’s travel policy caps domestic flights at $600 round trip, in economy. An agent goes to book yours. The best fare that gets you there is $980.
Should it book it?
It probably can. The real question is whether it should be allowed to.
A chatbot might show you the fares and let you decide. A script might follow a fixed rule: book within policy, or stop. But if you hand the task to an agent, you’d want to know more. Whose name is it booking under? How much may it spend? Who approves an exception? Who answers if it goes wrong? And will it get the booking right, exactly once?
We call all of those systems “agents” now. When one word covers that much, it stops helping anyone decide anything. So I’d start where companies already know how to hand over real work: with a person.
Start with a person
Think about Maya, a travel coordinator who books trips for the sales team. On day one, her manager walks her through the four terms of the job:
- A goal. “Get people to their meetings on time, within policy.”
- Tools. Her own login to the travel booking tool, and a company credit card to pay with.
- Authority. The travel policy: domestic economy fares up to $600. Anything above that is an exception, and the traveller’s manager has to approve it.
- Accountability. Every booking lands in the expense system under her name, where someone reviews it.
Nobody would describe Maya as “a brain with a keyboard.” Her judgement matters. But it’s the goal, the tools, the authority and the accountability together that let the company trust her with its credit card.
An enterprise agent needs the same four things. The difference is that a model supplies the judgement, not Maya. That judgement can be confidently wrong, or follow instructions hidden in an email. So the checks around it can’t rely on the model noticing that something is off. They have to be built in.
The definition
Those four become the requirements for an agent, and give me a definition:
An enterprise agent pursues a goal someone delegated to it, and takes actions that change business systems. It works within authority the organisation defines, with a clear line of accountability for what happens.
A delegated goal, consequential action, defined authority and accountability. Notice what isn’t on the list: the model. The model chooses the steps as the work unfolds. These four requirements govern what happens when it does.
I’m writing about agents that are allowed to change business systems. An agent that only researches and reports needs much of this too, but less is at stake.
What it isn’t
Every kind of automation needs controls like these. What an agent adds is judgement about what to do next. That’s clearest next to the patterns enterprises already run. These are patterns, not product categories: one product can combine them, and a chatbot can be the front door to an agent.
| Who decides the next step? | Who acts on business systems? | |
|---|---|---|
| Answer-only chatbot | The model suggests | A person, after reading the answer |
| Workflow automation | Code defines the allowed paths | Code |
| Enterprise agent | The model, within set limits | The system, through tools |
Anthropic draws a similar line. In its words, workflows are “orchestrated through predefined code paths.” In agents, the model “dynamically direct[s]” its own process and tool use (Building effective agents, December 2024).
Real systems mix the two, and the Chicago trip shows where the line falls. Booking a fare under the policy cap is a fixed rule, so I’d write it as a workflow. Thursday’s fare is $380 over. Is there a Sunday flight within the $600? Would a nearby airport do? Working that out needs judgement. That’s where an agent earns its place.
My rule of thumb: use fixed steps wherever you know them, and an agent only where the next step really depends on what it finds.
The building blocks
That $980 fare needs more than a model’s judgement. To see what else it needs, ask what you’d ask before handing a new hire the company credit card. I count six questions.
Can it do the job?
Ability
Model
Proposes the next step
Like a worker's judgement
Memory
Notes and work in progress. Not the source of truth
Like a worker's case files
Tools
Read and change business systems
Like a worker's logins
What lets a company trust it
Who is it?
Identity
Its own login, separate from yours, so every action traces back to it
Like a worker's staff badge
What may it do?
Authority
For whom, which systems, and up to what limit
Like a worker's job role and spending limit
Who oversees it?
Oversight
Rules approve what is within policy. An authorised person approves exceptions, and can stop it
Like a worker's sign-off from a manager
Who answers for it?
Accountability
A record of who asked, what it did and whether it worked, and a named owner
Like a worker's trail and manager
Can we count on it?
Reliability
Checks before it retries, pauses when it can't tell, and is tested before it is trusted
Like a worker's track record
Almost any agent can answer the first question. The other five are what let a company trust it with real work. They’re also how the definition’s “authority” and “accountability” get enforced. These are responsibilities, not products: one platform might cover several. Let’s follow the trip through each.
Can it do the job?
Ability. It comes from three parts:
- Model. Reads the policy and the fares, and proposes the next step. It plays the part of Maya’s judgement, and like judgement, it can vary.
- Memory. Keeps what’s been done: the hotel you booked, the red-eye you refused. But it isn’t the source of truth. Whether a ticket exists is the airline’s answer.
- Tools. Reach the booking system. Give it only what the task needs. Booking a fare, yes. Changing which credit card pays, no.
Who is it?
Identity. The agent books under its own login, so its bookings can be told apart from yours. And it books for you, because you asked through the travel tool, not for whoever emails it an offer.
What may it do?
Authority. Access makes a step possible. It doesn’t make it allowed. This agent may book economy fares under $600, so the $980 fare can’t go ahead on its own. A prompt can ask the model to stay under $600. The booking system has to enforce it. The security project OWASP lists the opposite, “excessive agency,” among its 2025 risks for applications built on large language models: tools, permissions or autonomy beyond what the task needs.
Who oversees it?
Oversight. Within policy, the rules approve automatically. The extra $380 is an exception, so your manager approves it before anything is booked. Some things no one can approve, like a trip that doesn’t exist. Those just stop. And a person can stop the agent at any time. The design question is where the policy line sits. Draw it too tight and people approve without reading.
Who answers for it?
Accountability. The record shows who asked, what the agent saw, what it decided and what happened. Engineers call this observability. It should also answer the question that matters: will you be in Chicago on Monday? And a named person owns the agent’s results, the way a manager owns their team’s.
Can we count on it?
Reliability. If the booking times out, the agent checks whether a ticket was issued. If it can’t tell, it pauses rather than buy a second one. If your manager takes until Friday to approve, the agent’s progress has to survive a crash in the meantime. That’s the job of the data layer, the filing cabinet, and the subject of my series Agents and the data layer. And before any of this, the agent is tested on realistic trips, including ones it should refuse.
Each step builds on the last
Those six answers aren’t checked once, at setup. An agent works in steps, and it’s stateful: each step starts from what the last one left behind.
Every step
- Propose model
- Check authority
- Approve rules, or a person
- Act tools
- Verify with the real system
back to the model, carrying what it now knows: repeat, finish, or stop and ask a person
Back to the trip. On the first pass, the agent finds a $590 Sunday flight, within policy, but it adds a hotel night. It asks you, and keeps your answer: Monday. The next pass proposes the $980 fare, which waits for your manager. When the approval comes, maybe the next day, the agent picks up where it left off. It checks the fare hasn’t moved, books it, and confirms the ticket with the airline.
That state is what makes it an agent rather than a one-off answer: what it knows, what’s been approved, what’s done. It’s also why memory and the data layer matter so much.
And it needs exits, written down in advance. It stops when the goal is met, when time or budget runs out, or when the next step needs a person. Without those exits, you’ve given a loop the company credit card.
Who’s in charge
When the agent reaches a limit, it needs to know who decides what happens next. That depends on how the work started.
- A person delegates to an agent. The agent should never have more authority than the person who asked. If you can’t book first class, neither can the agent booking for you.
- A workflow calls an agent. The agent is one step in a larger process, and the process owner owns the outcome.
- An agent hands work to another agent. This is the hardest case. Authority should narrow as work is handed on, never widen. Every handoff should be recorded, so you can follow a result back to whoever is accountable for it.
That’s what I mean by accountability. An agent can’t be accountable the way a person is. The system has to make it possible to trace every outcome back to someone who is.
Before you trust it with real work
Before an agent touches anything that matters, I’d check these, most important first:
- Its goal and limits are written down, and the limits are enforced in code the model can’t talk its way around.
- It acts under its own identity, with no more authority than the person it works for.
- Exceptions wait for a named person, and someone can stop it at any time.
- Every action is recorded, and a named person owns the results.
- After a failure, it checks before retrying, and stops if it can’t tell.
- It’s been tested on realistic tasks, including ones it should refuse.
A better model doesn’t remove any of these. Most of them are old engineering: identity, permissions, transactions, logs. What’s different here is that a model chooses the next step, and its choice can vary even when the task looks the same. So everything around it has to be more dependable than ever.
Open questions
That list is where I’d start. Two questions I don’t think anyone has fully answered yet:
- When an agent hands work to another agent, how do you prove the second one never had more authority than the person who started it?
- Which decisions should an agent never make on its own, however good the model gets?
Model with tools, or enterprise agent
So, should the agent book that $980 flight on Thursday evening? Not on its own judgement. Only after your manager approves the higher fare and the system records it. Then it checks the price, books within the approved exception, and confirms the ticket with the airline.
The model brings the judgement. The system brings the terms: who it is, what it may do, who oversees it, who answers for it, and whether you can count on it. That’s the difference between a model with tools and an enterprise agent.
continue reading
Is your data layer ready for agents? The case for Lakebase
Agents need a disposable workspace and a durable record. Here's where Databricks Lakebase fits, in plain terms, and what it still leaves to you.
When the database's newest user is an agent
When a whole company books travel through agents, the database gets a new kind of user: many, fast, and often wrong. What that asks of the data layer, and why branching alone isn't enough.
What an agent remembers
An agent books your flight, then crashes before writing it down. When it restarts, does it book again? What an agent remembers, and why some of it has to survive a crash.