Agent Architecture: Core Agent Components
In this lesson6 sections
Core components of an agent
Separate the model, tools, and instructions in an LLM-based agent. Learn how to choose each component, define its responsibilities, and trace their interaction through a scheduling example.
An agent application can be decomposed into components even when the model’s internal computation is difficult to interpret. Three useful components to identify are:
The model, which interprets inputs and proposes responses or actions.
The tools, which expose operations the application can execute.
The instructions, which specify the task and guide the model’s behavior.
This separation helps diagnose failures. An unsupported answer, an incorrect API result, and an ambiguous instruction need different fixes. We will examine each component, then connect them through a complete request.
By the end of this lesson, you will be able to:
Explain model selection factors.
Describe how tools enable agent action.
Recognize the role of instructions in agent behavior.
Understand component interaction within an agent system.
The model: proposing the next step
Given instructions and the current task state, the model proposes a response, plan, or tool call. The application determines what information the model receives and what happens to its output. A proposed action is therefore one decision in the workflow, not proof that the action has occurred.
Reflection or self-critique asks a model to review a plan, response, or observed result and suggest a revision. It may catch errors, but it can also repeat or introduce them. A useful reflection loop includes a criterion that can be checked, such as a failing test or a missing requirement.
This course uses LLMs for action selection and language processing. Their potential contributions include:
Interpreting language: Handle varied descriptions of a task.
Decomposition: Propose smaller steps from a larger goal.
Task transfer: Attempt a new task from instructions or examples without a weight update.
Each contribution needs evaluation. Fluency or a plausible plan does not establish that the model has chosen a valid action.
For example, when you give an agent the prompt:
“Book me the earliest flight from Seattle to New York tomorrow morning and notify my assistant.”
The request contains booking and notification goals. A plan also needs to resolve constraints such as airports, dates, time zones, budget, and the intended recipient. A booking tool may return several choices or report that a fare is no longer available. The agent should use those observations to decide its next step.
Select a model using representative requests and explicit quality requirements. The relevant measurements include:
Task performance: Evaluate extraction, summarization, planning, and tool-argument accuracy separately when the task needs them. Mistral, Gemma, GPT, and Claude are examples of model families, not a permanent ranking of small or capable models.
Latency: Measure the whole request, including repeated model calls, tool execution, and queueing.
Cost: Estimate cost per completed task, including failed attempts and retries. Routing routine steps to a smaller model may help if routing errors and integration overhead are acceptable.
Context: Check whether the input, relevant history, and planned output fit, then test whether the model uses the necessary information. Claude 3 Sonnet and Gemini 1.5 are historical long-context examples; advertised capacity alone does not establish effective recall.
Record the model version and settings alongside the evaluation. A different model may require different prompts, supported tool schemas, or output handling, so changing a model is a system change to test.
Tools: interacting with the environment
A tool exposes an operation to the agent application. It may retrieve information, perform a calculation, or change an external system. The model can request the operation, but application code validates the request, executes it, and returns an observation.
Tools come in many forms, such as:
APIs for fetching weather, sending emails, or creating calendar events.
Web search for retrieving the latest information.
Code execution environments for running logic or calculations.
Databases for structured data storage and lookup.
Device interfaces or robotic controls for physical world interactions.
Let’s say we ask our agent:
“Check tomorrow’s weather and message me if it looks rainy.”
To complete this, the agent may:
Resolve the location and date, then call the weather service.
Interpret the returned forecast under a stated condition for “rainy.”
Send an alert through the authorized messaging channel if that condition is met.
Distinguish an accepted message from a failed or uncertain delivery.
Writing “I sent an alert” is not evidence of delivery. The application needs the messaging service’s result and an appropriate completion check. Tool interfaces should make success, failure, and missing information distinguishable.
Instructions: defining the task and procedure
Instructions describe what the model should do and how it should respond. They are inputs to the model, rather than a separate executor. Clear instructions can specify priorities, format, and escalation criteria, but access controls and permission checks require enforcement in the application.
Instructions come in many forms, depending on how the agent is implemented. These may include:
A natural language prompt that sets the task.
A system message that defines the agent’s role and personality.
A set of examples that demonstrate how to handle different scenarios.
Constraints, such as ethical boundaries or formatting rules.
Task definitions, such as “summarize,” “extract entities,” or “use tool A if X is true.”
Designing and testing these inputs is prompt engineering. Treat prompt changes as changes to system behavior and compare them on the same evaluation cases.
For example, when we prompt a customer service agent with:
“You are a helpful support assistant. Always respond politely, and escalate issues if the user sounds frustrated.”
This instruction establishes a response policy rather than a particular customer’s task. “Sounds frustrated” is also open to interpretation. If escalation matters, define examples and measurable criteria, and check whether different wording or languages produce inconsistent decisions.
Instructions can make the desired behavior more explicit:
Response requirements: Specify audience, tone, content, and format so a reviewer can assess the answer.
Task procedure: Describe which information to gather and when a tool is appropriate.
Behavioral limits: State exclusions and escalation rules, while enforcing sensitive permissions through code outside the model.
A prompt can leave room for language generation and task-dependent planning while the runtime retains exact rules for access, validation, and execution. Those responsibilities complement one another.
How the components work together
To trace a request, follow the information exchanged among the components:
A basic interaction has three stages:
Assemble context: Supply the task, instructions, and relevant observations.
Request a decision: The model proposes an answer or tool call.
Execute and observe: The runtime validates and executes a permitted call, then makes the result available to the next decision.
The loop ends when the task’s completion condition is met or another stopping condition applies. Examples include a missing permission, an unrecoverable dependency error, or an exhausted step budget. The application should report that state accurately.
Why separate components?
Defined interfaces make it easier to change and test one responsibility without guessing how the whole system works.
Model changes: Compare a new model against the same task and interface requirements.
Tool changes: Add or replace an operation while checking its inputs, permissions, and result format.
Instruction changes: Evaluate whether a new prompt improves the intended behavior or introduces regressions.
Diagnosis: Inspect the request and result at each boundary to locate a failure.
Failure handling: Add timeouts and recovery rules around components whose failures would otherwise interrupt the task. Modularity alone does not provide isolation.
These boundaries also support later patterns such as chaining, routing, and multiple cooperating agents. Each pattern still needs a clear owner for task state and a way to assess the final result.
Let’s walk through a familiar task: scheduling a meeting.
We tell our agent,
“Set up a meeting with Sarah next week to discuss the roadmap.”
For this hypothetical meeting request, trace both the action and the evidence needed to confirm it:
Interpret the request: The model identifies the meeting purpose and checks whether the intended Sarah, duration, date range, and time zone are known. Instructions define when to ask for missing details.
Check availability: Calendar tools return the relevant participants’ availability within the application’s access permissions. The result may omit calendars the caller cannot inspect.
Create the invitation: Choose a suitable slot and use the calendar service to create the event within the authorized workflow. Preserve the returned event ID or error.
Report the current state: Confirm that the event was created if the service verifies it. Invitee acceptance is a later, separate state; do not claim everyone has accepted merely because the invitation was sent.
The model helps interpret and compose; tools provide observations and perform operations; instructions define the intended procedure. The runtime connects those roles and checks that the reported outcome matches the observed state.
Quiz
Knowledge check
Knowledge check
1 question · source answers hidden
Tracing the responsibility for a result
For any agent request, identify the model decision, the tool contract, and the instruction that guided it. Then identify the application check that validates execution. The next lesson adds memory and examines how observations from earlier steps affect later decisions.