Skip to content

Lesson 13 – The Tool-Agnostic Agent Playbook

The earlier lessons in this module taught specific tools: ChatGPT Codex, Gemini Canvas, n8n. Each has its own buttons, modes, and quirks. This capstone lesson steps back and distills the moves that work in any capable coding agent — Cursor, Copilot, Codex CLI, Gemini CLI, Aider, Claude Code, whichever your team runs. Learn the moves, not one vendor's menu. The product-specific chrome lives in your tool's docs; you look it up once.

Objective

Equip developers with a portable set of techniques for working with AI coding agents that transfer across tools and survive the next product rename. By the end, you should be able to brief an agent like you would a junior engineer, give it a way to check its own work, and run several at once without lock-in to any one vendor.

Training Outline

  1. The dividing line that matters – chat box versus agent.
  2. Ask the codebase questions first – learn the boundaries before you edit.
  3. Make it plan before it builds – cut the odds of building the wrong thing.
  4. Close the feedback loop – the technique that compounds.
  5. Describe the outcome, not the tool calls.
  6. Be specific.
  7. Let it drive your existing CLIs.
  8. Point it at git history.
  9. Keep a project rules file – AGENTS.md / CLAUDE.md.
  10. Give it your team's tools – MCP.
  11. Run work in parallel – git worktrees.
  12. Use the headless CLI as a Unix utility.
  13. Tool-specific chrome – and why it comes last.

1. The dividing line that matters

The split that matters is not Claude versus everyone else. It is chat box versus agent.

An agent runs commands, edits files, and reads its own output. A chat window does not. In a plain ChatGPT or Claude.ai window you still get Q&A, planning, and manual paste-back iteration — but you lose the autonomous loop. Every technique below that needs the agent to act keeps the word agent. Know which one you are in before you start.

Carries vs. autonomy

Many of these techniques still work in a bare chat window if you paste the code in. The technique carries; the autonomy does not. Where that distinction matters, this lesson calls it out.

2. Ask the codebase questions first

Before you edit anything, ask the agent questions about the code. This teaches you how to prompt and shows you the boundary of what the agent handles alone versus what needs your hand on the wheel.

A capable agent goes a level past text search. Ask how a class gets instantiated and it finds real call sites, not a keyword list — a deeper answer than the wiki holds. This works even in a bare chat window if you paste the code in; the autonomy is what you give up, not the insight.

3. Make it plan before it builds

Dropping a 3,000-line feature on an agent cold sometimes lands and sometimes builds the wrong thing. Cut the odds: tell it to brainstorm, draft a plan, run it by you, and wait for your sign-off before writing code.

Any frontier model does this on request. You do not need a special mode — you ask. This is the same discipline you met in Lesson 05 – Using ChatGPT Codex, generalized to every tool.

4. Close the feedback loop

This is the one that compounds. When the agent sees its own output, it self-corrects.

Give it a channel to check its work:

  • Unit or integration tests it can run.
  • A screenshot of the rendered web page.
  • A simulator capture for a mobile app.
  • The error trace from a failed run.

Hand it a mock plus a way to see the result and it lands close on the first pass and near-perfect after two or three iterations on its own.

flowchart LR
    A[Describe outcome] --> B[Agent edits code]
    B --> C[Agent runs it]
    C --> D{Tests / screenshot / error}
    D -- Pass --> E[Done]
    D -- Fail --> F[Agent reads output]
    F --> B

Pick the feedback channel that fits your domain and wire it in. In a chat window you stand in for the loop yourself by pasting the failure back. You saw this loop applied concretely to UI in Lesson 07 – Iterating on Web Page Code.

5. Describe the outcome, not the tool calls

Say what you want built. Let the agent sequence its own steps — search, edit, run, repeat. Naming each tool call slows you down and buys nothing; a capable agent strings the tools together better than your instructions would.

6. Be specific

Specific prompts beat vague ones every time, across every model. Talk to the agent the way you would brief another engineer. If typing the detail drags, dictate it — dictation ships in your OS and has nothing to do with which agent you run. The prompt-structuring discipline from Lesson 12 – LLM vs. ML Training applies here directly.

7. Let it drive your existing CLIs

The agent operates the tools your team already uses. Point it at a CLI and tell it to run --help to learn the interface. It reads the help text and starts using the command correctly. Any tool-using agent does this — there is nothing to install.

8. Point it at git history

When code looks wrong, tell the agent to read the git history. It finds who introduced a change, the surrounding situation, and the linked issues, then summarizes. A frontier model already knows how to use git. You point; it digs.

