How I use agents.

01

Start with what actually happened.

Before an agent changes anything, I want it to check where things stand. A previous conversation might say a problem was fixed, but does the fix exist in the code, and has anyone tried it? I want the agent to read the notes, look at the actual files, and check the results before continuing.

agent-session-resume ↗ helps pick up previous work across Codex, Claude Code, Antigravity, and OpenCode. It uses the notes left by the previous agent alongside the work itself. AgentCanvas gives me a place to look through that work with the agent, rather than relying only on its summary.

02

Keep the instructions that help.

When an instruction is useful across several tasks, I keep it in a skill: a saved set of instructions an agent can use again. It might explain where to look when something fails, how to check a change, or when to ask me before going further.

I keep one main copy of each skill and use symlinks, which are file-system links, to make it available to different tools. That way I can update the instructions in one place instead of maintaining several copies that gradually say different things.

03

Choose a model for the job.

I use Codex to investigate problems, write code, and test it. I ask Claude for another view on design, how an idea is explained, and what a decision might cause later. Gemini helps me work through large amounts of information, and I use Grok to question the approach and whether we need everything we're planning to build.

The model-orchestrator ↗ helps choose which model to use for each job. I still make the decisions that need me; having several models involved gives me more ways to check the work and question my assumptions.

04

Make access explicit.

An agent can do more when it can read the code, open a browser, and use the tools involved in the task. I also need to know what it can see, what it can change, and when it needs my permission.

I keep a list of those connections in an MCP registry. MCP is a way for agents to connect to tools and services. The registry records what each connection does, which agent tools can use it, whether it has been tested, and when I need to approve its use. Being able to read something doesn't automatically mean the agent should be allowed to change it.

05

Work through a task.

1. Catch up. Read the previous notes and check the actual work before deciding where to continue.
2. Decide. Work out what needs a decision, what the options are, and what we give up by choosing each one.
3. Build. Make the change needed to solve the problem without adding unrelated work.
4. Review. Bring in another reviewer when a fresh look could help catch mistakes, improve the design, or question how much we need to build.
5. Try it. Check the result directly: open the page, send a request to the service, check the released version, or work through the task as a user would.
6. Continue. Leave notes on what changed, what was tested, what still needs checking, and what to do next.

06

Learn from repeated problems.

Once a week I look through the work for repeated failures, useful workarounds, and places where an agent needed too much supervision.

I then decide whether to leave it alone, save a note, improve the instructions, or automate something I keep doing by hand. Some useful instructions stay private; others become skills I share publicly. If I keep correcting the same mistake, I want to change the setup so I don't have to keep repeating myself.