Every request becomes parallel work.
The Manager is a persistent lead. It hands the brief to specialists that each hold a different piece of Solana, and reviews what comes back before anything merges. Two agents touching the same program can't clobber each other; each one works in a separate git worktree.
Splits each request into parallel tasks and assigns the crew.
The Manager assigns the work. The specialists run in parallel.
It knows the layers a real project actually touches.
Every agent loads the account model, rent, PDAs and signer checks before it writes a line, plus the token, testing and DeFi layers most newcomers never get to.
We planted four bugs. It caught all four.
The Review agent catches the footguns Anchor doesn't catch for you, and explains each one in the review before the merge lands. The same eval runs in CI on every mainline push, so a regression fails the build instead of the audit.
- ✕Missing signer check
State mutated for an account that was never required to sign.
- ✕Non-canonical PDA bump
A caller-supplied bump accepted where the canonical one is required.
- ✕Lamport overflow
Unchecked arithmetic on a balance that wraps in release builds.
- ✕Token vs Token-2022
Assumes the legacy token program against a Token-2022 mint.
All four sit on the 24-item footgun checklist the Review agent is graded against in CI.
pub fn withdraw( ctx: Context<Withdraw>, amount: u64, bump: u8, ) -> Result<()> { // bump comes from the caller and is // never compared to the canonical one let seeds = &[ b"vault", ctx.accounts.owner.key.as_ref(), &[bump], // ← not canonical ]; **ctx.accounts.vault .to_account_info() .try_borrow_mut_lamports()? -= amount; Ok(()) }
A tutor that shows its work.
You can read every prompt, rule and knowledge module the system loads, and trace any choice an agent made back to the rule that produced it.
Prompts you can read
A read-only view of each agent's expertise and the knowledge modules behind it.
Corrected in review
The reviewer explains each footgun where you'll see it, so the lesson lands with the diff.
A worked example
What lands in the repo is working Solana code you can read and run.
All of it lives in the repo, and you can read any of it.
The agents get tested like the code they write.
The planted-bug eval runs in CI on every mainline push and goes red when the reviewer misses a seeded bug. The end-to-end suite drives a real local validator, and both live in the repo for you to run yourself.
Built like infrastructure, not a product demo.
The same evals and footgun checks follow each change to the agents. When a Solana standard moves, the prompts catch up and the evals say whether anything broke.