What is an agent? The definition can be pretty simple: it’s just an LLM that runs within an agentic loop.
To make this definition more concrete, an agent-system has a few high-level components:
1. The LLM backbone. 2. Instructions. 3. Tools. 4. The environment.
Given an initial instruction / specification, these components run in an agentic loop where the LLM generates output, executes tool calls, ingests feedback from the environment, and repeats.
At each step, termination conditions are checked to see if the loop should continue. For example, we can define a maximum number of steps, run tests to determine if the problem is solved, or have the LLM output a termination token. Together, all of these components form an agent harness, which controls orchestration / integration details of the LLM.
(1) LLM backbone. This is just a standard LLM that has been trained to operate in an agentic context. Specifically, the LLM must be able to work well within the provided harness, which requires advanced instruction following, tool calling, and reasoning capabilities. Although any LLM can be used as an agent backbone, we often benefit from using a reasoning model.
(2) Instructions provide the information necessary to solve a problem to the agent, as well as context that helps the agent to approach a problem correctly. Examples of information to put in the instructions include relevant domain info (e.g., from guidelines or policy documents) or how to solve the problem (e.g., break into smaller parts). We want instructions to be detailed enough to reliably guide agent behavior but not so detailed that they become brittle / hard to maintain.
(3) Tools. Agents use tools (e.g., APIs, CLIs, or MCP servers) to interact with the external environment. Tool calls can be represented directly in the LLM’s token stream by creating a set of special tool calling token; e.g., Qwen-3 uses the following tags:
- <tools> … </tools> for tool definition / specification - <tool_call> {params} </tool_call> for tool calls. - <tool_response> … </tool_response> for tool responses / observations.
(4) Environment. Tools mediate an agent’s access to the environment. The environment is stateful, and tool calls may result in environment state changes. Environment dynamics are encoded in tool calling logic–arbitrary environmental rules can be created via tool definitions.
Additional details. Agent harnesses are a rapidly evolving area of research—new ideas and components are introduced every day. Additional harness components not covered above include:
1. Context management controls how information is presented to the agent. For example, long-running tasks may use compaction to summarize prior steps or truncate feedback from the environment (e.g., error messages) to avoid overloading the LLM with too much context; see above. 2. Memory can allow the agent to persist useful context within a long-running task or even across different sessions and tasks. Conceptually, this memory system becomes another aspect of the environment—it is stateful and can be accessed via tool calls by the agent.
