In Tropo: Know What Your Agent Is Good At

You read why this matters — that directing an agent well is a management skill you already have, aimed at the strangest coworker you'll ever staff. Here you put a face to it. You'll hand the same small job to your agent two ways — once telling it almost nothing, once adding a single line — and watch its shape show up in the difference. Then you write four short notes about your particular agent that you'll reuse on every build after this. You're not learning to author a spec yet; you're learning to read the worker. About fifteen minutes.

---

Part 1 — The Spec File

Here's the spec you'll build from. You didn't write it — authoring comes at rung four. For now you're borrowing a good one so the thing under the microscope is the agent, not your spec-writing. Read it. Notice it says what "done" means and what to leave out — a spec is as much about the fence as the field.

Which folder does this go in? The one your agent is already working in. If you're not sure which that is, just ask it: "What folder are you working in right now?" — and use the folder it names. (Many agents show it at the top of the window, too.) Everything in this walkthrough lives in that one folder.

Getting the spec into a file — the easy way. You don't need to hand-craft a .md file (and on a Mac, TextEdit will fight you — it likes to save .rtf and hide extensions). Let the agent do it. Paste the whole spec below into your agent and say:

Save the text below as a file named first-tracker.spec.md in the
folder you're working in. Just save it exactly as-is — don't build
anything yet.

<paste the entire spec here>

That's it — the spec is now a real file in your folder, created by the agent, spelled correctly, no extension surprises. (If you'd rather make the file yourself and you're comfortable doing it, go ahead — the result is the same. Today it's just a file the agent reads; governing it comes later in the series.)

Here's the spec to paste:

# Spec: Outreach Tracker

## Appetite
Small, ugly, working — ten minutes, not an afternoon. This is a personal
list I maintain by hand, not a product. If a feature would take longer than
the time it saves me over a month of outreach, it's out of scope — I'd
rather ship a smaller thing I actually keep updated than a bigger one I
abandon.

## Intent
**Who:** A person doing a round of outreach — job applications, sales
intros, partnership feelers, fundraising, whatever. Someone sending a
batch of "reach out, then wait, then follow up" messages.

**What problem:** After the fifth message you lose the thread. Who did I
already contact? Who owes me a reply? Who have I let go cold? It lives in
your head or scattered across email, and things slip.

**What we're building:** A single-screen tracker — one row per person
you're reaching out to — that shows at a glance who's where in the
pipeline, so nothing falls through and you always know who to nudge next.

## What "done" looks like
- One openable file. You double-click it, it opens in your browser. No app
 to install, no server to run.
- One row per contact. Each row shows:
 - **Name** — the person or organization (plain readable name, nothing
 else jammed in).
 - **Channel** — how you reached out (email, LinkedIn, intro, etc.).
 - **Owner** — who on your side is handling this contact (you, or a
 teammate).
 - **Stage** — where they are: `To send`, `Sent`, `Replied`, `Ghosted`,
 or `Closed`. (`Ghosted` = sent, no reply, and the follow-up window has
 passed — a live "left on read" state, distinct from a deliberate
 `Closed`.)
 - **Last touch** — the date you last did something on this one.
 - **Next** — the one thing you'd do next (a short note).
- The current active contact — the one you're waiting on right now — is
 visually obvious at a glance. Exactly one row is highlighted.
- Stages read as colored pills, not raw text: `Replied`/`Closed` look
 settled, `Sent` looks active, `To send` looks quiet, `Ghosted` looks
 like it needs a decision.
- Two or three example rows already filled in, so you see the shape
 immediately and can edit from there.
- There's a clear, obvious way to add a new contact row.

## One worked example
> **Row:** Dana Reyes · LinkedIn · **Sent** · Jun 30 · "Follow up if no
> reply by Jul 7"
>
> Dana is the contact you're currently waiting on — so her row is the one
> highlighted. You sent the LinkedIn message June 30, she hasn't replied
> yet, and your note to yourself is to nudge her July 7 if it's still
> quiet. One glance at the tracker and you know: Dana is the open thread,
> and July 7 is the date.

