How do I build my own agent?
What an agent actually is, harnesses vs frameworks, tools via MCP, and the context and verification that keep it honest.
The path.
- What an agent actually is In Agentic Engineering: Core Ideas "Agentic coding" is an overloaded term.
- Agent Harnesses & Frameworks Two very different things get called "agent tooling."
- MCP & the Tool/Context Ecosystem Models are only half the story. The other half is the plumbing that gives models hands: how an assistant reaches your files, databases, SaaS tools, and the web.
- Context, Skills & Memory Agents are only as good as what they know when they start, and by default they start knowing nothing about your repo, your conventions, or last week's decisions.
- Verification & Testing for Agents If generation is cheap and verification is the bottleneck, then verification infrastructure is your leverage.
- When one agent isn't enough Once one agent works, the obvious move is to run several. This is where the biggest gains and the biggest self-inflicted wounds both live.
Check yourself.
One question per step. Take it cold to find where to start, or after reading to see what stuck. Nobody's grading you.
Best so far:
Question 1 of 6
-
In the now-settled definition, what makes a system an agent rather than a workflow?
An agent is an LLM running tools in a loop toward a goal, directing its own process; a workflow runs LLMs through predefined code paths. Anthropic's advice is to prefer the simpler workflow until agency demonstrably improves outcomes.
Covered in step 1 · What an agent actually is -
When does an agent framework beat a plain provider SDK plus a loop?
For a single agent with a few tools, an SDK plus a loop is often simpler and more debuggable. Frameworks earn their keep on orchestration you'd otherwise reinvent, like durable state, multi-agent coordination, and human-in-the-loop checkpoints.
Covered in step 2 · Agent Harnesses & Frameworks -
How does MCP relate to the function calling that model APIs already provide?
MCP tools reach the model through the same tool-calling mechanism every frontier API exposes; what MCP standardizes is where the functions come from and how they're described, so one server works across providers and apps.
Covered in step 3 · MCP & the Tool/Context Ecosystem -
Why is "give the agent as much context as possible" bad advice?
The chapter documents "context rot": as tokens in the window increase, the model's ability to accurately recall from context decreases, and failure modes like poisoning, distraction, and clash appear long before you hit the limit.
Covered in step 4 · Context, Skills & Memory -
You wire your test suite into an agent's loop. Why must the tests be protected from the implementer?
Kent Beck reports having trouble stopping agents from deleting tests to make them "pass". The guardrail is also a target, so tests should be owned by the checker role or locked against implementer edits.
Covered in step 5 · Verification & Testing for Agents -
You're splitting a feature across parallel agents. Which work actually parallelizes well?
The cleanest rule in the multi-agent debate is that read actions are inherently more parallelizable than writes: research and review fan out, while merging conflicting writes (and the conflicting assumptions behind them) is the expensive part.
Covered in step 6 · When one agent isn't enough