Part VII gave you places for work to run — a Mac mini, a VPS, a queue, a schedule, logs you can inspect. Now something new starts running in those places: a program that receives a goal, decides what to do next, uses tools, remembers what happened, and keeps going until the job is done or it needs help.

That program is an agent. And the most important thing to learn first is what it is not: it is not a clever prompt.

The formula to memorize

Here is the definition you will use for the rest of Part VIII:

model + instructions + tools + state + loop = agent

Each piece has a job. Learn them separately before you combine them:

• Model. Proposes language, plans, and next actions. It guesses well, but it does not remember reliably, and it cannot touch the outside world by itself.
• Instructions. Define the job: what the agent is trying to achieve, what it may and may not do, and when to stop or ask for help. Think of this as the standing work order.
• Tools. Defined capabilities the agent can call — search a source, read a file, write a draft, query a database. The model asks; the tool acts.
• State. Durable progress the next step or the next run can use: which sources were checked, what was found, what still needs review.
• Loop. The execution pattern that ties it together: think, act, observe what happened, update state, decide whether to continue or stop.

Remove any one of these and you no longer have an agent. A model with instructions but no tools is a chatbot. Tools with no loop is a single function call. A loop with no state forgets everything the moment the run ends.

One turn versus a carried job

Compare two requests.

One-turn request: "Summarize this article." The model reads the text in front of it, produces a summary, and stops. There is no outside lookup, no saved record, no follow-up decision. Useful — but nothing carries forward.

Agent job: "Each morning, check these five approved industry sources, save anything new about two named competitors, and prepare a short review packet for me." Now watch what has to happen:

receive goal → load source list and last-run state
  → check each approved source (tool calls)
  → compare findings against what was already saved
  → save new findings with citations and timestamps
  → prepare a review packet → stop and wait for human review

The model is involved at several steps — deciding which findings matter, drafting the packet — but the system around it does the carrying: the source list, the saved record, the comparison, the stopping rule. That system is the agent.

This is why "a clever prompt" is not enough. A long, detailed prompt can improve one answer. It cannot check five sources tomorrow morning, remember what it already saved yesterday, or stop itself when the evidence is thin. Only a system with tools, state, and a loop can do that.

A concrete example: the research monitor

Imagine a small research monitor built for a founder who tracks two competitors. Its world is deliberately narrow:

• Goal: surface new, citable facts from approved sources — nothing else.
• Inputs: a list of five approved URLs or feeds, plus the two competitor names.
• Tools: fetch a page, search saved notes, write a draft packet.
• State: last check time, which items were already recorded, which items are pending review.
• Output: one Markdown packet per run with findings, links, and a confidence note.
• Stop condition: after all five sources are checked, or after ten minutes, whichever comes first. Then it stops and waits.
• Human owner: one named person who reviews the packet.

Notice what is missing: the agent cannot browse the open web freely, cannot publish anything, cannot email anyone, cannot spend money. Its narrowness is the feature. A beginner mistake is to give an agent the whole internet and a vague goal like "keep me informed." A working agent has a short source list and a visible finish line.

Run it twice to see why state matters. On Monday it checks five sources, finds three new items, saves them, and reports. On Tuesday it checks the same five sources — but because Monday's findings are saved in state, it reports only what is genuinely new instead of repeating Monday's packet. Without state, every run starts blind.

Why this lesson comes first

Every later class in this part assumes this formula. Class 29 asks whether a platform feature is really an agent (does it have all five parts?). Class 30 dissects the loop. Class 31 designs the tools. Class 32 decides where the system runs. Class 34 chooses durable memory. If you can point at any proposal and ask "where are the instructions, the tools, the state, the loop, and the stop condition?" you are ready for all of it.

Check your understanding

1. Name the five parts of an agent in your own words, with one sentence for each. 2. Why does a long prompt alone fail at a job like "check these sources every morning"? 3. What does state let the Tuesday run do that the Monday run could not? 4. Why is a narrow source list safer and more useful than "search the whole web"?

Exercise: write AGENT-CARD.md

Create a file called AGENT-CARD.md for one agent idea of your own — a source watcher, a ticket classifier, a freshness checker. Keep it small. Use this shape:

# AGENT-CARD: <name>

Goal: <one sentence — what job does it carry forward?>
Input: <what it reads each run>
Tools: <named tools it may call>
Output: <exact artifact it produces and where it goes>
Stop condition: <when it must stop, e.g. sources done / N steps / N minutes>
Human owner: <one named person who reviews the output>

Worked example:

# AGENT-CARD: Competitor Watcher v1

Goal: Surface new citable facts about two named competitors each morning.
Input: 5 approved source feeds + saved findings from prior runs.
Tools: fetch_page, search_saved_notes, write_review_packet.
Output: `review/YYYY-MM-DD-packet.md` with findings, links, confidence note.
Stop condition: Stop after 5 sources checked or 10 minutes; never publish or email.
Human owner: Darin — reviews packet before anything is shared.

Finish line: one AGENT-CARD.md with all six fields filled in — goal, input, tools, output, stop condition, owner.

Verify: hand the card to someone else (or reread it tomorrow) and ask: could they tell what the agent does, what it produces, and when it stops — without asking you anything?

Common failure: the goal says "runs my business" or "handles research." Shrink it until the output is one named file and the stop condition is a number. Lesson 28.4 will help you cut it down further.

In the next lesson, you give the system hands: what tools are, and why the smallest safe tool comes first.