9. Keep a project rules file

Write down what the agent cannot discover on its own: stack, conventions, boundaries, commands. The agent makes better calls with it.

The portable standard is AGENTS.md. OpenAI originated it; the Linux Foundation's Agentic AI Foundation now stewards it. As of mid-2026 it ships in 28-plus tools and 60,000-plus repos, read natively by Codex CLI, Copilot, Cursor, Windsurf, Aider, Zed, and VS Code among others. Claude Code reads it too, with its own CLAUDE.md as a richer native format. Gemini CLI uses GEMINI.md. Put shared rules in AGENTS.md, and use a tool-specific file only for tool-specific config.

What to put in it:

  • Exact commands with their flags, not just tool names.
  • A three-tier boundary list: Always do, Ask first, Never do.
  • A flat project-structure map with a one-line purpose per file.
  • Code style as snippets, not prose.
  • Testing setup: framework, mocking strategy, coverage thresholds.

Keep it tight, and write it yourself

Two facts decide whether the file helps or just burns tokens. An ETH Zurich study found AI-generated context files cut task success roughly 3% and raised cost over 20%, while human-curated files delivered about a 4% gain. Write it yourself. Keep it under about 150 lines. Place nested files deeper in the tree and the agent reads the one closest to the file it edits.

10. Give it your team's tools

Hand the agent the tools your team already uses on a codebase and it operates them for you. The portable mechanism is MCP (Model Context Protocol), an open protocol adopted across OpenAI, Google, and the major coding tools. It is not a single vendor's feature, so this move transfers wherever you work. This is the principled foundation under the workflow wiring you built in Lesson 11 – n8n Workflow Automation.

11. Run work in parallel

You are not limited to one session. Keep several checkouts of a repo and run multiple agents at once. Use git worktrees to isolate them — both are plain git and shell, with zero product lock-in. Power users lean on this hard.

Connects back to Lesson 06

The conflict-avoidance discipline from Lesson 06 – Codex Actions in Parallel is exactly what keeps parallel agents from clobbering each other. Worktrees give each agent its own isolated working tree so their edits never collide.

12. Use the headless CLI as a Unix utility

Most agent CLIs run headless and pipe like any other Unix tool. Feed a log in, get structured output back, chain it with jq. Pipe git status through it and select the result. Read a giant log from a bucket, pipe it in, and ask what is interesting. The pattern shows up across tools, so learn it once and reuse it in CI, incident response, and pipelines.

# Illustrative: pipe a failing build log into a headless agent and ask for the cause
cat build.log | your-agent -p "What failed here and what is the smallest fix?"

13. Tool-specific chrome

Slash commands, key bindings, theme and terminal setup, the exact context-file name, the SDK flag — these differ per tool and change often. Learn your tool's equivalents from its docs once, then forget them and run the playbook above. The techniques outlast the menu, which is why this section comes last.

Exercise

🛠️ Run the playbook end to end on a small repo.

  1. Pick one agent your team actually uses.
  2. Write a tight AGENTS.md (or CLAUDE.md) for a sample repo — under 150 lines, hand-written, with the Always / Ask first / Never boundary list and your exact build/test commands.
  3. Ask the agent three questions about the code before editing anything (Section 2).
  4. Give it a feature and require it to plan first and wait for your sign-off (Section 3).
  5. Wire in one feedback channel — a test command or a screenshot — and let it iterate on its own until the channel goes green (Section 4).

✍️ Deliverable: Submit your AGENTS.md, the agent's plan, and a short note (5–8 sentences) on where the feedback loop saved you a round trip and where you still had to take the wheel.

Summary and Key Takeaways

  • The real split is chat box versus agent — know which you are in.
  • Plan before building and close the feedback loop are the two highest-leverage habits; the loop compounds.
  • Brief the agent like an engineer: be specific, describe outcomes, and let it sequence its own tool calls.
  • Capture institutional knowledge in a tight, human-written AGENTS.md; give it your tools via MCP; scale out with git worktrees and the headless CLI.
  • Tool-specific chrome is real but learn it once — the moves above transfer to whatever you run next.

This lesson closes Module 02 by tying together the tool-specific skills from Lesson 06 – Codex Actions in Parallel, Lesson 11 – n8n Workflow Automation, and Lesson 12 – LLM vs. ML Training into one portable, vendor-neutral playbook you can carry into any project.

Cortado Group / Cortado Labs | Tool-agnostic agent practices, Module 02 capstone