AI Agents for Business: 5 Things to Know Before You Build

AI agents for business are quick to start and hard to leave alone. I build them for businesses, taking on work that was being done by hand: researching, writing, pulling reports together, summarizing calls, and moving jobs along faster. I run a set of my own for the same reason, and the worked examples below are those, because they are the ones I can open up in public. Most of what has gone wrong was not the model failing to be clever enough. It was a step that took more than ten minutes to return anything at all, a tool with no way in, a job scoped too widely to check, and one afternoon where an agent was confidently wrong and I believed it. Here are the five things I would tell myself before that first build.

Key Takeaways

• A model that is wrong and sure of itself is the failure to design for. A better model does not remove it.
• Pick one job you can say in a single sentence, with a clear trigger and a clear output.
• Whatever the agent knows about your work, you put there. Find out which file that is and whether you can edit it.
• Let it prepare actions before it can commit them. Anything you truly do not want it doing, take the access away rather than asking it not to.
• Time the job by hand before you start, then track the upkeep for two weeks. An agent whose maintenance outweighs the job it took over is costing you time while looking like it saves it.

Short on time? Jump to your first agent checklist and start there.

What AI agents for business actually do

An AI agent is a model that has been given tools and permission to use them, so instead of answering you it goes and does something: reads a file, updates a spreadsheet, drafts an email, posts an update. Most of them work in a loop, taking one action, looking at what came back, and choosing the next one, until they decide the job is done. That last part is the whole difference. A chat window produces words and stops. An agent produces an action, and the action lands somewhere real.

Which is why the useful question was never "is the model any good". It is "what happens when the model is wrong and the action lands anyway".

1. Plan for the confident wrong answer

Agents get things wrong, and a job made of several steps gets more chances to. The part worth building around is how certain they sound when they do.

The clearest example I have came from my own writing setup. It has a checking step whose entire job is to catch bad claims before anything goes out. On one run it answered from memory instead of opening the source, and gave me a version number that was wrong plus a setting that did not exist. On its own that is a small problem. What made it a real one is what came next: I had already made a correction, and the invented answer was used to argue against it. My version had been the right one. The step was not simply wrong, it was wrong with enough conviction to push a correct answer off the table.

A smarter model might guess right more often. It would still be guessing, because nothing in that step required it to look, and that is a design choice rather than a capability one. The repair was to make the guess checkable. A claim now has to arrive with its source and the quote it came from, so checking it means opening a link rather than trusting a verdict. It can invent a quote too, which is exactly why the check is me opening the source. That is weaker than taking access away, and worth knowing as weaker: it is what you are left with when the thing you want to prevent is a guess rather than an action. It also no longer gets the last word over a correction I have already made.

Expect a version of this, and decide before you build which of its answers you would notice being wrong. That single question shapes where the checks go.

2. Pick one boring job you can say in a sentence

The tempting place to point a first agent is the messiest part of your week, because that is where the time goes. It is the wrong end to start from. That work is messy precisely because it runs on judgment calls and exceptions nobody has written down. An agent may pick some of them up from your examples, but you cannot count on which ones, and you have no way to check.

Before you build your first AI agent, write its job as one sentence with a trigger and an output. "When a new inquiry arrives, draft a reply from one of my saved templates and flag anything that fits none of them." That works because every part of it is bounded: you know when it should run, you know what it produces, and you can tell at a glance whether it did the job.

"Handle my inbox" is not that. No trigger, no defined output, and no way for it to be wrong in a way you would catch.

Start as close to deterministic as you can. Not that the model returns identical words every time, it will not, but that the job has one right shape of answer, so you can tell at a glance whether a run came out right. Where a judgment call has to stay in, keep it narrow and put guardrails around it: name the handful of choices it is allowed to make, and say what happens to anything that falls outside them. A task you already do the same way every week gives you something to hold the agent's output against, so you see the gap immediately. A task you approach differently each time gives you nothing to check it with.

3. Whatever it knows about your work, you put there

"It learns how you work" is an easy promise to take at face value: use the thing long enough and it will come to understand how you do the job. What actually happens is narrower. In ordinary use the model itself does not change from working with you. Some products do keep notes between sessions, but those notes are written from what you gave them and stored as a file somewhere, rather than learned into the model. Everything the agent appears to know about your work is context handed to it on each run: your past examples, your written process, your tone, and your rules.

