Agents & tools — A model, in a loop, with tools. That's it.

This is the track I care most about, because it is the one where the industry's marketing is furthest from the engineering. An agent is not a mysterious autonomous intelligence. It is a while loop. Write one by hand and the mystique never comes back — and then build the harness around it, which is where the actual work has moved.

Track 3 of the AI engineering roadmap by K Laxman — about 17 hours across 6 stages.

The agent loop, by hand

You can write an agent without a framework and explain every line of it.

environment · tool schemas · the while loop · context accumulation · approval gates

Interactive explainer on the live page: agent loop — You can write an agent without a framework and explain every line of it.

In short:

  1. An agent is a while loop. Call the model; if it asks for a tool, run it, append the result to the conversation, and call again. Stop when it answers without a tool call.
  2. The context is the agent's memory. Every tool result goes back into the context. The model knows only what the loop has put there so far.
  3. You own the stopping conditions. A step limit, a cost ceiling and approval gates for risky actions belong in your code, not in the prompt.

Build this — Write the loop. No framework.. A while loop, three tools, JSON-schema arguments, one approval gate before anything destructive. This is the keystone exercise of the whole page — do not substitute a framework tutorial for it.

You're done when: You can draw the loop on a whiteboard and point at exactly where a tool result re-enters the context.

Common traps:

Check yourself:

  1. Where exactly does a tool result re-enter the loop? Answer: It is appended to the message history as a tool-result message, and the whole history is sent on the next model call.
  2. When should you NOT build an agent? Answer: When you can write the steps down in advance. Use a fixed pipeline, and keep agents for tasks where the path genuinely depends on what is found along the way.

Put to work in: Jarvis — that loop, in production, running live in your browser · OpsPilot — agentic request triage & remediation

Workflows and graph loops — the five patterns

You can pick the simplest pattern that solves a task, and draw any agent system as a graph of steps with a loop in it.

prompt chaining · routing · parallelization · orchestrator-workers · evaluator-optimizer · state, nodes and edges · conditional edges and cycles · checkpointing

In short:

  1. Five patterns cover most systems. Prompt chaining (fixed steps), routing (classify, then specialise), parallelization (split or vote), orchestrator-workers (a model plans the subtasks) and evaluator-optimizer (generate, critique, revise).
  2. A graph is the loop, drawn. Nodes are steps, edges are control flow, and state is what travels between them. An agent is a graph with a conditional edge pointing back to an earlier node.
  3. Every cycle needs an exit. A loop edge must have a condition that ends it — a passing check, a round limit, a budget. Without one, the graph is an infinite loop with a bill attached.

Build this — One task, two patterns, a number for each. Take a writing or extraction task. Solve it once as a prompt chain and once as an evaluator-optimizer loop (generate → critique → revise, with a round limit). Run both on the same 20 inputs and record quality, latency and cost. Then draw the second one as a graph: which edge is the loop, and what stops it?

You're done when: Given a new task, you can say which pattern fits, why the simpler ones don't, and where the loop's exit condition lives.

Common traps:

Check yourself:

  1. Customer emails go to billing, technical or sales, each with its own prompt. Which pattern is that? Answer: Routing — classify the input, then send it to a specialised prompt or model.
  2. What turns a workflow graph into an agent? Answer: A cycle whose next step the model decides: a conditional edge back to the model node, taken until the model chooses to stop (or a limit stops it).

Put to work in: Research Intelligence Agent — orchestration in practice · OpsPilot — routing and remediation workflows

Tools and MCP — connecting agents to real systems

You can design a tool an LLM actually uses correctly, and expose it over MCP.

tool design · argument validation · MCP architecture · tool servers · when a tool is too broad

In short:

  1. The tool description is a prompt. The model chooses tools and fills arguments from the name, description and schema alone. Write them for a new colleague with no other context.
  2. Narrow tools, typed arguments. One clear job per tool, enums instead of free strings where possible, and validation on every call — the model's arguments are untrusted input.
  3. MCP standardises the plumbing. An MCP server exposes tools and resources once; any MCP-capable client (desktop apps, IDEs, your own agent) can then use them without custom glue.

Build this — Wrap your Track 2 RAG bot as an MCP server. One tool, a real schema, connected to a client you didn't write. The moment someone else's agent can call your thing, tool design stops being theoretical.

You're done when: You can say why a tool named `do_stuff(input: string)` will be called wrongly, and rewrite it so it won't be.

Common traps:

Check yourself:

  1. Why will `do_stuff(input: string)` get called wrongly? Answer: The name and schema tell the model nothing about when to call it or what to pass. Split it into specific tools with typed, described parameters.
  2. What does MCP give you that a function call in your own code doesn't? Answer: Reuse: the same server works across every MCP client, and tools can be added or updated without changing the agent's code.

Put to work in: Intelligent Document Processing — multi-agent system

Harness engineering — the part that isn't the model

You can say what a harness is, name its five pieces, and point at the one your own agent is missing.

