What is an AI agent?
An AI agent is a system that is given an objective rather than an instruction, and works towards it in a loop: it decides what to do next, uses a tool to do it, looks at what came back, and decides again. The distinguishing feature is not intelligence. It is that nobody has to supply the next step.
How one actually works
Underneath, an agent is a loop around a language model. The model is given the objective, a description of the tools it can use, and the record of what has happened so far. It responds with either an answer or a request to use one of those tools. The surrounding program, not the model, actually executes that request and puts the result back into the record. Then the loop runs again.
The tools are the part people underestimate. A model on its own can only produce text, so everything an agent does in the world happens through a tool somebody defined: query this database, read this file, call this API, send this message. The set of tools available is therefore the exact boundary of what the agent can do, which makes it a security decision as much as a capability one.
Observation is what makes it a loop rather than a script. The agent sees the actual result of each action, including failures, and can respond to what it finds instead of following a path decided in advance. That is the entire reason to use an agent for a task rather than ordinary automation: it handles a shape that is not fully knowable up front.
Memory determines whether it can do anything substantial. Without it the agent starts every run cold and re-derives everything it knew last time. With persistent memory it carries state forward across steps and across separate runs, which is the difference between answering a question and working a task over days.
Agent, chatbot, or a single call
Most things sold as agents are one of the other two, which is not a scandal. Plenty of valuable work is a single call, and paying for a loop you do not need is a real cost.
| Shape | Steps | Tools | Memory | Suits |
|---|---|---|---|---|
| A single model call | One | None | None beyond what you paste in | Rewrite this paragraph. Classify this message. |
| A chatbot | One per turn | Rarely, and usually one | The current conversation | Answer questions a person asks in sequence. |
| An agent | As many as the task needs | Several, chosen at each step | Carried across steps and across runs | Work through a task nobody is watching. |
What production adds
First-hand. This describes HDS's own delivery infrastructure, which is on the work page as internal ai agent platform (hds), and which built this site.
Everything above describes an agent that works. Almost none of it describes an agent you can leave alone, and the gap between those two is where the actual engineering lives. Three things carry most of that weight.
Persistent memory. Work that spans more than one run needs state that survives the run. Without it every session begins by rediscovering context, which is slow, expensive, and a reliable source of contradictions between one run and the next.
Review and verification as first-class agents. The most useful structural decision is to make checking a real role rather than a step the builder performs on its own output. An agent reviewing another agent's work catches a category of error that self-checking reliably misses, because the thing that produced a mistake is the worst candidate for noticing it.
Audit-grade logging. Every action recorded well enough to reconstruct afterwards what the system did and why, for somebody who was not there. Without it an agent is not debuggable and cannot be trusted with anything consequential, because there is no way to establish what actually happened when something goes wrong.
Those three are why this platform can be pointed at real work. One principal runs several workstreams in parallel, because review and verification are automated rather than queued behind a person. The agents that built this site are the same ones used in client work.
Where agents are the wrong tool
When the task is deterministic. If the steps are fully known and the same every time, ordinary automation is faster, cheaper, and cannot improvise. Wrapping a settled procedure in a loop that reasons about it each run adds cost and variance for nothing.
When errors compound invisibly. A long chain where step three's mistake is only detectable at step twelve is a bad shape for an agent, because the loop has no natural place to notice. Either the task gets broken into checkable pieces, or it is the wrong task.
When the answer has to be right and cannot be verified. If there is no way to check the output and the cost of being wrong is high, the correct design keeps a person in the decision rather than claiming a confidence the system does not have. That is a limit of the approach, not a limitation of a particular implementation.
And when the process itself is not understood. Agents amplify whatever they are pointed at, so pointing one at a process nobody can describe produces a faster, more expensive version of the confusion. That work needs doing first, by people.
Where an agent does fit, the tool it reaches for most often is retrieval over private documents, which is how it answers from material the model was never trained on. How HDS builds both, and where the practice draws its own limits, is under AI and autonomous systems.
Common questions about agents
Is an AI agent the same thing as a chatbot?
No. A chatbot responds to a person, one turn at a time, and the person supplies the next step. An agent is given an objective and decides its own next steps, using tools and observing what came back, until the task is done or it gives up. The difference that matters commercially is that nobody has to be sitting there.
Do agents actually work, or is this still a demo technology?
Both, depending on the task. Agents work well where each step can be checked, where a wrong turn is recoverable, and where the tools available are reliable. They work badly on long chains where an early mistake quietly poisons everything after it. The honest question is never whether agents work but whether this particular task has those properties.
What stops an agent doing something destructive?
Design, not the model. The step that decides and the step that acts are separated, consequential actions sit behind a gate a person passes, and the tools an agent is given are scoped so the damaging thing is not reachable in the first place. An agent that could not delete the database is safer than one that has been asked nicely not to.
How many agents does a real system need?
Usually more than one and far fewer than the diagrams suggest. Splitting work across specialised agents helps when the roles genuinely differ, particularly when one agent checks another rather than everyone building. Splitting for its own sake adds coordination cost and more places to go wrong, which is a real expense paid for a diagram.
Could we run this over our own documents?
That is the most common first use and it is a different mechanism worth understanding on its own. Retrieval augmented generation is how a system answers from a private corpus with citations back to the source, and it is frequently the tool an agent reaches for rather than a competing approach.
Still deciding whether an agent is the right shape for the task?
Start with a free scoping conversation with Mike Hyams, the person who builds and supports the work.