## Non-goals (leave these out)
- No login, no accounts, no cloud sync. It's a local file.
- No email integration — it does not send messages or read your inbox. You
 update it by hand.
- No analytics, charts, or "conversion rate" dashboards. It's a status
 list, not a CRM.
- No more than one screen. If it needs scrolling to read, it's too big.

That's the whole spec. It names who it's for, what "done" means, one worked example so the agent can't guess wrong, and the fence of things to leave out. You already write briefs like this for people. This is the same instinct, aimed at an agent.

---

Part 2 — The Build Walkthrough

Four turns. First you build the tracker once so there's something to change. Then comes the real exercise: you ask for the same change twice — bare, then with one line of context — and set the two results side by side. Each turn is a prompt you paste and a look at what comes back.

A note on what you'll see: the conversation is text — copy the prompts straight out. The tracker itself is the one thing you'll see as an image, because its whole point is that it's visual. And one honest caveat about the replies below: your agent's exact wording will differ every time — these blocks are roughly what you'll see, not a transcript to match. What matters is what the agent does to the file. Tropo runs the same way across tools; the words matter, the chrome doesn't.

Step 1 — Build the tracker once

The spec is now saved as first-tracker.spec.md in your folder. Direct the work — you're not writing the tracker, you're handing off a clear ask and letting it run.

Paste this:

I dropped a spec in this folder called first-tracker.spec.md.
Read it and build exactly what it describes — a single openable
HTML file I can double-click. Don't ask me questions, just build
it to the spec.

Roughly what comes back:

Read the spec. Built outreach-tracker.html — a single self-contained
file, no server, nothing to install.

It has the six columns from the spec (Name, Channel, Owner, Stage,
Last touch, Next) and four example rows:
 · Priya Menon — Replied
 · Dana Reyes — Sent (this is the highlighted row — your open thread)
 · Marcus Lee — Ghosted
 · Rivera & Co. — To send

Stages show as colored pills, Dana's row is the one highlighted, and
there's a "+ Add a contact" button at the bottom.

Open it with: open outreach-tracker.html

Now open it. Find outreach-tracker.html in your folder and double-click it — it opens in your browser. (If you're comfortable in a terminal, the agent's open outreach-tracker.html does the same thing — but you never need the terminal for this.)

[screenshot: your working tracker] A light bone-and-white board, one screen, no scroll. An ember eyebrow reading TRACKER · OUTREACH, a title "Who I'm reaching out to," and a status line: "Waiting on Dana Reyes — nudge Jul 7." Below it, four rows — Priya Menon (Replied, green), Dana Reyes (Sent, ember — the single highlighted row), Marcus Lee (Ghosted, amber), Rivera & Co. (To send, quiet). A + Add a contact button at the bottom.

That's the board you're about to change — twice.

Step 2 — Ask for the change with no context (the bare run)

Now the exercise starts. You want a new column: Priority — how urgently each contact needs attention. You're going to ask for it in the most minimal way a busy person actually would, giving the agent nothing but the ask. This is the "bare run." Watch what it fills in on its own.

Paste this — exactly this, nothing more:

Add a Priority column to the tracker.

Roughly what comes back:

Done — added a Priority column to outreach-tracker.html with a value
in each row:
 · Priya Menon — High
 · Dana Reyes — high
 · Marcus Lee — Medium
 · Rivera & Co. — Low

Reload to see it.

Reload the file. Look hard at what it actually did — this is the point of the run:

• The mechanics are perfect. It added a real header cell and a matching cell in every row; the table stays balanced and the file still opens. It never breaks the plumbing.
• It put the column at the far right, after "Next" — the weakest spot, not next to Stage where you actually scan.
• The casing is inconsistent: High, then high, then Medium, then Low. Ugly, and it means you can't reliably sort or filter later.
• It's plain grey text — every other status in the tool is a colored pill, but Priority, the thing that should pop, is the flattest column on the screen.
• The rows didn't re-sort — "High" is scattered top to bottom instead of rising to the top.

None of that is a bug. It's the agent's shape: it nailed the how and guessed the what — and it guessed toward "quick and literal," not "match what's already here." Hold that picture. You're about to fix all of it with one sentence.

