Deep dive into the single agent pattern — the simplest agentic architecture where one LLM instance with registered tools handles the entire workflow.
The Single Agent Pattern — Deep Dive · 5 minsTranscript9 entries
Instructor:Your first agent should be one agent, not five. Most teams start way too complex when a single agent with a few tools does the job in a tenth of the code. In this session, you'll see what a single agent actually does. Where does it shine, and what are the signals that you should look for to decide when to move on to a better and more complex pattern. Let's understand using a very simple example. A user asks for a trip plan. No routing layer, no orchestrator, no pipeline. Just one agent that owns the whole thing.
Instructor:The trip plan agent reads the request, picks the tools to call, and the LLM controls the path. Not your code, because it's not deterministic. That's what makes it a true single agent. The agent calls search_attractions first this time, but here's the key: What about next time? It might call weather first, or it may call restaurants. The model decides, and that decision can change based on inputs or from run to run under different circumstances. Now it searches for restaurants. You didn't tell it to do this second.
Instructor:It just decided, and that's the point for flexibility. It's a straightforward task, where data gives you context that reshapes your whole plan. For a trip plan like this, the one agent is all you need. It can ship fast, iterate fast. The agent combines everything into the one plan. Minimal wiring, fast iteration, and that's the payoff you are after. But here is the cost. If the task gets more complex, you slowly start losing control over the order and execution.
Instructor:That means the reliability starts dropping. So why go with this architecture? Because it's efficient. Five to ten lines of config, LLM plus tools. Whatever the request you throw at it, not many code changes are required. If you want to add a new capability, just register the tool. No pipeline to restructure. For a straightforward task, this is genuinely all you need. So let's understand in practical terms how does it work. And after that we'll see the same stuff. And the server is already running.
Instructor:So we've got a server, we've got a client, and we're ready to run the whole example. And the code is tagged in GitHub, and the link is available in the description. The server is already running, so we're just going to run the client. And we'll see the print here in the client. So let's discover the agent and watch what it does. It will go for two queries, and it is connecting using a local Ollama. So we have our response, and you can see it's pretty much doing different tool calls
Instructor:to meet our attraction needs for it, and it was just using Ollama for the LLM purposes. So let's go back to our presentation there. Now here is where it breaks: your instructions become too complex in terms of tokens, in terms of reasoning for the LLM to focus, and it starts conflicting with the guidelines that you provide. So in that case, you need to look for a more complex agent pattern, which can break the reasoning apart and allow the LLM to excel at its best ability.
Instructor:And at that time you might want to move from this simple method to a little bit more complex one, which can handle the complexity of the different tasks. The other thing that I would look for is input consistency. So when you provide the same input for a couple of times, and you see the tool calling, you see the tool-calling sequence and the unreliable order of execution becoming inconsistent, then I think it's a very good time to understand that we might need a more complex pattern to handle the task.
Instructor:The third one which I look for is the same thing in a slightly different way. When it starts to skip, when it starts repeating the same errors again and again by skipping multiple steps, and letting the error compound. And that's when you say yes, it is time to go for a pattern upgrade. And this is where you then decide which next pattern might be the best use case for yourself. So that's the single pattern. It's very simple. One agent, multiple tools, model calling the shots, and it's the right default.
Instructor:To start with agentic AI, this is where you always should start, in my opinion. Until you find a reason that you need a more complex solution. So in next videos we will cover other patterns. Six or seven patterns we are covering in this series. So please make sure you look for the playlist where you can find all the recordings. And I'll see you in the next one.
Learning Objectives5
Define the single agent pattern and explain how it differs from multi-agent architectures
Identify when a single agent is the correct architectural choice versus over-engineering
Explain how tool selection and execution order emerge from the LLM's reasoning
Recognize the failure modes: prompt bloat, nondeterministic execution, and weak multi-step control
Evaluate the trade-offs of flexibility versus reliability in production deployments
Setup Instructions
0/3
Clone the repository
Clone the course repository to your local machine to follow along with the code examples.
bash
git clone https://github.com/nilayparikh/tuts-agentic-ai-examples/tree/main/agents/mono/agent-design-patterns-1/01-single-agent
cd $(basename https://github.com/nilayparikh/tuts-agentic-ai-examples/tree/main/agents/mono/agent-design-patterns-1/01-single-agent)
Create a virtual environment
Create an isolated Python environment for the project dependencies.
bash
python -m venv .venv
source .venv/bin/activate # or .venv\Scripts\activate on Windows
Install dependencies
Install all required packages from the requirements file.
How does a single agent decide which tool to call?
The LLM uses the tool names, descriptions (from docstrings or description fields), and parameter schemas together with its instruction prompt to decide which tool to call. This decision is part of the model's reasoning — there is no explicit routing code.
Q
Is a single agent the same as a chatbot?
No. A chatbot generates text from conversation history. A single agent can also invoke tools — search APIs, databases, calculators, file operations — and use tool results in its reasoning. The tool-calling capability is what makes it an agent rather than a chatbot.
Q
When should I NOT use a single agent?
When execution order matters (use sequential), when independent subtasks should run concurrently for speed (use parallel), when the instruction prompt has grown too large to be reliable, or when failures need to be traceable to a specific pipeline stage.
