Spend good-model time deciding what to do and proving it worked. Give cheaper models the parts you can describe clearly. That’s the approach behind my current agent setup.
Here are the tools, skills and instructions I use, with downloads you can adapt. The resources are freely shared. Running the models and connected services may still cost money.
Put a strong model in charge
I’d start with Prime Agent. It lets an agent create and direct other agents, keep work running in the background and communicate with its workers. I’m finding it really good with the new Astra release.
My personal setup uses Astra at medium reasoning as the lead. Luna workers use max reasoning for bounded implementation, research and checks. Those roles live in my instructions. The agent checks model availability before delegating; the configuration doesn’t grant access to a model your account can’t use.
The lead has a different job from its workers:
- Understand the objective, choose an approach and define the checks.
- Write focused prompts for workers, with the relevant context and a clear definition of done.
- Inspect their results, request corrections and accept the final work.
You don’t need to write every worker prompt yourself. The lead can work out which files matter, explain the decisions already made and give each worker an outcome it can verify.
Take a website as an example. The lead reads the brief and design reference, settles the layout, then delegates individual components and browser checks. Difficult design decisions and debugging stay with the lead.
A useful worker brief might look like this:
Build the navigation using the supplied design reference and existing components. Limit edits to the navigation files. Check the mobile layout, keyboard navigation and open/close behaviour. Return the changes, the checks you ran and anything unresolved.
This can reduce cost when the workers have clear tasks. Ten cheap agents repeating the same investigation can cost more than one capable agent doing it properly. Measure the total cost of an accepted result, including retries and review.
Use different agent tools together
I use Orca ADE to organise the work. An agent development environment gives you a place to manage agent terminals, branches and results. Orca runs tools such as Codex, Claude Code, Pi and Antigravity side by side, with separate Git worktrees so writing agents can work in their own checkouts. It also connects to GitHub and Linear. The source is on GitHub.
The software surrounding a model is often called its harness. It provides tools, permissions and session management. An agent in one harness can invoke another through its command-line interface, pass it a brief and collect the answer.
For example, Antigravity’s agy CLI has a headless mode. Running agy -p "your task" returns a response without requiring an interactive terminal conversation. A lead agent can use that for a research task or an independent review.
For YouTube research, give the worker a URL and ask for relevant findings, timestamps and a statement of what it actually accessed. Provide a transcript when direct access isn’t available. A plausible summary isn’t proof that the agent watched the video.
For review, give another model family the requirements and actual changes. Different training and tuning can produce different blind spots. Ask for specific defects and evidence, then check the findings. Agreement between models is useful, but it doesn’t replace testing. My formal Orca acceptance reviews remain tracked with their evidence.
Keep the state of the work outside the chat
I use Linear as a durable task state register. That means the ticket is the place to look for the current objective, decisions, owner, dependencies, acceptance criteria, status and completion evidence.
When a session ends or I switch tools, the next agent reads the ticket and continues. It doesn’t have to reconstruct the plan from a long conversation or guess whether another worker finished a prerequisite.
For a tracked task, the lead confirms the scope, assigns unblocked work and records meaningful changes as the job progresses. Workers report their results. The lead checks the evidence before closing the ticket or allowing dependent work to start.
That distinction matters. A worker finishing its attempt and the result being accepted are separate events.
Not every typo needs a ticket. My instructions distinguish small, obvious corrections from bounded tasks that need tracking, and new capabilities that need a specification and implementation tickets.
Two other tools give the agent useful context:
- GBrain holds searchable knowledge that survives individual chats. I use it for reusable background and research. Linear remains authoritative for task status.
- codebase-memory MCP indexes code into a graph of functions, classes and relationships. It lets agents find symbols and trace callers without repeatedly reading large parts of the repository. My instructions require checking index freshness and verifying important logic against the actual source.
MCP is the connection that exposes a tool’s capabilities to the agent. My setup also includes Context7 for looking up library documentation.
Borrow the skills
A skill is a reusable set of instructions, sometimes with scripts and reference material, that teaches an agent how to handle a particular job. You can give the next agent the working method without explaining it from scratch.
pstack, by poteto, is worth starting with. It covers planning, delegation, competing approaches and independent review. Its verification skills teach agents how to drive the real app and capture evidence. It also includes blast-radius, automate-me and reflect for checking wider effects, capturing working preferences and retaining lessons. Model choices can be configured by role.
Matt Pocock’s skills help turn an idea into work that agents can pick up:
- wayfinder resolves the decisions in a project too large or uncertain for one session. Use it when the route is still unclear.
- to-spec turns the agreed decisions into a specification.
- to-tickets splits the spec into small, independently verifiable pieces of implementation with explicit dependencies.
Start at the step you need. A settled feature doesn’t need another round of open-ended planning.
I also use ponytail to keep implementations simple and avoid unnecessary code. My writing skill covers clear prose, technical documentation, removing formulaic AI writing and writing instructions for other agents. It’s included below.
Make the lead prove the result
I’d spend high-quality model time on verification early. Before workers start, the lead should establish how to run the app and what observable result proves the task is complete.
For a form, that means checking validation, submission and whether the data was saved correctly. For a visual change, compare the rendered page against the reference at the relevant screen sizes. A screenshot can prove appearance; it can’t establish that a record was saved.
My setup asks implementation workers to use test-first development for testable behaviour. Astra then inspects the actual changes and runs the required acceptance checks independently. Repairs go back to the worker, followed by another check of the changed result.
A strong model’s judgment helps choose the right checks and recognise gaps. The running software provides the evidence.
Take the setup
The Free Game repository hosts these snapshots of my setup from 5 September 2026:
- Download my Prime Agent setup. Includes the Astra/Luna guidance, all 12 active custom skills and their references, model settings, MCP connection templates and setup notes. The launcher and workaround scripts are included as reference files, along with optional work-profile settings.
- Download my Prime Agent writing skill. One skill with routes for clear writing, antislop checks, technical writing and instructions for agents.
The setup is an opinionated configuration pack. Read the included instructions and adapt the paths and policies before using it. You’ll need your own logins, supporting tools and model access. Credentials, private endpoints, personal knowledge and chat history are excluded. The packaged files were checked for integrity; the pack hasn’t been installed against your accounts.
Pick one real task. Give it a clear outcome, a strong lead and a way to verify the result. Add cheaper workers when there’s independent work for them to do. Increase the parallelism once you trust what comes back.