Agent
Concept
A setup that hands a language model a set of tools and a goal, then lets it take one step after another until the goal is met.
Why it exists
A large language model (LLM) is a program that has read an enormous amount of text and picks the words that plausibly come next. Ask it something and it answers, and that's the whole of it. It can't open a file, can't search anything, and doesn't know what it said yesterday. One question, one answer, done.
So anything that took more than one step turned into a job of carrying material back and forth by hand. That's what happened when Theo at Pagedeck tried to group last quarter's incident reports by root cause. He dug fourteen reports out of the company doc store and pasted them in, got a summary back, read it, typed "these two look like the same cause, check the deploy history," then went and found the deploy records and pasted those in too. The model wrote a paragraph each time. Deciding what to do next and fetching the material was all Theo. It took two hours.
The judgment Theo supplied across those round trips wasn't much: not enough material, go find more; found it, ask again. The model could have made those calls. It just never got the chance. An agent is what you get when you move those round trips over to the model's side.
How it works
The model receives a goal, decides for itself what to do next, calls one of the tools it's been given, reads the result, and goes around again until it judges the work finished. One turn of the loop has four steps.
- The goal and a list of tools go in together. A tool here is a function that the surrounding program runs on the model's behalf when the model names it — document search, calendar lookup, file edit — each described with what it does and what inputs it takes.
- The model picks one step. It produces something like "search the incident reports," naming a tool and the values to pass. Nothing executes at this point. The model only states an intention.
- The program actually runs that tool and collects the result, whether that's fourteen search hits or an error message.
- The result goes back to the model and the loop returns to step 2. The model now decides its next step with that result in hand. When it judges the goal met, it returns a final answer instead of a tool call and the loop ends.
That loop is both the power and the weak point. A step that is 95 percent reliable becomes about 60 percent reliable once ten of them are chained. Worse, if step three grabs the wrong document, the next seven steps proceed diligently on bad material. And when a hallucination slips in — the model stating something false in a confident sentence — the following step treats it as an observed fact.
Cost bites too. The model rereads the entire conversation on every step, and billing tracks the text read and written, so a twenty-step run costs a good deal more than twenty times a single question. Teams therefore cap the number of steps and the spend, and hand off to a person when a cap is hit. Tools that can't be undone, like deleting a file or sending mail, get a human confirmation in front of them.
Where it shows up
Agents fit work where one answer isn't enough and the next move depends on what the last one turned up. Work that maps a single input to a single output doesn't need one.
Engineering uses them the most. Tools that take one issue, find and read the relevant files, make an edit, run the tests, then fix what broke are already in wide use. The fit is good because a test result is an unambiguous score that comes back on every step.
Customer questions are another common home. A chatbot used to be a desk that picked from a list of prepared answers. Built as an agent, it can take "why was I charged twice last month," pull up the billing history, check the refund policy, and answer. Questions nobody scripted get handled.
Summarizing a document or tightening a sentence, on the other hand, needs none of this. A well-written instruction covers it — that's prompt engineering — or, if the answer depends on internal material, retrieval-augmented generation (RAG), which finds the relevant passages and pastes them into the instruction. Spinning a loop for that work only adds cost and failure modes.
How it sounds at work
"This isn't a one-shot question. I think it has to run as an agent."
The task needs more material partway through, so a single instruction won't do it.
"It went twelve rounds, never answered, and burned tokens the whole time. Let's cap the steps."
The loop circled instead of finishing, so cut it off by force.
"Write tools need a human approval before they fire."
Read-only tools can be called freely; anything that changes state goes through review.
At Pagedeck, Theo wired this up first for internal support questions, right after spending two hours grouping those incident reports by hand. He attached document search and deploy-history lookup as tools and capped the loop at eight steps. The same work finished in four minutes. In exchange, about one request in five ran out of steps and went to a person.
Mia asked about that one-in-five case before anything else. Saying "I couldn't finish this" and handing it over is a completely different experience from confidently producing a wrong answer, so the two failures needed different handling. They added one more check before any answer goes out: does it cite a source document.
What people get wrong
The most common misreading is that an agent takes people out of the loop. Demo videos make it look that way — one line of goal, ten steps, a result. In practice the work moves rather than disappears. Someone has to build the tools and tune their descriptions, decide where automation stops and a person takes over, and handle the requests that fail. Leave that shifted work out of the estimate and about two months in, somebody says they're busier than before.
The second is that the loop makes the model smarter. Several steps look like reasoning. But the same model makes every one of those calls, and the only thing that changed is that it now sees its own output and can act on it. Miss that and you start assigning judgments the model can't make, wrapped in a loop that amplifies each wrong one across several steps. An agent gets work done repeatedly that already works once. It doesn't make unworkable things work.
Easily confused with
| Term | What it is | How it differs |
|---|---|---|
| Large language model | The model that produces text | Material versus assembly. An agent is that model plus tools plus a loop, and doesn't exist without it |
| MCP | An open standard for connecting tools to a model | A standard, not a setup. It settles how a tool plugs in, not how many steps get taken with it |
Where to go next
- AI Engineering
see which branch this sits in and what stands beside it
- Prompt engineering
writing the instruction the model reads on every step
- Chatbot
the first product where agents showed up in the wild
Last updated 2026-09-16