This article focuses on LLM-based agents, not every kind of agent in AI. The word agent has several meanings, and people building LLM applications draw the line between workflows and agents differently. A digital employee, a clever chatbot or a prompt with extra steps is not a useful engineering definition.
Here is a practical working definition: an LLM-based agent is an application that gives a model a goal, relevant context and limited ways to act, then lets it select a next step within defined boundaries. This is an editorial synthesis, not a universal standard or a promise of reliable autonomy.
Start with the application
A large language model can generate a reply or propose a tool call. A proposal does not, by itself, grant access to your files or authority to change a customer record. In the application-defined function-calling pattern used here, the application supplies the available functions, validates and executes a proposed call, then returns the result to the model. Platforms including OpenAI also offer built-in tools with different execution arrangements; application-side execution is not a rule for every tool.
The application supplies the goal, instructions and context. In this pattern it defines the available functions, validates proposed actions and decides what happens when a function fails, a request is forbidden or human judgement is required. The model is an important component of the system, but not the entire system.
One loop, several exits
The basic loop is: give the model a goal and current observation; receive a proposed next step; validate and perform any allowed action; return its result; then continue, finish or ask a person. The number of steps need not be fixed in advance, but the boundaries and exits should be.
The diagram shows one agent loop in the application-defined pattern, with an explicit way out. Validation can check parameters, formats, permissions, resource limits and business rules. An agent need not run indefinitely: it can finish, reach an iteration limit or pause for a human. Anthropic describes environmental feedback and stopping conditions; its distinction between workflows and agents turns on who chooses the next step.
The parts worth naming
- Model: proposes text or a next action based on the available context. Fluency does not establish that an answer is correct.
- Goal and instructions: describe the job and the assistant's role. They do not override the system's permissions.
- Tools: narrowly defined ways to retrieve information or request actions. In our function-calling example, a proposed call is a request that the application handles, not an action performed by the model.
- Context and memory: the current question, selected documentation and previous results are context. Persisting information across sessions is optional, not a condition for calling something an agent.
- Permissions and boundaries: specify what the system can read or change, and what it must never do. Read access to a document is not permission to modify an account.
- Stopping, observability and review: specify when to stop or escalate, how many steps or resources the task may use, what actions are recorded and which actions require a person's approval.
These are design responsibilities, not a shopping list of products. A small, well-bounded agent may have one read-only tool and no long-term memory. Attaching several tools to a model without a clear goal or execution rules does not make a trustworthy system. Anthropic advises starting with the simplest solution that meets the need; an agent is not the default answer to every problem.
A fictional support assistant
Imagine a customer asks, “Does this feature work with the latest version?” Our fictional assistant is allowed to search a versioned help site and draft replies, but cannot send them or edit the customer's account. It retrieves the relevant help page and compares its scope with the question. If the page covers the version, it prepares a reply for review and links the section it used. If “latest” is ambiguous, it asks which version the customer means. If the documentation is contradictory or an account change would be needed, it stops and escalates to support staff.
This is an illustration, not a deployed system or a performance result. The interesting behaviour is the bounded choice among lookup, clarification, draft and escalation. Nothing here requires another agent, a vector database or a promise of unattended operation. The read-only tool and the human handoff are architectural choices, not natural properties of the model.
What it is not
A prompt is input to a model; it is not an application loop. An LLM alone can answer a question, but it does not by itself provide an application's permissions or escalation policy. A chatbot describes an interface: some chatbots expose agents and others do not. A deterministic workflow follows paths chosen in advance by code; in the narrower distinction used here, the model is not directing the next step, although a real system can mix fixed stages and agent-like choices. Simple automation may execute a script without any LLM at all.
Those categories are tools for explaining control flow, not a scorecard. If a fixed workflow solves the task more reliably and cheaply, there is no engineering prize for calling it an agent.
Boundaries are the point
A documentation page is useful context, but it is not an instruction source. Retrieved text may contain an attempt to redirect the model: OWASP calls this indirect prompt injection. Separating external content from instructions and giving the application only the privileges it needs reduces the scope of harm; it does not eliminate the possibility of mistakes.
For the support example, the boundaries are concrete: which documentation can be read, which personal data must not enter the model context, which actions are forbidden, how many lookups are allowed, what is recorded for review and when a human must decide. A draft reply is not a sent reply. A request to change a record should be rejected or explicitly reviewed, not silently executed because the model sounded confident. OWASP recommends least privilege and human approval for high-risk actions; the exact policy belongs to the system's operators.
The useful takeaway
An agent does not replace architecture. It moves part of the choice of the next action into a loop; execution and oversight must still be assigned explicitly, whether a tool runs in your application or on a provider's platform. Start by asking what the agent may observe, what it may propose, who may execute it, and how a person can stop or correct it.
References
[1] Anthropic, “Building effective agents”, 19 December 2024. The page notes that its tooling landscape reflects December 2024; the workflow/agent distinction is used here as an architectural framing, not a current tools catalogue.
[2] OpenAI, “Function calling”, developer documentation. Distinguishes application-defined function calls from built-in tools.
[3] OWASP Gen AI Security Project, “LLM01:2025 Prompt Injection”.