guides vs sensors · context assembly · tool orchestration · verification loops · cost envelopes · behavioural evals

Interactive explainer on the live page: harness — You can say what a harness is, name its five pieces, and point at the one your own agent is missing.

In short:

  1. The harness is everything but the model. Context assembly, tool orchestration, verification, limits and logging. It decides what the model sees and what happens to what it produces.
  2. Guides steer, sensors check. Guides (instructions, examples, conventions) shape behaviour before the action; sensors (tests, linters, validators) check the result after it.
  3. Close the loop with verification. Let the agent run the check itself — the test suite, the type checker — and feed failures back. That catches errors no prompt prevents.

The shift this track has been building toward. Prompt engineering was how you got one good answer out of a 4k context window; it stopped scaling the moment a task ran longer than a few hundred lines. What replaced it is not a better prompt — it is everything around the model: what you put in the context, which tools it can reach, what checks its work, what stops it spending your money, and what you can read afterwards when it went wrong. Swapping models moves output quality by ten or fifteen per cent. Changing the harness decides whether the system works at all.

Build this — Put a harness around the loop you already wrote. Take your Track 3 agent and add the five pieces one at a time, measuring after each: a conventions file it always reads, a deterministic check it cannot talk its way past, one verification gate that re-runs its work before the result counts, a per-task token ceiling that kills the run, and a trace you can read afterwards. Keep the model fixed the whole time — the point is to see how far the harness alone moves it.

You're done when: You can point at one failure your harness now catches that the model used to get away with — and say which of the five parts caught it.

Common traps:

Check yourself:

  1. Your coding agent keeps breaking imports. Guide or sensor? Answer: Both, but the sensor matters more: run the build or type check after each edit and feed errors back. A prompt rule alone will be ignored eventually.
  2. Name the five parts of the harness in the explainer above. Answer: Context (what the model sees), tools (what it can do), verify (checks on what it produced), budget (steps and cost it may spend), and trace (a record of every run).

Put to work in: Jarvis — tool allow-lists, call budgets and a visible trace

Multi-agent systems — when one context window isn't enough

You can tell when splitting work across agents pays for itself, and build an orchestrator whose sub-agents don't trip over each other.

orchestrator and sub-agents · parallel context windows · token cost vs quality · task locking · shared state via git or files · outcome-based evaluation

In short:

  1. Sub-agents buy context, not intelligence. Each sub-agent explores in its own clean context window and returns a short summary. The win is breadth and parallelism on tasks too big for one window.
  2. It costs a multiple of the tokens. Anthropic reports multi-agent research using roughly 15× the tokens of a chat. It pays off only when the task is valuable and genuinely splits into independent parts.
  3. Coordination is the hard part. Agents need clear task boundaries, a way to claim work (a lock file, a queue) and shared state they can merge (git, files). Most failures are two agents doing the same thing.

Build this — An orchestrator with three researchers. Build a lead agent that splits a research question into three sub-questions, runs three sub-agents in parallel with separate contexts, and merges their cited summaries. Compare against a single agent on 10 questions: quality (judged against your own rubric), tokens and wall-clock time. Keep the multi-agent version only if the numbers justify the cost.

You're done when: You can quote what your multi-agent version costs in tokens compared with one agent, and what it buys.

Common traps:

Check yourself:

  1. When is a single agent the better choice? Answer: When the subtasks depend on each other, share most of their context, or the task fits in one window. Parallel agents add cost and coordination for no gain there.
  2. Two parallel agents keep fixing the same bug. What do you add? Answer: A way to claim tasks — a lock file or queue entry per task — checked before starting work, plus merging shared state often.

Put to work in: Research Intelligence Agent — agentic research & decision support

Frameworks — deliberately last

You choose a framework because it removes work you understand, not because you're lost.

LangGraph and friends · what they abstract · what they hide

In short:

  1. A framework hides the loop. LangGraph and similar libraries give you state, retries, persistence and graphs of steps. They are the same loop you wrote, with decisions made for you.
  2. Adopt for features, not for learning. Durable state, human-in-the-loop pauses and tracing are real reasons. "I don't know how agents work" is not — that is what the previous stages fixed.
  3. Know the escape hatch. Before committing, find out how to see the exact prompt sent and how to override one step. Debugging something you can't see is the real cost.

Framework material comes last on purpose. Read one only after you have written the loop, the patterns and a harness yourself. You will find you already know what every abstraction is for — and you will notice the ones that are solving a problem you don't have.

You're done when: You can name one thing your chosen framework does that you would rather do yourself, and say why.

Common traps:

Check yourself:

  1. Name one good reason to adopt a framework. Answer: Durable, resumable state for long workflows, or built-in human-approval pauses — features that are genuinely tedious to build and test yourself.
  2. What should you check in your framework before production? Answer: That you can see and log the exact prompt and tool calls for any run, and override any single step without forking the library.

Explore more

GitHub · LinkedIn · Email