In Part 1, we discussed why students and working professionals should understand agentic systems, and why learning one framework is not the real career skill.
Now we move from why to how.
A first agent can be surprisingly easy to build.
Give a model a goal, connect one or two tools, and let it decide when to use them.
The harder question comes next:
How do you turn that working demo into a system you can actually trust?
That is where agentic engineering begins.
Start with one useful problem
Imagine we want to build a research assistant.
The user asks:
What changed in AI security this week? Find reliable sources and prepare a short cited summary.
A simple version might look like this:
Question → AI model → search tool → sources → answer
That is already more than a normal chatbot because the model can decide when it needs outside information and use a tool to obtain it.
For a first project, that is enough.
Do not start by creating a researcher agent, reviewer agent, citation agent, writing agent and manager agent.
First prove that one agent can solve one useful problem well.
This principle matters because every extra agent, tool and workflow adds more places for something to go wrong.
Step 1: Give the agent tools
Without tools, a model can mainly reason over the information already available to it.
Tools allow it to act.
Our research assistant might have:
- a web search tool
- a page-reading tool
- a function that stores useful sources
The basic loop becomes:
Understand the goal
→ decide what information is missing
→ choose a tool
→ use it
→ observe the result
→ decide what to do next
This simple loop is at the centre of many agentic systems.
But tool design matters.
A tool should have a clear purpose, predictable inputs and understandable results.
If an agent has 50 vaguely named tools, deciding which one to use becomes harder.
A smaller set of well-designed tools is often better than giving an agent access to everything.
Anthropic’s current engineering guidance makes this point directly: tool quality and clear tool boundaries can materially affect agent performance.
Step 2: Add state only when the system needs it
Suppose our research assistant searches five sources.
It now needs to remember:
- what it has already searched
- which sources it accepted
- which claims still need evidence
- what stage of the task it has reached
That is state.
State answers:
What is happening in this particular task right now?
Memory is related, but different.
Memory might preserve useful information across tasks, such as a user’s preferred sources or recurring research preferences.
For beginners, keeping this distinction simple is enough:
State = what this task needs to continue.
Memory = information useful beyond this task.
Do not add permanent memory simply because an agent framework supports it.
Store information because the system actually needs it.
Step 3: Decide what the AI should control
This is one of the most important design decisions.
Some processes are predictable.
For example:
search → extract sources → validate citations → write summary
If those stages should always happen in that order, a normal workflow may be better than allowing the model to invent the process every time.
Other problems are less predictable.
A research agent may discover that a source contradicts another source and decide that it needs another search.
That is where model-driven decision-making becomes useful.
A practical system often combines both.
Workflow controls what must happen.
Agent decides what requires judgment.
This distinction helps avoid unnecessary autonomy.
Microsoft’s current guidance makes a similar recommendation: use simpler patterns when they work, and use workflows where explicit execution order and checkpoints matter.
Step 4: Make failure part of the design
A demo usually assumes everything works.
Production does not.
The search API may fail.
A website may be unavailable.
A tool may return incomplete information.
The model may choose the wrong tool.
A long-running task may stop halfway through.
A reliable agentic system needs answers to questions such as:
- Should this step retry?
- How many times?
- Can the task continue without this tool?
- Should it return to the last successful checkpoint?
- When should it stop?
- When should it ask a human?
For our research assistant, a failed source lookup should not necessarily destroy the entire task.
The system might record the failure, try another source and continue.
But if it cannot verify a critical claim, it should not quietly invent one.
That is the difference between recovering from failure and hiding failure.
Step 5: Evaluate the result
This is where many agent tutorials end too early.
The agent produced an answer.
But was it good?
For our research assistant, we could evaluate:
- Were the sources relevant?
- Were the claims supported?
- Were citations attached to the correct claims?
- Did it use authoritative sources where available?
- Did it invent anything?
- Did it finish within an acceptable cost and time?
That is an evaluation, or eval.
Traditional software often gives us a simple answer:
test passed / test failed
Agentic systems are harder because some outputs are not perfectly deterministic.
That does not mean they cannot be tested.
It means we need to define what a good outcome looks like.
Anthropic’s current guidance on agent evaluations makes this point clearly: because agents act across several steps, modify state and respond to intermediate results, evaluation needs to examine the behaviour of the system rather than only its final sentence.
For students especially, learning evaluation early is more useful than adding another framework to a résumé.
Step 6: Make the agent observable
If the final answer is wrong, you need to know why.
Did the model misunderstand the question?
Did it choose a bad source?
Did a tool fail?
Did it receive the right information and make the wrong decision?
That requires observability.
A useful trace might show:
goal
→ model decision
→ tool selected
→ tool result
→ next decision
→ final output
AWS’s current guidance for agentic systems goes further, treating tool invocations, workflow execution, state and agent behaviour as important parts of production observability.
For learning purposes, remember the simple rule:
If an agent can take an action, you should be able to reconstruct what happened.
Without that, debugging becomes guesswork.
Step 7: Decide where humans belong
Human involvement does not mean the agent failed.
Sometimes human approval is part of the correct design.
Our research assistant may be allowed to search and summarize automatically.
But imagine a different agent that can:
- delete cloud resources
- transfer money
- send an external email
- approve a refund
- change production configuration
Those actions have consequences.
A good design may allow the agent to prepare the action but pause before execution.
Agent proposes → human approves → system executes
The important question is not:
Can the AI do this?
It is:
Should the AI be allowed to do this without another decision point?
Agentic engineering is partly about deciding where autonomy should stop. For one worked example of drawing that line, see our Perspective on why autonomy is not the same as trust.
Step 8: Add security before adding more autonomy
Every tool increases capability.
It can also increase risk.
If an agent can access a database, cloud account, file system or external API, ask:
- What identity is it using?
- What can that identity access?
- Does it have more permission than this task needs?
- Are credentials protected?
- Can untrusted content influence its actions?
- Are high-impact operations restricted?
Do not give an agent broad authority because configuring narrow access takes more effort.
The principle is the same as traditional system security:
Give the system only the access required for the job.
Agentic systems make this more important because the model itself may decide which permitted action to take next.
TechiesJournal has separate coverage for agent identity and security, so we will not repeat that subject here. But anyone building real agents needs to treat security as part of the architecture, not a later feature.
Where does MCP fit?
As your agent begins using more external systems, you will encounter Model Context Protocol, or MCP. Our guide to how MCP, A2A and WebMCP connect agents covers the protocol itself.
MCP provides a standard way for AI applications to discover and interact with tools and external resources.
That can reduce custom integration work.
But MCP does not replace the fundamentals we have discussed.
You still need to think about:
- which tools should exist
- what the agent can access
- authentication
- permissions
- tool quality
- error handling
- evaluation
Learn MCP after you understand basic tool calling.
Otherwise you may understand the protocol without understanding the system you are trying to build.
When do you need multiple agents?
Later than many tutorials suggest.
Suppose our research assistant works well but we discover that source verification requires a genuinely different process.
We might eventually separate responsibilities:
Research agent → evidence reviewer → writer
That can be useful.
But multi-agent design also adds:
- more model calls
- more state
- more coordination
- more latency
- more cost
- more failure paths
Current Anthropic and Microsoft guidance both make essentially the same architectural point: use the simplest pattern that solves the problem, and add orchestration or multiple agents when the task actually requires it.
So before creating another agent, ask:
What problem does this additional agent solve that one agent or a normal workflow cannot?
If there is no clear answer, do not add it.
From agent to agentic system
Our original research assistant was simple:
Question → Model → Search → Answer
A more dependable version now looks different:
Goal
↓
Agent
↓
Tools
↓
State
↓
Evidence
↓
Evaluation
↓
Checkpoint / human decision when needed
↓
Result
Around all of that sit:
security + observability + failure recovery
Accessible text alternative for this figure
Three stages of growth. A simple agent is a model with a tool. A useful application is a model with tools and state. A reliable system keeps the model, tools and state and adds evaluation, observability, recovery, security and human control. Added elements are marked with a plus sign and a warm fill, so the progression does not depend on colour alone.
That is the important transition.
The model remains important.
But the model is no longer the whole application.
This is why building agentic systems is increasingly becoming a software-engineering discipline rather than simply a prompting skill.
What should you build next?
If you are learning, do not try to implement everything in this article at once.
Build in layers.
First: one agent and one useful tool.
Then: add state.
Then: define what a successful result looks like.
Then: add tracing and failure handling.
Then: add human approval if the agent can take consequential actions.
Only after that should you explore complex orchestration, MCP-heavy architectures or multiple agents.
The best learning project is not the one with the most agents.
It is the one where you can explain:
what the agent is trying to achieve,
what it can do,
what can go wrong,
how you detect failure,
and why the final result should be trusted.
That is the difference between building an agent demo and building an agentic system.
Continue the Building Agentic Systems Series
Part 1: Previous. Building Agentic Systems: What Students and Working Professionals Should Learn Now. Start here if you want to decide whether agentic systems deserve your learning time and how deeply your role needs the skill.
Part 2: You are here. Building Agentic Systems: From Your First Agent to a Reliable System. Understand the technical journey from a simple tool-using agent to a system with state, evaluation, observability, security and recovery.
Part 3: Next. Learning Agentic AI: Free Courses, Hands-On Labs and Certifications. We will compare current learning resources from AWS, Microsoft, Google, OpenAI, Anthropic and others, and separate free training, course certificates, hands-on credentials and professional certifications.
Sources and Further Reading
Source review: 2 October 2026.
- Anthropic — Building Effective Agents. Useful for understanding the difference between workflows and agents, why simpler architectures should come first, and when additional autonomy is justified.
- Anthropic — Writing Effective Tools for Agents. Explains why tool quality, clear interfaces and evaluation matter to agent performance.
- Anthropic — Demystifying Evals for AI Agents. A practical explanation of why multi-step agent behaviour needs systematic evaluation.
- Microsoft — Agent Framework. Current documentation that progresses from a first agent and tools through state, memory, workflows, human involvement, checkpoints and hosting.
- AWS — Agentic AI Lens. Useful production guidance covering observability, state, resilience, security and operational behaviour in agentic systems.
- OpenAI — Agents SDK documentation. Current developer resources covering tools, state, orchestration, guardrails, human review, tracing and evaluations.