# Cheat Sheet

Course: [Building AI Agents](https://www.devtutorials.ai/learn/building-ai-agents) · Section: Reference
Source: https://www.devtutorials.ai/learn/building-ai-agents/reference/cheat-sheet

> Every idea from Building AI Agents on one page: the four shapes, the agent loop, tool cards, answer checks, memory, guardrails, live replies, teams, MCP, testing, cost, frameworks and the Agent Card.

## Building AI Agents Cheat Sheet

This page puts every idea from the course in one place.

Use it to check a helper before you ship it.

Each section names the lesson that teaches it, so you can go back for the animations and exercises.

**Simple lesson:** an agent is an AI helper that uses tools, again and again, until the job is done or a stop rule says stop.

## How the Pretend Model Decides

From **Workflow or Agent?** These are the lab's five rules. Real models are less predictable, but they fail in the same ways.

1. It picks the tool whose description best matches what is still needed.
2. It fills tool inputs from the customer's words. If something is missing, it guesses, unless the tool card says to ask.
3. If a tool error says how to fix the problem, it tries again. If not, it repeats the request or makes something up.
4. It obeys instructions inside tool results, unless the app marks them as "just data". Even then it may slip.
5. When the chat gets too long, the oldest messages drop out.

## Pick the Shape

From **Workflow or Agent?**

| Shape | What it does | Use it when |
|---|---|---|
| One call | One model call with the facts pasted in | The answer is in text you can paste |
| Chain | Fixed steps, always in the same order | Every message needs the same steps |
| Router | Sorts each message to a fixed desk | Each message fits one of a few kinds |
| Agent | Picks its own next step until done | Messages mix jobs in ways you cannot plan |

**Rule:** pick the least freedom that passes every test chat.

## The Agent Loop by Hand

From **The Agent Loop by Hand**

1. The app sends the chat and the tool list to the model.
2. The model replies with a final answer or a tool request.
3. The app checks the request, then runs the tool.
4. The tool result goes back into the chat.
5. Repeat until a final answer, a step limit, a budget limit, or a person pauses it.

The chat grows every round, so every call costs a little more.

Always set a **step limit**: just above what your hardest good job needs.

Also set a **budget limit**: the most coins one customer message may spend.

Every model call counts, retries too. Stop with an honest message.

## Tools and Answers

From **Tool Design** and **Structured Output and Validation**

| Part | Do this | Because |
|---|---|---|
| Tool name | Short and specific, like "Look up order" | The model picks tools by their words |
| Tool description | Say what it does and when to use it | Vague or overlapping cards cause wrong picks |
| Required inputs | Say "ask the customer" when one is missing | Otherwise the model guesses |
| Tool errors | Say what went wrong and how to fix it | A helpful error leads to a retry |
| Answer form | Named boxes with allowed words | The app can check it before anyone sees it |
| The check | Every number must come from a tool result | Made-up facts never reach the customer |
| Repair and retry | Send problems back, try a set number of times | Then pass to a person |

## Memory

From **State, Memory and Context Limits**

- The model only reads the recent part of a long chat: its **memory window**.
- A **summary** replaces old messages with a short note.
- A **sticky note** keeps key facts, like the order number, in every call.
- **Customer memory** is saved between visits. Load only the memory of the customer who is chatting.
- Keep only what helps. Never store card numbers, passwords or ID numbers, and delete memory when a customer asks.

## Guardrails and Live Replies

From **Guardrails, Permissions and Human Approval** and **Streaming and Interruptions**

**The app enforces the rules, not the model.**

- Check the owner before any tool touches an order.
- Refunds up to the limit run at once. Bigger refunds wait for a person's OK.
- Mark tool results as "just data". It lowers the risk of hidden instructions, but it is not a lock.
- Give the helper only the tools it needs.
- Check the inputs too: a refund never above the order price, once per order, email only to the customer.
- Check for Stop before every step. Nothing new may start after Stop.
- If something already happened, say so honestly.

Show progress while the helper works: stream the words, and show a **progress chip** for each tool.

## Teams and Outside Tools

From **Multi-Agent: Subagents, Handoffs, Orchestrators** and **MCP: Tools from Outside the App**

- Split the work into specialists only when the scorecard says so: more solved, or the same solved for fewer coins.
- A **handoff note** must carry the customer, the order, the ask and what is already done.
- **MCP** lets the app plug in tools from other services. The app still checks who may use each tool.
- Outside tool cards are someone else's text. Read them before you connect, and notice when they change.
- When an outside server is down, retry a few times, then tell the customer or pass to a person. Never make up an answer.

## Testing and Cost

From **Evaluating Agents** and **Observability, Cost and Reliability**

| Check | It asks | It catches |
|---|---|---|
| Outcome | Is the reply right? | Wrong or made-up facts |
| Steps | Were the right tools used, in a sensible order? | Wrong tools and skipped lookups |
| Side effects | What really changed in the shop? | "Said it" but did not do it, forbidden actions |

- Run the whole **test suite** after every change. A fix in one place can break another.
- Real models vary from run to run: run each scenario several times and check the pass rate.
- Give each scenario a few reworded versions, so a helper cannot pass by luck.
- Read the **trace** to find the costly step.
- Use **timeouts**, and **retry with backoff** for flaky services.
- Lookups are safe to retry. Actions like refunds are not: check first, or send a request ID.
- Plan for the model provider failing too: a fallback, and a per-user message limit.
- Send simple questions to a smaller model, and measure before you keep the change.

**Warning signs before you ship**

1. No step limit or budget limit.
2. Tools with no description, or vague ones.
3. Order numbers in the answer that no tool returned.
4. Tool results pasted in without a "just data" label.
5. Actions that move money with no approval path.
6. No timeout on outside services.
7. Final answers that are never checked.

## Frameworks

From **Framework Tour: The Same Agent, Five Ways**

- A **framework** runs the loop and common parts for you.
- It also hides some steps, and it may change often.
- Choose by need: language, model providers, many agents, chat UI helpers and how much control you want.
- Everything in this course carries over. You can start hand-rolled and switch later.

## The Agent Card

From **Capstone: An Agent for Your App**

**Fill this in for every helper you build.**

- **Job:** what it helps with, and for whom.
- **Shape:** one call, chain, router or agent.
- **Tools:** which ones, with clear cards.
- **Answer form:** boxes, allowed words and the number of retries.
- **Memory:** window size, sticky facts and customer memory.
- **Limits:** steps and budget.
- **Guardrails:** owner check, approval limit and the "just data" label.
- **Live replies:** progress chips and the Stop check.
- **Tests:** the scenarios it must pass before it ships.
- **Record:** what gets logged, who can read the log, and where API keys live (never in prompts).

**Simple lesson:** the best agent is often not an agent. When you do need one, give it clear tools, firm limits and tests.