Your agent, one job end to end (the win)

Complete Give your agent tools first. You need the tools concept to understand what your agent can and cannot reach.

This is the lesson where your agent does a real job and you hold the result in your hands. Not a demo. Not a hypothetical.

You will feed your agent a real batch of input, watch it work through the perceive-decide-act loop with real stakes, and walk away with output you would actually send, file, or act on.

The previous lessons built the foundation: you know what an agent is (Lesson 1), you built one with a specific job and persistent instructions (Lesson 2), and you understand how tools extend what it can reach (Lesson 3).

Now you put it all together: one job, start to finish. Real input, real output, real evaluation.

Here is what "end to end" means concretely:

Start: you bring a real batch of input to your agent Project. Not a test batch, not three sample emails.

The actual pile of stuff that has been sitting on your desk or in your inbox. The messier, the better, because that is what the agent will face every week.

Middle: the agent runs the loop. It reads your input (perceive), applies the rules you wrote in the Project instructions (decide), and produces structured output (act).

You watch for two things: did it follow the instructions, and is the output something you would actually use? Not "is it impressive," but is it useful.

End: you have a finished artifact: a triage summary, a set of draft replies, a sorted task list, a report. Whatever job your agent does, the artifact is the proof it worked.

If you would send the draft, file the summary, or act on the list, the agent passed. If you would rewrite it from scratch, the instructions need tightening.

The quality bar is yours, not the agent's. The agent does not know if its output is good. You do.

This is the step most people skip: actually holding the output against your own standard and being honest about where it falls short. That gap is exactly the information you need to improve the instructions.

What you will notice is missing (and that is the point):

After you run the full job, you will hit real edges. The agent cannot remember what it did for you last week (it starts fresh every conversation).

It cannot pull information from your calendar or CRM without you pasting it in. It cannot hand part of the job to a second specialist agent.

Those three gaps are exactly what the premium modules in this track close: - Memory (Module 4) gives the agent recall across sessions, so it builds on what it learned last week instead of starting cold. - Connected tools via MCP (Module 5) lets it reach into your real services (email, calendar, project tracker) without you copy-pasting. - Agent teams (Module 8) let you split a complex job across specialists that hand work to each other, so a research agent feeds a writing agent that feeds a review agent.

Those are the next rungs. The free funnel you completed proves the pattern works. The premium modules remove the manual steps that keep you in the loop.

This is the real run. No practice input. No test data.

STEP 1: GATHER REAL INPUT
Collect the actual batch of input your agent is designed to process. If your agent triages email, open your inbox, select the unread messages, copy them, and paste as plain text. If it summarizes reports, bring a real report. If it sorts tasks, bring your real task list. The messier and larger the batch, the more honest the test.

Privacy note: before pasting, strip names, account numbers, and anything sensitive you would not want in a chat log. Replace them with placeholders like [Client A] or [Account #].

STEP 2: RUN THE FULL JOB
Open your agent Project. Start a new conversation. Paste (or point to) the full batch. Let the agent run. Do not intervene, correct, or prompt it mid-run. Let it finish.

STEP 3: EVALUATE THE OUTPUT
After the agent finishes, ask Claude this inside the same conversation:

"I'm going to evaluate your output. For each section you produced, I'll rate it SEND (I would use this as-is), EDIT (needs minor changes), or REDO (I would start over). Walk me through each section so I can rate it."

Be honest. A SEND is something you would actually forward, file, or act on today. An EDIT needs a few fixes but the structure is right. A REDO means the agent missed the point.

STEP 4: EXTRACT THE IMPROVEMENT
After rating, ask Claude:

"Based on my ratings, what are the top 2 changes to the Project instructions that would turn the most EDITs into SENDs? Write the updated instruction lines I should replace."

Take those changes, update the Project instructions, and run one more batch. See if the SEND count improves.

## Evaluation: Weekly Email Digest, June 16

### Urgent section
**Rating: SEND.** Correctly identified the proposal deadline change as the top item. Summary is accurate and concise.

### Needs Reply section
**Rating: EDIT.** Both draft replies are close but the tone on the vendor response is too formal for how I write to CloudHost. Need to add "match my casual tone for vendor emails" to instructions.

### FYI section
**Rating: SEND.** Clean, no unnecessary detail. Correct that no action is needed.

### Overall structure
**Rating: SEND.** Categories are right, formatting is consistent, total is under 300 words as instructed.

**Score: 3 SEND, 1 EDIT, 0 REDO.**

### Top 2 instruction changes:
1. Add: "For vendor and supplier emails, use a casual, direct tone. No 'Dear' or 'Regards.'"
2. Add: "If a Needs Reply email is low-stakes (scheduling, confirmations), keep the draft under 30 words."

What good looks like

• You ran the agent on a real, full-size batch of input from your actual week
• You rated every section of the output honestly (SEND, EDIT, or REDO)
• At least one section earned a SEND rating on the first run
• You extracted instruction improvements and applied them to the Project
• You ran a second batch with the improved instructions and saw at least one rating upgrade

Now that you have a working agent with a real result, map the edges. Open a fresh conversation (outside your Project) and paste this:

"I built an agent that [describe your agent's job in one sentence]. It works well for [what it handled]. But I noticed these limits:

1. It does not remember what it did last week.
2. It cannot pull data from [name the services you wished it could reach].
3. When the job gets complex, I wish it could hand part of the work to a specialist.

For each limit, explain in one paragraph what would fix it and what that fix is called in agent terms (memory, MCP connectors, multi-agent teams). Keep it practical, not theoretical."

This exercise connects what you experienced to what the premium track teaches. You are not buying features in the abstract. You are buying fixes for edges you personally hit.

What good looks like

• You named at least two real limits you hit during the full run
• Claude mapped each limit to a specific agent concept (memory, MCP, multi-agent)
• You understand what each premium module would concretely fix in your workflow