Checking an agent against the specification
Conformance to the Common Agent Specification is checked by programs. Each check passes or fails on its own, and none of them adds up to a score.
Section 14
What the specification says about conformance
This is the text of Section 14, reproduced from the specification.
The floor is checked mechanically, and a conforming deployment ships the checker: a program that asks Section 4's exchanges of an agent and treats silence as failure, because absence of an error is not evidence of permission. The interview of Section 4.3 is the template. Descriptor checking is Section 6.8's; AgentDoc checking is Section 9.10's. Attribute claims are checked by fetching their artifacts. Behavioral conformance to interfaces and roles is the evaluator's territory, and its verdicts are Section 8.4 records.
Byte-exact obligations are pinned by conformance fixtures, under the family's fixture doctrine: the fixture is the authority, and when an implementation disagrees with it, the implementation is what changes; every case is checkable without a network or a clock, cases whose verdict depends on time carrying their own now; and a fixture contains cases that MUST be accepted as well as cases that MUST be refused, because a fixture of refusals alone is passed by an implementation that refuses everything. Fixture identities are test vectors and control nothing.
Nothing in this section produces a score.
The checks
One mechanical check for each kind of claim
Each chapter that defines a document or an exchange also says how a program checks it. None of these checks asks whether the agent is any good. That question belongs to an evaluator, whose verdict is a signed record of its own (Section 8.4).
| Check | What a program verifies | Where |
|---|---|---|
| The interview | It asks the five questions, verifies each answer against the signed bytes it comes from, asks questions outside the agent's offerings and expects the standard refusals. | Section 4.3 |
| Checking a Descriptor | The required members are present, every kind is a media type or a defined value kind, no member carries an address, credential or endpoint, and a bound Descriptor's signature verifies against its subject. | Section 6.8 |
| Checking an AgentDoc | Every section cites sources the document lists, every source can be fetched and matches its digest, every fact appears in a cited source, and nothing left unstated has been given a default. | Section 9.10 |
| Checking a package | The layout, the manifest against its pinned schema, the draft Descriptor, the install file, the absence of credential values, and one skill for each offering. | Section 12.10 |
| Checking a repository | The manifest and every path it names, the package inside it, a package AgentDoc that regenerates byte for byte, and the lineage of each copy. | Section 13.9 |
Fixtures
Fixtures pin the byte-exact parts
A fixture is a file of test cases that an implementation must agree with. When an implementation disagrees with a fixture, the implementation is what changes. Every case can be checked without a network or a clock, and each fixture holds cases that must be accepted beside cases that must be refused.
- Trials (Section 7.7, with the trial scope of
the allowance in Section 7.5 and the refusals of Section 4.7). The fixture says which
trial declarations a registry refuses, the order of admission and its first-failure
answer, the fields of a
TRIAL_REFUSEDrefusal, what a node measures at admission, and that only admitted trials are counted. It is published as conformance/trial.json in the specification's repository, and the Agent Messaging Server repository carries the same cases.
A binding pins the byte-level constants this specification leaves symbolic, such as fence text and freshness windows, in its own conformance fixtures. The fixtures for Agent Messaging are described at agentmessaging.ai.