What is an AI agent in a business process?

An AI agent is software that uses a language model to decide something small inside a business process: which category this message belongs to, which fields are on this supplier invoice, whether this reply needs a person to read it before it goes out. It then acts on that decision through a limited set of tools you have authorised.

What separates an agent from a chatbot is scope. How many systems it can reach, what it is allowed to do there, and the point at which it stops and asks somebody.

What is an AI agent good for?

Agents work on steps that resist rules: ambiguous requests, unstructured documents, wording that changes with every customer, judgement calls where no one on the team can write down the decision tree. Where a determinate rule does exist, ordinary code is cheaper, faster to test and easier to audit, and putting a model there only hides the logic from whoever has to fix it later.

Most agent projects we are asked to rescue got into trouble by using a model where an if statement would have done. It raised the running cost, obscured the behaviour, and made the system harder to trust than the rules it replaced.

What tools does an agent need?

An agent acts by calling tools: create the invoice, look up the order, post to the channel, fetch the document. Each tool needs a narrow argument list, defined behaviour when it fails, and a log line every time it runs, because the tool call is the only part of an agent's work you can replay afterwards.

The thing we usually find instead is a shell account and one broad credential. That is what gets these projects shut down at security review.

How is an agent kept under control?

Four things do the work: credentials scoped to that agent alone, an allowlist of actions with the irreversible ones held behind human approval, an audit trail of every input, tool call and output, and a written procedure for stopping the agent and handing its queue back to a person the same day.

All of that is ordinary access control and observability. Having a model in the loop changes what you log, not what you need.

How is an agent isolated in practice?

With its own operating-system account. Each agent we deploy runs as its own Linux user, with its own home directory, credentials, logs and reachable filesystem, so an instruction it should not have followed cannot read another agent's data or touch anything else on that server. Take that approach and revoking an agent becomes a command you run instead of a support ticket you wait on.

Agents sharing a user, a credential or a filesystem are a defect, and we treat them that way. The setup is in what agent isolation actually means.

Which model does an agent use?

Whichever model fits that agent: a frontier model over an API where the steps need judgement, an inexpensive open-weight model for high-volume classification, or open weights running on your own hardware where the data cannot leave the building.

Because the choice is configuration rather than architecture, it can differ agent by agent and change when prices or model versions change. Open-weight versus frontier models covers how we test candidates, and AI agents: integration and management covers how the delivery works.