TL;DR

1. The model matters, but tools matter at least as much. Weak tool descriptions are one of the easiest agent failures to diagnose, and one of the most common.
2. Design the tools before the agent. If you cannot answer "what can this agent do that a general LLM cannot on its own?", you do not have an agent yet.
3. Ship a small, focused loop with 2-3 well-described tools and a hard iteration cap. Watch traces. Iterate.

In Part 1 I laid out the four levels of AI agents I keep seeing in production, and argued that most shipped "AI agents" are stuck on the lower rungs. This post is about how to build one that is not.

One assumption underneath everything below:

Tools are the center of an agent. Not the system prompt.

Most tutorials start with "let's write the system prompt." Wrong starting point. Start with tools.

Start With Tool Design

A weak tool description looks like this:

search_documents:
  description: "Search documents."

The model has no idea when to use it, what to put in query, or what the output means. So it guesses. Badly.

A good description looks closer to this:

search_documents:
  description: "|"
    Use this tool when the user's question requires evidence from
    internal documents, policies, or technical references.

    Do NOT pass the full user question as the query. Extract the
    core concepts and keywords. If the first result set is weak,
    rewrite the query and search again before answering.

    Cite the retrieved documents as evidence in your final answer.
  parameters:
    query:
      type: string
      description: "2-6 keywords, not a full sentence."

Same tool. Completely different agent behavior.

The good description does three jobs the bad one skips:

1. When to use it — a trigger condition, not just a name.
2. How to call it — concrete shape of arguments, with anti-patterns called out.
3. What to do with the result — how the output feeds back into the final answer.

Claude's Skills system is worth studying for the shape, not the brand. A Skill packages task-specific instructions, files, scripts, and example workflows behind a short trigger description. The heavy content only loads when the agent decides the Skill is relevant. The pattern has a name: progressive disclosure. Reachable in any framework that lets you gate long instructions behind a short surface.

Two tips that have saved me more time than anything else in this area.

1. When you're stuck, let skill-creator rewrite your prompt.

Anthropic ships an official Skill called skill-creator whose job is to make and improve other Skills. Its SKILL.md is, almost accidentally, the best prompt-design tutorial I have read. The patterns it pushes are exactly the ones that hold up under load: explain why a rule matters instead of writing rigid ALWAYS/NEVER directives; design for the smart model you actually have, not the rote one you imagine; generalize past your test cases rather than overfit to them; cut anything not pulling its weight.

What I do now whenever I have to write a non-trivial agent system prompt: write a first draft myself, then ask Claude to rewrite it "following the skill-creator SKILL.md guidelines." The result has beaten my draft every single time. Sometimes embarrassingly so.

2. Read how Claude Code itself is built.

Anthropic's Claude Code documentation walks through how their own coding agent is wired — system prompt shape, tool surfaces, subagent boundaries, context management, the whole stack. If you have only ever read agent tutorials, reading the docs for a real production Level 4 agent is the cheapest level-up I know.

Practical translation: do not dump every possible instruction into the system prompt. Expose short names and descriptions. Load the deep stuff on demand.

A scar from one of my own v1s. We added six tools, expecting the agent to compose them in interesting ways. It did not. It picked the wrong one, called it with the user's entire question as the query, and kept looping. The tool name was the lie. It promised "search", but the implementation could only handle keywords, and nothing in its description said so. We cut from six tools to two, rewrote the descriptions, and the loop stopped.

The bug was not reasoning. The bug was that the tool name lied.

Design the Tools Before the Agent

If you only remember one thing from this post: design tools first, agent second.

Before writing a single line, ask:

• What can this agent do that GPT, Claude, or Gemini cannot do on their own?
• What external data does it need access to?
• What real actions should it be allowed to take?
• What workflow is it automating end-to-end?

If the honest answer is "it talks nicely," the user has no reason to use it. General-purpose LLMs already talk nicely. The differentiation comes from tools that connect to your system:

• Query the company database
• Modify project code
• Search internal policy documents
• Look up a customer's order history
• Create a Jira ticket
• Summarize a Slack thread into action items
• Run a domain-specific validation script

Tools are how an agent becomes useful in domains where a general LLM cannot act. They are also the surface where security, permissions, and auditing actually live — which is another reason "we'll figure out tools later" is the wrong order.

A Reasonable Starting Architecture

If I were building a v1 today:

User
  ↓
Root agent (system prompt + context manager)
  ↓
Planner / agent loop
  ↓
Tool selector → Tool execution → Observation
  ↓
(loop until done or iteration cap)
  ↓
Final response

A good v1 has:

• A focused system prompt — describes the agent's job, not its biography.
• Conversation context with a sliding window — keep head + tail, compress the middle.
• 2 or 3 well-described tools, not 20. Each one earns its slot.
• An agent loop with a hard iteration cap. 10 is a good default; tune from traces.
• Tool results fed back into the next model call, with clear delimiters.
• Trace logging from day one. You will need it.

That's it. Ship that, watch traces, then improve.

The traps I see most often in v1s:

• Too many tools. The model wastes turns choosing between near-duplicates. Merge or delete.
• No iteration cap. One bad tool call and the agent burns your budget in a loop.
• Tool errors swallowed silently. The model retries blindly because it never saw the error. Always surface error messages back into the loop.
• System prompt growing every time something breaks. Each new instruction makes the previous ones less salient. Fix the tool description instead.

What "Done" Looks Like

You'll know you've built a Level 4 agent when:

• A user describes a goal, not a step. ("Cancel the order I placed yesterday if it hasn't shipped.")
• The agent chooses which tools to call, in what order, without you hard-coding the path.
• It recovers from at least one bad tool result without giving up.
• The trace shows decisions, not a script. Goals broken into steps. A look at the actual result after each tool call. An explicit "this is done." Not a fixed sequence in JSON costume.

If you cannot yet point at a trace that satisfies all four, keep going. That is the gap worth closing.

If you missed it, Part 1 covers the 4-level taxonomy and why most "AI agents" you encounter in real products are stuck at Level 1 or 2.

Tell me what your current v1 looks like — especially the tool list. Most of the interesting design happens there, and most of the bugs do too.