A personalised advanced multi-model, multi-agent system
Several model families reviewing in parallel, a jury that argues findings before any of them reach you, and rulebooks written for your protocol rather than a generic checklist — the same architecture behind our EVM and DAML reviews, shaped to your codebase.
The standard workspace already runs that architecture: five lenses read your source concurrently, a three-juror panel votes on every candidate finding, and a devil’s advocate gets the last word before anything is written into a report. A custom workspace keeps the shape and replaces the contents — the lenses, the rulebooks, the severity bar and the routing all become yours.
What does not change: no single model’s opinion ever becomes a finding on its own. Hunters, jurors and the judge are routed across independent model families by design, and that separation is the point of the architecture — it is not something we relax to fit a custom build.
Rulebooks written around your protocol’s own invariants
A generic checklist asks whether your code contains known bad patterns. It cannot ask whether your code still holds the properties you depend on, because nothing in a generic checklist knows what those properties are.
A custom rulebook starts from the invariants you can already state about your protocol — the thing that must never be true, the accounting identity that must balance, the role that must never be assumable, the sequence that must never interleave. Those become rules the hunters actively look for violations of, in the same structured form as the rulebooks that ship with the product.
- Properties you can already articulate, written down as checkable rules
- The failure modes you have seen before in your own system, or in protocols you fork from
- The assumptions your contracts make about callers, oracles, and upstream protocols
Model families chosen per lens, so no one family both raises and confirms
Every lens is a different reading of the same source, and different model families are genuinely better at different readings. Routing is therefore decided per lens rather than per run: the family that proposes a candidate finding is not the family that votes on it, and not the family that tries to overturn it.
That is what stops the panel from agreeing with itself. A single model asked to check its own work will usually confirm it; a juror from a different family, seeing the finding without the reasoning that produced it, frequently does not.
| Stage | What it does | Why the family changes |
|---|---|---|
| Hunters | Read the source through one lens each and propose candidate findings independently | Different families surface different classes of issue from identical input |
| Jury | Three stances vote cold, then deliberate only if they split | A juror sharing a family with the hunter inherits its blind spots |
| Judge | A devil’s advocate tries to overturn what the jury confirmed | Overturning needs a reader with no stake in the original reasoning |
Your risk axes and severity bar, not ours
Severity is not a property of a bug; it is a property of a bug in your system. A rounding error that is noise in one protocol is the whole exploit in another, and a centralisation finding that matters enormously to one team is a documented, deliberate design decision to the next.
So the axes a finding is scored on, and the bar it has to clear before it is worth your attention, are set for your build rather than inherited from ours. In practice that is the difference between a report you act on and a report you spend a week triaging.
- The axes you actually track, with your own weighting between them
- Your threshold for what counts as reportable, so the noise floor is yours
- Classes of finding you have already accepted, recorded as accepted rather than raised again every run
Runs against your pipeline, on your schedule
A review that only happens when someone remembers to upload a file is a review that happens rarely. A custom workspace is built to run where your code already moves — against the branch, on the cadence, and into the place your team already looks.
- Triggered on your schedule, or on the events that matter in your repository
- Reads the branches and repositories you point it at, including private ones
- Reports in the formats the workspace already produces — Markdown, PDF, DOCX
- Re-check rounds tracked as engagements, so a fix is verified against the finding it closes
How a build starts
It starts with a conversation, not a form. Ask for a callback and a person gets in touch to work out what you are building, what you need caught, and whether a custom workspace is actually the right answer — for a lot of teams the standard review already is, and we would rather tell you so.
No obligation and no sales sequence. Either an email or a phone number is enough — we only need one way back to you.
Tell us what you are building
If you already know the properties your protocol must hold, that is the whole starting point — the rest is our job.