An AI agent receives a trigger and decides what to do with it. Then it writes the result into a real system your team already uses. That last part is the whole distinction. A chatbot produces an answer on a screen. An agent produces a CRM record, a ticket, a Slack message that somebody has to act on. If the thing you were shown in a demo never touched a system of record, you did not see an agent.
What are AI agents, and why the word keeps sliding
The term now covers almost anything with a language model inside it. Useful definitions are narrow, so here is a narrow one. An AI agent has a trigger and some autonomy over what happens next. It also has access to an external tool and the right to change state in it.
Strip any of those four and you have something else:
| What it has | What it is |
|---|---|
| Answers in a conversation, no tool access | A chatbot |
| Fixed steps, no decisions, no model | A script or an automation |
| Model decides, but only returns text to a human | A drafting assistant |
| Trigger + decision + tool use + write permission | An agent |
Agent vs chatbot, agent vs script
The agent vs chatbot line is about consequences. A chatbot can be wrong and nothing happens except that you read a wrong sentence. An agent can be wrong and a contact exists in your CRM that should not.
The agent vs script line is about input. Scripts are excellent when the input is predictable: same fields, same order, same shape every time. Then the input becomes a photo, a forwarded email, or a sentence a salesperson typed in a hurry. The script has nothing to grip. That is the gap where ai agents for business earn their place. Not because they are smarter, but because they turn messy input into structured output that code downstream can consume.
Autonomy is the word that causes the most trouble. In most working systems it is far smaller than the marketing suggests. Autonomy usually means the model picks which field a piece of text belongs to. Or which of three routes a request takes. It rarely means the model decides business outcomes. In the systems that survive real users, it never does.
How an agent is actually put together
Most working ai agents have four parts, and only one of them is the model.
1. The trigger. Something has to start the chain. That can be a message posted in a channel, a file dropped in a folder, a form, a webhook, or a schedule. Triggers are boring, and they are where projects quietly go wrong. Teams pick a trigger that requires people to change their habits, and nobody uses it.
2. The model step. This is where unstructured input becomes structured output. A photo becomes fields. A paragraph becomes a category and a priority. The output of this step should be data with a known shape, not prose. Everything downstream is code, and code needs fields.
3. Tool use. The agent calls something real: a CRM API, a ticketing system, a database, a messaging platform. This is the integration work. It takes the most time to build. A demo can skip it entirely, which is why it never shows up there.
4. The hand-off. A human ends up with something to do, and it is clear who that human is. An agent that produces work assigned to nobody produces nothing.
Which business process makes a realistic first agent
Look for a process where three things are true at once. The input arrives unstructured. The output is a record with defined fields. And the volume is high enough that people have started cutting corners.
Those three conditions describe the ai agent use cases that survive past month one. Lead capture, inbound request triage, document intake, meeting notes that need to become tasks.
The inverse is also a useful filter. If the input is already structured, write a script. If the output is a judgement call rather than a record, keep it in a person’s hands. And if it happens twice a month, the maintenance will outlive the benefit. Our piece on when an automation actually pays for itself works through that arithmetic in detail.
What an agent needs access to before it is useful at all
Access is the gate. Before anything else, an agent needs a place to read from and a place to write to. The credentials should belong to it, not be borrowed from someone who might leave.
In practice that means an account in the target system and a scoped API key. It gets permission to create but usually not to delete, plus a channel where it can report what it did.
Teams routinely underestimate this step, because in a demo the access already exists. In a real company it involves someone with admin rights, a conversation about scope, and often a security review. Budget for it.
An example from our practice
We built one of these for ourselves, and it is deliberately unglamorous.
After conferences we came back with a stack of business cards. Somebody had to type them into the CRM: name, company, email, phone, plus whatever was scribbled on the back. It was slow, and it happened the week after a conference when everyone was already behind. The errors were the ones you would expect from transcription under time pressure.
Now the chain runs like this. Whoever collected the card photographs it and drops the photo into a dedicated Slack channel. That post is the trigger. The ChatGPT API reads the image and extracts the fields: name, company, email, phone, and the notes. HubSpot receives that structured output. It creates a contact plus a follow-up task, assigned to whoever uploaded the photo.
Where the model stops
Notice where the model sits in that chain. The model does not decide whether the lead is worth pursuing. Nothing in the chain writes the follow-up email or ranks anything. Converting a photograph into fields is the entire job. A person still decides what the follow-up should say, and whether it happens at all. The human in the loop here is not a safety blanket bolted on afterwards; it is the design.
What makes it an agent rather than a clever prompt is the write permission. It has a Slack channel to watch and a CRM record it is allowed to create. Remove that and the same model doing the same extraction is just a nice answer nobody acts on.
One more design decision matters more than it looks. Sometimes the extraction is wrong: a smudged card, a logo read as a company name, a phone number missing a digit. The result is posted back into the same channel the photo went into. The person who uploaded it sees what was captured, right there, next to the image. A bad read is visible within seconds. It does not sit in the database until a sales rep calls a dead number. Silent failure is the expensive one.
The full build is written up in our business cards to HubSpot case study. The operational side is covered in how that kind of chain runs inside a small sales team.
What to watch out for
Scope creep into judgement. The most common failure is not technical. It is someone asking, reasonably, whether the agent could also score the lead, or also send the first email. Each addition moves the agent from converting data to making decisions. Guardrails that were adequate for extraction are not adequate for that. Keep the scope written down and treat expansion as a new project with its own review.
When it goes wrong
Invisible failure modes. Every agent has a failure mode. The question is never whether it will misread something, but where the misread surfaces. Design the visible path first: which channel shows the error, who sees it, how fast. If you cannot answer those three, the agent is not ready.
Confidence that reads as correctness. A model returns a confidently formatted answer whether or not it understood the input. There is no natural signal that says “this one was a guess.” That is why the output belongs in front of a person rather than straight into a report. We covered those limits in what you can and cannot build with AI.
Ownership after launch. An agent depends on APIs that change, credentials that expire, and a channel someone might archive. Somebody has to own it. If no name goes next to it at launch, it will break quietly. You will hear about it from a customer.
Measuring the wrong thing. Pick the measure before you build, and pick one you already track. For the business card chain, that is the time a card takes to become a contact with an owner. And the share of contacts with fields that are simply wrong. Both were measurable before the agent existed, which is what makes the comparison honest.
How do you tell whether it is working
Three questions, answered from data rather than impressions. Did the volume going through the chain hold up after the novelty faded? Did the per-item time drop against the number you recorded beforehand? Are errors caught by a person at the point of entry rather than discovered downstream? If all three hold after a couple of months, you have a working system. If the first one fails, the trigger did not fit how people work. No amount of model quality fixes that.
Conclusion
Most agentic ai use cases worth building come down to the same shape. A messy input, a model that turns it into structured output, a real system that receives it. And a person who still decides what happens next. The autonomy is narrow by design. Custom ai agents earn their keep by removing transcription and routing work from people. Not by taking over the judgement those people are paid for.
Start with one process where the input is unstructured and the volume is real. Give the agent exactly the access it needs. Make its mistakes visible in the same place its work appears. Want a second opinion on whether a process in your company clears that bar? Our AI solutions team looks at these for a living.
