reference · comparison · the question every visitor arrives with
Why not the CI and code owners I already have?
It is the fair question, and a reader who does not get an answer supplies their own, usually "no reason". So here is the answer: what your existing setup already gives you, what an agent-tracing tool gives you, and the part that is left over. Assay is only the part that is left over.
What a CI-plus-code-owners setup already gives you
A great deal, and precision matters here. A code-ownership file requests the right reviewer automatically: in the forge's own words, Code owners are automatically requested for review when someone opens a pull request that modifies code that they own
. Branch protection then makes that review and your test suite conditions of merging: You can require approving reviews from people with write permissions in the repository or from a designated code owner
, and all required status checks must pass before collaborators can merge changes into the protected branch
.
So if your question is "can I require a review and a green build before code merges", the answer is that you already can, and you should. Assay does not add that. It assumes it.
What an agent-observability or tracing tool gives you
The other thing a team running agents reaches for is visibility inside the run. The tracing category is now standardised: the OpenTelemetry generative-AI semantic conventions define, in their own words, spans, metrics, and events for GenAI clients
: step-level telemetry for what the model and the tools around it did, what it cost, how long it took, and a replayable trajectory of the run.
What is left over, and that is the part Assay does
Put those two together and a specific list is still uncovered. None of it is a gap the forge or the tracer was failing at; each is simply not the thing they are for. The residue is:
- A definition of done attached to the change before the work starts. The required check proves a build is green; it does not carry what this particular change was supposed to satisfy. Assay's unit of work carries that, as executable checks, written before an agent touches the code.
- A verification step run by a party that did not implement it. A required review reads the diff; it does not re-run the change's own acceptance checks on the merged result. Assay makes that a distinct, non-author step, and records who ran it and when.
- An append-only record where withdrawal is a tombstone, not a deletion. A merged pull request is a point in history; it is not a running ledger whose every removal is a detected event. Assay's registers are, and a deleted row turns the build red.
- The human decision expressed as a forge event rather than a convention. "A person must approve this class of change" is, in most shops, a habit. Assay derives that gate from recorded risk answers and makes it a condition, not a courtesy.
That is the whole of it. If you already have the review and the required check, Assay is these four things layered on top, and nothing you have to tear out to get them.
A note on what you will not find here
There is no chart on this page claiming Assay is some multiple faster, cheaper, or better than an alternative, and there is none claiming an alternative falls short of Assay by some percentage. That is deliberate. The same bar that stops us publishing a productivity number about ourselves stops us publishing a comparative one about anyone else: a number you cannot recompute against a stated baseline is a claim wearing a measurement's clothes. Every factual statement about another tool on this page is a quotation from that tool's own documentation, linked below, dated at the time of writing. Where a claim could not be sourced that way, it was dropped rather than dressed up.