Six things to know before putting an AI agent to work in a company

An AI agent is not magic. And it is not “build an agent, automate everything, cash in” either. Most people do not know what an agent is; among those who do, many build one and watch it fall apart. It makes up a figure, forgets what it was doing halfway through the task, calls the wrong tool at the wrong moment. It works perfectly in a demo and breaks on day one in production.

These are six things we learnt building Ditta, where a virtual employee works every day on the accounts of real companies. They hold for those who build agents and for those who buy them.

1. Context is everything

It is the most obvious thing and the most neglected. Building an agent is not chaining tools: choosing a model, giving it access to the data and letting it figure out what to do. An agent like that sees only the step it is on, guesses and hopes.

Context is the difference between an agent that is worth something and one that is worth nothing. What it remembers: if it is handling an anomalous invoice it has to know what triggered the anomaly, who the supplier is, which rule applies, what happened last time with that supplier. How it passes information on: when one step hands over to the next, the data has to arrive clean and structured, or everything after it breaks. What it knows about the trade: credit notes, VAT, reverse charge, payment terms are not guessed from the documents. They have to be given, in a form the agent can use.

An agent with poor context is the one that calls the same tool twice because it forgot the answer, or takes a decision contrary to what it learnt two steps earlier. An agent with good context works like a person who knows the trade: it connects the dots without anyone telling it how.

2. Agents multiply, they do not replace

The wrong way to think about it: “so we do not have to hire”. The right way: “so three people do what used to take fifteen”. Agents do not remove the need for human judgement. They remove the friction around judgement: the searching, the gathering, the cross-checking, the formatting, the chasing.

An admin office still has to decide what to do with the exceptions. But instead of spending the close week looking for missing documents, it spends it resolving cases. The agent did the work, the person approves it. And this also means you start sooner: you do not need an agent that handles every edge case, you need one that handles the common cases well and brings the odd ones to a person with enough context to close them in a minute.

3. Memory and architecture

How an agent keeps information along a task, and from one task to the next, decides whether it works at scale. Three patterns always come back. One agent doing a whole flow, start to finish: simple, but at step ten it has to remember what it decided at step three. Several agents in parallel on different pieces of the same problem: fast, but you have to decide how the results come together and who decides when two reach opposite conclusions. Agents in sequence, one triages, one investigates, one resolves: natural when the work has stages, but the handovers are where things break.

These are not implementation details. They are architecture decisions, and they count more than the choice of model. Get them wrong and you spend months hunting bugs that are not bugs: they are the wrong shape for the problem.

4. Catch exceptions, do not make dashboards

The instinct of anyone building systems with AI is to show information. A dashboard with open cases, average times, percentages. But administration already knows the receipts are missing. Sales already knows a contract is stuck waiting for a signature. A dashboard is where problems go to die.

An agent has to catch the problem when it is born and bring it to whoever can fix it, with everything needed to fix it, right away. An invoice without the required documents does not go into a report: it is flagged now, to the right person, with the supplier, the amount, the rule that applies and the document that is missing, and it is not booked until it is resolved. The dashboard, if anything, comes later, when the problem has almost disappeared.

5. Software that does not adapt and software that learns

There is a reason companies keep buying programs nobody then uses. They are easy to buy: they have a demo, a price and a box to tick next to a need. Someone approves and feels that something has happened.

Then the program sits there. It does not fit the way the work happens, it becomes one more place to log into, and after a year it is abandoned but impossible to remove. Every extra tool is an integration to maintain and a vendor who may change their mind: debt accumulates.

An agent built on the systems the company already has does the opposite. It works inside those systems, it creates no new place, and every correction makes it better: capability accumulates. It is the difference between renting a tool that will be replaced and building something that grows with the company.

6. Timing

If the project plans a year before anything goes into production, it is already lost. The plan does not survive contact with reality: the flows drawn on paper are not the real ones, and the cases nobody foresaw are precisely the ones that matter. And in a year the field will have changed three times.

You go into production in a few weeks, on a real job, with real decisions and a trace of every action. Then you improve every day, with people’s corrections. The best agent is the one that runs and improves, not the one still being designed.

In short

Context is the whole game: an agent without context is a very expensive random number generator. You design to multiply people, not to replace them. Architecture counts more than the model. You catch and resolve, you do not report and review. You go into production early and improve always. Everything else is detail.

The starting point was an article by Varick Agents, who put agents into production for large groups. The lessons match ours, at a different scale.