That is a perfectly good mechanism, and it is how you get output that sounds like you. But it means the thing holding your standards is a document, and documents go out of date. So the question to settle early is a practical one: which file is it, and can you open and change it yourself in under a minute? If the answer is no, you have no way to correct the agent as your process moves on, and your process will move on.

My writing agents read a voice file and a running log of corrections. When something comes out wrong I go and fix the rule, not the sentence, so the next run starts from the corrected version. That loop is the part that compounds. Without somewhere to put a correction, you explain yourself again, forever.

4. Give it a draft mode before you give it the keys

The most useful habit I have is that a new agent starts out preparing actions without committing them.

It writes the email and has no way to send it. It writes into a holding folder and the real one is out of reach. It produces the row and hands it over. Once I can name the way it goes wrong, and I have watched the thing that catches it do so on ordinary runs rather than once on a demo, I widen what it can touch. Two of my publishing channels sit in draft mode permanently, where the agent assembles the post and I release it, because those two are public and a mistake there is not quietly fixable.

Five things matter here.

A rule in a prompt is a request, not a control. Telling an agent to leave something alone holds until the run where it does not, and nothing warns you that this is that run. If there is a folder, an account, or a button you never want it near, take the access away rather than writing the instruction down. Anything you are relying on it to choose not to do, it can do. This works where what you want to prevent is an action, because an action runs through something you can close. Where what you want to prevent is a bad judgment, you are back to an instruction plus a way to check the result, and that is the weaker position to be in.

Looking at something and altering it are two different permissions. Treating them as one is how an agent ends up rewriting a file it was only meant to consult. My original material sits in folders it can open but not touch, and there is exactly one folder it is allowed to write into.

Make it leave a trail you did not have to trust it for. Every run should leave behind what it looked at, what it decided, and what it changed. The version worth having is written by the tools rather than by the agent: the log your system already keeps, the file history, the record of what changed and when. A summary the agent writes about itself is least reliable on exactly the run that went wrong. My writing setup files a record for every claim it publishes, and the useful part of that record is not the verdict the agent reached, which is its own account of itself. It is the source and the quote sitting next to the verdict, because those I can open. That feels like paperwork right up until something is wrong on a live page and the answer to "where did that come from" is a link away.

Whatever your agent reads, it can be influenced by. Any text you did not write counts: an incoming message, a page it fetched, a file someone sent. Treat it as something a stranger wrote directly to your agent, because that is what it is. A draft step alone will not cover you here, because the agent has already read, fetched, and written several times over by the time a draft exists, and you are looking at the finished page rather than at the steps. What holds is keeping the two apart: the agent that reads outside messages is not also the one holding the ability to send, to pay, or to publish.

Some of the work never gets handed over completely. Anything a customer will see, anything involving money, and anything you cannot take back keeps a person's name on it. Those are the places where a quick look before it goes out costs you almost nothing, and where you would much rather be sure.

5. Count the minutes it costs you each week

This is the number that decides whether an agent stays in your week.

Whether it works is the easy question. The harder one is what it costs to keep running on an ordinary week. Some of that is your time: the nudges, the restarts, the small corrections. Some of it is a step that works perfectly and is still unusable. And some of it is the part that never got handed over at all. Add it up and compare it against the job it took over. If the upkeep is winning, the agent is costing you time while appearing to save it, and that can go unnoticed for months because no single interruption feels big enough to count.

Not all of it shows up as your minutes. One step in my video setup used a model to plan the edit. When I timed it, it took between 619 and 634 seconds just to begin returning anything, and on the real run with identical input it sometimes never came back inside a twenty minute window. Nothing was broken and the output was fine when it arrived. It was simply too slow and too unpredictable to sit in the middle of a chain, so that step is now off by default and I write the plan myself.

Some of the cost is a wall you cannot automate through. The thumbnail on one of my channels gets picked in the app, by hand, every video, because there is no way in that reaches it. The agent does everything up to that point and then stops, permanently, because that is the shape of the tool.

Measuring this needs nothing fancy. For two weeks, note the minutes any time you correct, restart, or clean up after it. Total them, and compare against how long the task took you before. That is the method, and the time to start it is the first week rather than the third month. If you would rather work through that on your own workflows alongside someone who runs these every day, that is most of what I do in the AI workshop, and you leave with one agent running.

Your first agent checklist

Answer these five before you build. If one of them has no answer yet, that is the part to work on first. The last one is worth doing today rather than later: time the job by hand once, while you still have something to compare against.

Then build the smallest version that does the job in draft mode, run it against work you have already done so you can compare, and widen its permissions once it has earned them.