Step 3 — Ask for the exact same change, plus one line (the context run)

Rebuild the tracker fresh first, so both runs start from the identical board — paste Step 1's build prompt again to reset it. Then ask for the same Priority column, but this time add a single line naming the three things the bare run guessed wrong: the values, the order, and the styling.

One line of intent. Paste this:

Rebuild outreach-tracker.html from first-tracker.spec.md, then add a
Priority column: high/med/low, sorted high-first, match the existing
pill styling.

Roughly what comes back:

Rebuilt from the spec, then added the Priority column:
 · Dana Reyes — High
 · Priya Menon — High
 · Marcus Lee — Med
 · Rivera & Co. — Low

I placed it right after Stage, used the tool's existing pill styling
(high glows like an active state, low recedes), normalized the values
to High/Med/Low, and re-sorted the rows high-first. I also updated the
"+ Add a contact" button so new rows come in with a Priority pill too.

Reload to see it.

Reload and set the two side by side. The one line did more than its three words:

• All three named asks landed: normalized values (High / High / Med / Low), rows re-sorted high-first, and real pill styling that reuses the tool's own pill grammar.
• And it pulled the rest up with it. With the quality bar raised, the agent also moved the column next to Stage on its own and — the one that matters most — updated the hidden "add a row" code so new rows keep the Priority pill. One line of intent raised the quality of the whole change, not just the three things you listed.

[screenshot: bare run vs. context run, side by side] Left: Priority stranded at the far right in plain grey text — High, high, Medium, Low — rows in their old order. Right: a PRIORITY pill column right after Stage — High, High, Med, Low — pills matching the stage pills, rows re-sorted high-first.

Same agent, same ask, one line of difference. That gap is the whole lesson of this rung: you just watched your agent's shape — where it's reliable, where it guesses — show up in the artifact. Now you're going to write it down.

Step 4 — Write your agent-profile notes

This is the deliverable you keep. Everything above was to learn your agent; this is where you bank what you learned so you never re-learn it. Have the agent drop a notes file next to your tracker, then you fill it in — in your own words, from what you actually saw in the two runs.

Paste this:

Save the text below as a file named agent-notes.md in the folder
you're working in. Save it exactly as-is — I'll fill it in myself.

# Agent notes
_Just notes, not yet governed — I'll reuse this on every build.
Lives next to the tracker._

Filled in after running "add a Priority column" twice against the same
tracker — once bare, once with one line of context — side by side.

## What it did well with no context
> What did the bare run get right on its own?
-

## What it guessed wrong
> Where did the bare run fill a gap with a guess I wouldn't have made?
> (placement, values, casing, sort order, styling, the parts it forgot)
-

## What one line of context fixed
> I added one sentence. Which wrong guesses did that one line correct?
-

## What I'll always spell out for this agent
> The standing rule. Next time I ask for anything like this, what do I
> say up front so I never get the bare-run version again?
-

_agent-notes · rung 3 · reuse me_

Then fill it in. Here's what the two runs above would give a reader who watched closely — yours will read like this, in your own words:

## What it did well with no context
- Got the mechanics right unprompted: a real header cell and a matching
 cell in every row, table stayed balanced, file still opened. And it
 understood what "priority" means for outreach — sensible high/med/low
 values with no list from me.

## What it guessed wrong
- Placement: dumped it at the far right, after Next — the weakest spot.
- Casing: High / high / Medium / Low. Can't sort or filter on that.
- No styling: plain grey text while every other status is a colored pill.
- No sort: High scattered top-to-bottom instead of rising.
- Forgot the moving part: never touched the "add a row" code, so any
 NEW contact I add would come in missing a Priority cell.

## What one line of context fixed
- One sentence — "high/med/low, sorted high-first, match the existing
 pill styling" — landed all three, AND fixed placement and the add-row
 code I never mentioned. One line of intent pulled the whole change up.

## What I'll always spell out for this agent
- This agent nails the HOW and guesses the WHAT. It always wires the
 mechanics; it always guesses placement, formatting, and consistency if
 I stay silent — toward "quick and literal," not "matches what's here."
