Short answer
An AI agent is software that pursues a goal by choosing its own next step, calling tools as it goes, instead of following a fixed sequence you drew in advance. In a company of 10 to 100 people it pays off where the input is messy and the decision cannot be enumerated — triaging inbound requests, drafting quotes from unstructured briefs, answering questions from internal documents. Where the path is knowable, a plain automation is cheaper, faster and far easier to debug.
What an agent is, without the marketing
Strip the term back and an agent has three properties. It has a goal rather than a script. It has tools it can call — a search, a database query, an email draft. And it decides at runtime which tool to use next and when the job is done.
That third property is the whole thing. A workflow with a model call inside it is not an agent; it is an automation with a smart step. Vendors blur this deliberately, because "agent" prices better. The distinction matters to you because the two have completely different failure modes and completely different costs to operate.
Under the hood, the mechanism is unglamorous: the model is given a list of tools with descriptions, it returns a request to call one, your code runs it, and the result goes back into the conversation. Anthropic's documentation on tool use lays out the loop plainly. There is no magic in the box, which is reassuring once you have seen it.
The test for when an agent is warranted
One question settles most cases: can you draw the flowchart?
If you can draw it — even a large, ugly one with forty branches — build the flowchart. It will be cheaper, it will run in milliseconds, it will fail in ways you can read in a log, and it will do the same thing tomorrow that it did today. If you genuinely cannot draw it, because the next step depends on content you have not seen yet, you have a candidate for an agent.
Most projects sold as agent projects are flowcharts that nobody sat down to draw. The drawing is the hard part and the model is being used to avoid it. That works for a demo and becomes unmaintainable in production.
A second, blunter test: what is the cost of a wrong decision, and who notices? If a wrong decision is invisible until a client complains, you are not ready to let software make it unsupervised.
Five that hold up in a small company
These are the patterns we see survive past the pilot in companies of this size.
- Inbound triage — reads incoming email or form submissions, classifies intent, extracts the fields that matter, routes to the right person with a summary. High volume, messy input, cheap to be wrong once.
- Quote and proposal drafting — turns an unstructured brief into a first draft using your pricing rules and past documents. A human always signs. The saving is in the blank page, not the send button.
- Internal question answering — answers staff questions from your own procedures and contracts rather than from the open web. This is retrieval work more than agent work; see making an assistant answer from your files.
- Data cleanup and enrichment — reconciles records that a rule cannot match because the same company is spelled four ways. Bounded, checkable, and genuinely tedious for a person.
- Meeting-to-action — turns a transcript into decisions, owners and dates, then files them where the work actually happens. Its value depends entirely on landing in the real system, not in a summary nobody opens.
Notice the shape they share. Each one ends with a human decision or a reversible action, and each one handles input a person would find tedious rather than difficult.
Where agents quietly fail
The failures that hurt are not the dramatic ones. A crash gets fixed. These do not announce themselves.
- Confident wrong answers. The output looks exactly like the correct output. If nothing checks it, it propagates.
- Silent drift. A source system changes a field name. The agent adapts, sort of, and starts producing subtly different results with no error anywhere.
- Non-determinism. The same input can produce different behavior on different runs. A single successful test proves very little, which makes acceptance testing genuinely harder than for ordinary software.
- Cost creep. A retry loop that fires on an edge case can multiply a bill overnight. Cap the loop and alert on volume, not just on errors.
- Nobody owns it. The person who built it moves on and the agent keeps running, trusted by everyone and understood by no one.
The first three are not specific to agents — they are what any delegated judgment does when nobody is sampling its output, and the sampling method that catches them is set out in the line between rules and judgment. An agent inherits all of them and adds its own: the sequence of actions is chosen at runtime, so a wrong step can be followed by four more before anything looks unusual.
Guardrails that are worth the effort
Not all controls repay their cost. These four do, in our experience.
- Narrow write access. Read widely, write to as few places as possible. Most damage comes from an unnecessary write permission.
- An approval step in front of anything outbound. Client emails, payments, public posts. Drafting is safe; sending is not.
- A full log of every tool call with its inputs. Without it, you cannot answer "why did it do that", and you will be asked.
- A hard cap on iterations and spend per run. Loops are the failure mode that costs money rather than credibility.
Worth noting: none of these are AI-specific. They are the controls you would put around a junior employee with system access, which is the right mental model.
How to start without betting the quarter
Pick one process. Pick it because it is annoying and frequent, not because it is strategic — strategic processes have too many stakeholders for a first attempt. Run the agent in draft mode for a fortnight while a person does the work normally, and compare the two outputs.
That comparison is the whole decision. If the agent's draft is usable most of the time, you have a case. If it is wrong in ways that take longer to check than to redo, you have learned something cheap and true. Either way you have avoided the pattern where a system goes live, nobody measures it, and its value stays a matter of opinion — the same trap we describe in measuring automation ROI honestly.
If the flowchart turns out to be drawable after all, that is a good outcome, not a failed project. It means you can build it with a workflow tool — the territory covered in automation without developers.
Frequently asked questions
What is the difference between an AI agent and an automation?
An automation follows a path you drew. An agent chooses the path at runtime, using a model to decide which tool to call next and when the job is finished. The practical consequence is that an automation fails loudly and predictably, while an agent can fail creatively — doing something reasonable that nobody asked for. You take on that risk when the decision genuinely cannot be enumerated in advance, and not before.
Do we need an agent framework, or is a workflow tool enough?
For most companies of 10 to 100 people, a workflow tool with one model call inside it covers the majority of real use cases. Frameworks earn their keep when a task needs several tools chosen dynamically, memory across steps, and retries with different strategies. Starting with a framework because it sounds current is the most common way to end up maintaining infrastructure that solves a problem you did not have.
How do we stop an agent doing something damaging?
By scoping its permissions rather than trusting its judgment. Give it read access broadly and write access narrowly. Put an approval step in front of anything that leaves the building — an email to a client, a payment, a public post. Log every tool call with its inputs. An agent that can only draft is a fraction as useful as one that can send, and vastly cheaper to be wrong about while you learn what it does.
How much does it cost to run?
The model calls are usually the small part. The costs that surprise people are the ones around it: the person who reviews the output, the integration work when a source system changes its format, and the debugging time when an agent behaves differently on the same input twice. Budget for the surrounding work, then treat the model bill as a variable you can tune later by routing simple steps to a cheaper model.
If you want an outside read on which of your processes justify an agent and which do not, that is a conversation we have most weeks. Book a call and bring the process that annoys you most.
