assay · audience · for the people who run the fleet
You run the agents. Here is where each question lands.
Four situations arrive here, and they want different things: the fleet operator, the team lead with the platform engineer who installs it, one person with one repository, and a reviewer who checks from the outside. Find the one that fits, follow the two or three pages that answer it, and read the boundary where the answer is still being built rather than a page you can open today. Nothing below routes you to a page that does not exist.
You run a fleet of coding agents and want to know what runs without you
You searched for orchestration or a control plane for coding agents, and you want to know whether this runs over the agents and the continuous-integration system you already have. Assay by Medici is an agent-operated delivery pipeline with a human-governance layer. It is not a harness and does not replace yours: it sits under whatever harness you run and under your own CI, separating the identity that writes a change from the identity that verifies it. Between gates it runs unattended; the merge and every risk gate wait for you.
Your path
-
The methodology
What the pipeline does and what it refuses to do.
-
How it installs
Under your harness and CI.
-
The live board
The proof it is operated and not merely described: the house's own fleet, dozens of parallel agent sessions under one accountable human.
You lead the team, and a platform engineer will install it
You own throughput and the decision of what is safe to leave unattended, and you want to know who decides what once agents are writing the changes. Your existing controls assume a human wrote the change and a different human reviewed it. An agent breaks that assumption, and Assay restores it: the author identity and the reviewing identity are different accounts, and that separation is enforced by the code host, not by convention.
Your path
-
The methodology
How the author, the reviewer, and the verifier are kept separate, and the section on what it does not claim.
-
The install page and GitHub Apps
The setup cost in full.
-
The verification step
The proof: a non-implementer re-runs the checks and the evidence rows carry who ran them and when, and the append-only registers (the record files) where a deleted row turns the build red.
You are one person with one repository
You searched for how to verify what your agent did, on a project that is just you. You are in scope, through the one-person path rather than the full multi-account setup. The nine-App, two-account arrangement is built for an organisation that needs separated identities across a team; for a solo builder it is the wrong size, and no page here pretends otherwise.
Your path
-
Tiering
The free tier and the solo cockpit.
-
The generated status board and work orders
The tools you run day to day (we call the work orders briefs).
-
The loop itself
The proof: it holds for one person the same way it holds for a fleet.
You check someone else's agents without installing anything
You searched for an audit trail, attestation, or evidence for agent work, and you are here to verify rather than to adopt. You are the one reader for whom setup cost is irrelevant and evidence is everything. The state of that evidence today: there are no external customer deployments, and every operational figure comes from the house's own fleet, labelled as such. That single self-reference is what there is, and it is checkable, which a logo wall the reader cannot verify is not.
Your path
-
The live board
The house's own flow, dwell times and all.
-
The methodology
The exact claim and the residual gap.
-
The registers
How tampering is made visible. The proof that ends this path is that everything you just read is something you checked yourself, without installing anything.