- So for any change to this tool I now say three things up front: exact
 values, where it goes, and "match the existing styling."
- And I name the moving parts (the Add button, any behavior) explicitly —
 it won't extend those unless I point at them.

That file is the point of the rung. It's your read on this agent, written in the one form you'll actually reuse.

---

Part 3 — The Verification Checklist

Directing is half the job. This is the harder half — deciding whether what came back is right, not just whether it exists. "It looks finished" is not "it's correct." So don't read this as a row of checkmarks to admire. Perform it. You review other people's work all the time; you know the difference between glancing and actually checking.

Go to the two tracker versions and do this now, before you call it done:

1. On the bare run, click + Add a contact. Watch the new row. The bare agent never updated the add-row code, so the new row comes in with one cell fewer than the header — its columns slide out of alignment (or the Priority slot is simply missing). This is the trap the agent left, and clicking is the only way to see it — nothing in the file looks wrong until a new row appears. If you can't tell, count the cells in the new row against the header count.
2. On the context run, click + Add a contact. Now the new row should come in with a Priority pill and every cell lined up under its header. That's the difference the one line bought you — and the difference between a tool that's demo-correct and one that's correct in use.
3. Compare the casing across the two runs. Bare: High / high / Medium / Low — mixed. Context: High / High / Med / Low — normalized. If your context run still has ragged casing, the "high/med/low" part of your line didn't take — send it back.
4. Count the highlighted rows on each version. There must be exactly one — Dana. If two rows glow, the "one open thread at a glance" promise is broken, and the spec said exactly one.

Now fill in the receipt — with what you saw, not what you hoped:

What was asked	The same change — add a Priority column — run two ways against the same tracker: once bare (nothing but the ask), once with one line of context (values, sort, styling). Then a written profile of how the agent behaved.
What you can now do yourself	Read your agent's shape from its output — see where it's reliable (mechanics) and where it guesses (placement, casing, styling, the parts it forgets to touch) — and correct all of it with one line of intent given up front instead of a round of rework after.
What the record shows	first-tracker.spec.md, outreach-tracker.html, and agent-notes.md sit in your folder. The two runs are the evidence: bare left Priority stranded and mixed-case with a broken add-row; one line of context put it next to Stage, styled it, sorted it, and fixed the add-row. The gap between them is your agent's shape, in plain sight.
What's not done yet	agent-notes.md is just a file living in your folder right now — not yet a governed file your studio tracks. That upgrade (give it a uid: and let the rebuild pick it up) comes later in the series. You also haven't authored a spec of your own yet — that's rung four. Today you learned to read your agent and banked the read. That's the win.

If the bare run's add-row didn't break, or the context run's add-row didn't include a Priority pill, or the casing stayed ragged — you caught it, which is exactly the job. Send the broken one back:

The "+ Add a contact" button is out of sync with the columns — a new
row should come in with a Priority pill and every cell lined up under
its header. Fix the add-row code to match.

Directing includes rejecting. That's not the loop failing; that's the loop working — and catching the missed add-row yourself, when the agent's reply said "done," is the exact skill this rung is teaching.

---

Part 4 — What You Now Have in Your Studio

You started able to build with an agent. You end able to read one — to see, from what it hands back, where to lean on it and where to spell things out.

In your folder, right now:

• A working tracker — outreach-tracker.html, a real tool you can open, read at a glance, and add contacts to. Not a demo. Use it for your next round of outreach.
• Two runs you can compare — the bare version and the one-line-of-context version, side by side. The gap between them is the single clearest picture of your agent's shape you'll get: reliable at mechanics, a guesser at everything unstated.
• Your agent-profile notes — agent-notes.md, in your words, from what you actually saw. That's the reusable one. It turns "I hope this comes back right" into "I know what to say up front so it does" — on every build after this.

It's doable. It's not automatic — the agent won't tell you its own weak spots unless you make it (that's the Power Play in the essay), and you had to run the change twice and check the add-row yourself to see the shape. But you did, and now you can read it. Next rung: you stop borrowing the spec and start authoring the ask — and you'll write it knowing exactly what your agent needs spelled out. For now — you learned your agent, and you wrote it down.

**