Your first agent: which process to start with

At most companies the first AI agent fails because it gets the most exciting job instead of the most boring one. The first one has exactly one task: to prove the system is dependable. So start with work that comes back every week, that you can write down in steps, that has everything it needs already on paper, and whose result you can judge at a glance.

What is an AI agent?

An AI agent is a program that uses a language model to run a piece of work on its own: it reads what comes in, decides the next step, uses the tools you connect (mailbox, spreadsheet, invoicing), and puts down a result. It does not discuss the work. It does it, and reports back.

The difference from a chatbot is not the model, it is access. A chatbot answers a question and lets go. An agent holds a key to something: a mailbox, a folder, your invoicing tool, and whatever it does there leaves a trace. We wrote about that split separately, in case that is where you are right now: when a chatbot is enough and when you need an agent.

It has three parts, and the model is only one of them:

• The instructions. Not one sentence, but the process written out: what comes in, what counts as a good result, and what to do when something is missing.
• The tools. What it can touch: mailbox, spreadsheet, folder, your admin system. What you never hand over, it cannot break.
• The limits. What it may do on its own, where it stops, and who it asks.

Two of those three come from you. That is why the first agent is not a technology question. Today's models are more than capable of the daily work of a small company; the written process is what tends to be missing. Repeating work usually lives in one person's head, in the way that person does it, not in the way anyone ever wrote it down.

The word agent says nothing about size, by the way. There can be one of them, taking a single repeating task off your hands, and there can be a dozen of them handing work to each other. The only question between the two is which one gets built first, and the first one is always the small one.

Which process should you start with?

The one that comes back every week, that can be written down in steps, and whose result you can judge at a glance. Typically sorting incoming mail, pulling data out of what arrives, building a quote from a template, putting together the weekly summary. Give the first agent your most frequent work, not your hardest.

Look back at last week and find what repeated. The question is not which task annoys you most, it is which one you did the same way for the tenth time. Repeating work makes a good first job because you already have a yardstick: you know what a good result looks like, because you have produced it a hundred times.

A few processes most small companies already have:

• Sorting incoming mail. Which one is a request for a quote, which is a complaint, which is an invoice, and who it belongs to. A wrong call takes one move to correct, so it is cheap to learn on.
• Pulling data out of what arrives. Name, address, quantity, deadline from an email or a PDF, straight into the spreadsheet. The catch is not the extraction but the format: if two date styles live side by side at your company, that has to be settled first.
• Building a quote from a template. The items and the prices come from you, the agent assembles them and puts them into shape. It only works if the price list sits in one place, not in three tables reconciled from memory.
• The weekly summary. What sits in four places ends up in one, in the same shape, at the same time. Its advantage is that a mistake jumps out at whoever has been looking at the same table for weeks.

What not to start with: anything whose output reaches a client without review, and anything only one person can do, mostly on instinct. The first agent does not need to be heroic, it needs to earn trust. Once the first piece of process automation has run cleanly for a good while, nobody needs convincing about the second.

Boring work is a good pick because a mistake on it is cheap. If the agent files an email in the wrong place, someone moves it back, and that is that. A quote sent out wrong does not behave that way. What the first one measures is not how much it saves, it is where your written process actually stands.

How do you know a process is a good fit?

Four questions have to come back yes: does it repeat, can someone describe it step by step, is everything it works from written down, and does a bad result show on the output. A single no means the agent is not what is missing. The written process is, and a person writes that.

Those four questions are a short test, and you can run it yourself before you talk to anyone about building anything:

• Does it repeat. If it happens once a month, the first agent never gets enough chances to prove itself, and you never gather enough experience to trust it.
• Can it be written down in steps. Sit down with whoever does it and have them talk it through. If the explanation swerves into "well, it depends" three times, what is missing is a decision, not an agent.
• Is the material written down. Price list, rules, past emails, product data. If those live in someone's head or in ten different places, the first step is not the agent, it is putting a company knowledge base together.
• Does a bad result show. Someone has to be able to tell at a glance whether the output is good, without having to check it against anything. If the mistake only surfaces weeks later, fixing it costs more than the process automation ever saved.

The third one is where most companies stall, and that is a matter of order, not a problem. The write-up is not wasted even if no agent ever gets built: it is exactly what you need to train a new colleague. It usually shortens the work as well, because putting a process on paper knocks out a few steps nobody could justify.

How long does the first one take to build?

We measure it in stages, not in elapsed time. A short conversation settles what the process does today and what counts as a good result, then a written proposal follows. The build moves in stages, and each one ends with something you can look at. The first visible result is the agent's narrowest working version.

That first conversation is not about which model goes in. Four things have to be settled: what comes in, what counts as a good result, what the agent gets access to, and who reviews it. The written proposal follows from that, and it also says what is not included.

What slows the build down is not the development. Handing over access, gathering the examples, and deciding what the right answer is in an edge case: all three land back with you. That is why it is worth naming at the first conversation who owns all three, because that is what decides whether the stages have to wait on each other.

From there the build moves in stages. The result of the first stage is usually the narrowest working version: one process, few tools, a human approval before every step that matters. That is not timidity, it is measurement. This is where you first see how far the written process sits from what actually happens in the office.

Widening comes next: more cases handled, fewer questions back, broader access. An agent is not finished just because it was delivered, though. Email formats change, a rule changes, a new model arrives, and someone has to attend to it. That is why monthly operation is available after delivery, and why the first agent should sit on a process that has an owner on your side too. For what that looks like in practice, see agentic systems for small and mid-sized companies.

What happens when the agent gets it wrong?

It will get things wrong, so the first question is not whether that can be prevented, but whether it surfaces. Every step is logged, irreversible actions sit behind an approval, and a switch stops it instantly. The mistake then becomes a rule: we write down what went wrong, and it knows that from then on.

An agent does not fail the way a script does. A script crashes and stops. An agent produces something that looks plausible and simply is not right. So "it works" is not enough: you have to see what it did, and on what basis.

Three things give you that:

• A log of every step. What it read, what it decided, what it wrote out. You have to be able to read it back afterwards, otherwise you never find out where it went off.
• An approval before irreversible steps. An email going out, an invoice issued, data deleted. The agent gets that far on its own, then stops before the last step, and the approval stays with a person.
• A stop switch. One move shuts it down, without anyone having to touch code.

That way a mistake is not a disaster, it is information. A bad result does not turn into an embarrassment, it turns into a line on the rule list, and on the next run the agent holds itself to that as well. On a properly run agent the list of mistakes tends to shrink rather than grow.

One thing the best log in the world will not settle, though: responsibility does not transfer to the program. Whoever's name is on the email going out in the company's name is the one answering for it. That is not a technical question, and it is the single reason not to strip the approval points out once it is running in.

AI is the tool. A human answers, a human decides, a human delivers.