Our provider qualification routine found a reassuring-looking set of updates at the start of October.
Claude ACP had a newer version. Grok had a higher version in the ACP Registry. Codex had moved to a new major. Agy and Cursor both had newer candidates.
If the job were dependency maintenance, the obvious output would have been a list of version bumps.
Instead, most of them stayed where they were.
That is because a version number answers surprisingly little of what Agent Bridge needs to know before a runtime becomes part of a release.
Grok was newer in the wrong sense
The most illustrative case was Grok.
The ACP Registry showed a 1.0.49 candidate while our release lock was on 1.0.46.
At first, that looks like ordinary lag.
Then we checked the authoritative npm channel. Its latest dist-tag still resolved to 1.0.46.
So what did 1.0.49 mean?
It certainly existed. We had also already found packaging behaviour in that candidate that differed from the self-contained runtime shape our release expects.
What we did not have was evidence that 1.0.49 was the stable release we should follow.
We recorded it as a release-channel mismatch and kept 1.0.46.
The highest semver was not the answer because version order and release-channel intent were answering different questions.
Agy and Cursor existed without the integrity metadata we expected
Agy and Cursor exposed another assumption.
Their Registry candidates pointed to exact archives, but the entries did not include the SHA-256 metadata our installers normally use to independently verify the bytes before staging them.
Our first conclusion was to hold both candidates.
That was the safe outcome, but it exposed a weakness in the qualification process. If upstream simply does not publish integrity metadata in that field, we would rediscover the same "missing checksum" surprise every week.
The better distinction is between release provenance and qualification provenance.
For qualification, we can resolve the exact vendor URL in an isolated download, hash the exact bytes ourselves, pin that hash for the qualification attempt and then feed those pinned bytes through the normal installer.
That lets us test a candidate without pretending upstream supplied metadata it did not.
It does not automatically make the candidate releasable.
Agy 1.3.0 staged and reported the expected build label, then failed to produce a usable ACP protocol response in qualification. It stayed unpromoted.
Cursor's candidate was also isolated-download pinned and staged, but it did not reach the required live qualification in that round. It stayed unpromoted too.
We learned more without lowering the release gate.
Codex was held because the number mattered too much
Codex had almost the opposite problem.
The candidate was 2.1.1, a major-version change.
We already had an explicit steering contract around Codex and a separate issue responsible for qualifying that change. Weekly update automation was not allowed to silently turn a major runtime boundary into routine dependency churn.
So we did not stage and "see what happens".
The major version triggered a different owner and a different qualification path.
Again, the version number mattered. It just did not mean "upgrade".
Claude was the boring success
Claude is useful here because one candidate did follow the happy path.
The exact version was selected. The provider qualification passed the relevant behaviours. Exact-head CI and resource checks passed. The release lock was updated.
That is what promotion looks like when the evidence lines up.
The contrast with the held candidates is the important part.
Our release state is not intended to mirror every upstream registry as quickly as possible. It is a record of exact runtimes we are willing to make part of Agent Bridge's supported execution path.
Freshness matters. Reproducibility and behaviour matter more.
I now think of a release as a tuple
Not literally in the database, but conceptually.
A usable runtime release needs at least:
an upstream identity, a release-channel interpretation, exact bytes or a verifiable way to obtain them, a local release lock, and current evidence that those bytes satisfy the behaviour we rely on.
If one of those is missing, "version 1.3.0 exists" is still useful information.
It just is not a release decision.
This has also made our weekly qualification routine more valuable. Its job is not "upgrade everything". Its job is to discover what changed, identify which candidates are actually comparable to our current stable channel, qualify what can safely be qualified, and leave explicit holds where the evidence is incomplete.
A hold is a result.
What I am watching next
Provider distribution is still inconsistent.
Some projects publish strong manifests and checksums. Some rely on package registries. Some expose vendor archives. Some have several channels whose relationship is not obvious from the version string.
I do not want Agent Bridge to invent a universal software-supply-chain system around all of them.
I do want the qualification process to stop confusing absence of one particular metadata field with absence of any safe way to investigate a candidate.
The release gate can stay strict while the investigation path gets smarter.
The thing I am trying to remember is simple:
A version tells us what something calls itself. A release is the decision to trust exact bytes for a particular job.
There is a fair amount of evidence between those two statements.