Hermes Agent connector changelog

Use this page to decide whether a Hermes Agent connector change requires a new artifact, admission record, provider qualification, migration, or caller update. It records only changes established from the reviewed source range.

Release status: the reviewed snapshot is not a tagged release. The reviewed repository tags 034a5206 as v1.0.0; the documentation revision is five commits later and still declares workspace version 1.0.0. Use the full source and artifact identities to distinguish these states.

Identify the exact version

An operator record for the reviewed snapshot needs the full source commit, tree state, immutable host image, manifest digest, connector version ID, release ID, and Hermes artifact. A tag or 1.0.0 image label cannot replace that tuple.

Reviewed source snapshot

The entries below describe Hermes-relevant differences between v1.0.0 and 97be86e9. They are source changes, not proof that an artifact was built, published, deployed, or qualified.

Added

• A dedicated aip-host-hermes-agent binary and common standalone-host image path.
• Registry admission, tenant-scoped routing, replica leases, health, drain, and recovery integration in the connector-fleet topology.
• An exact Hermes upstream revision in manifest compatibility metadata.
• Eight endpoint-qualified scheduled-job operations.
• Product-image and controlled-fleet qualification procedures for the Hermes host.
• Job-route tests for path IDs, list queries, body partitioning, capability classification, approval, risk, and idempotency metadata.

The added operations are:

Job identifiers are exactly 12 lowercase hexadecimal characters. The connector places the identifier in the path and does not forward job_id or the AIP idempotency key in an update body.

Changed

Seven existing session-management operations change from CapabilityKind::Resource to CapabilityKind::Tool:

• sessions_list;
• session_create;
• session_get;
• session_patch;
• session_delete;
• session_messages;
• session_fork.

Their capability IDs and provider routes do not change in this source range. The classification change makes every published Hermes API operation action-routable. The current manifest test rejects any remaining CapabilityKind::Resource entry.

The production delegated-result resolver also gains a constructor that accepts only the Action queue and lifecycle store. The standalone host uses that constructor instead of receiving the complete central runtime.

Security and isolation boundary

The standalone host makes these ownership rules deployable:

• every endpoint descriptor must match the host tenant;
• endpoint credentials are read from bounded owner-controlled files;
• an omitted operator-policy file leaves first-class delegation disabled;
• the host installs durable approval, profile-state, Action, and lifecycle stores from its own runtime database;
• registry identity, artifact digest, manifest, credential revision, and endpoint set are fixed outside Action input.

These controls describe the reviewed standalone topology. They do not qualify an arbitrary deployment or change the trust requirements of native AIP.

Deprecated, removed, or renamed

No Hermes capability ID from the 27-operation v1.0.0 baseline is removed or renamed in the reviewed range. The source defines no connector-specific deprecation or removal date.

The session kind correction can still affect callers that cached capability metadata or projected Resource entries differently. Treat it as a contract metadata migration even though the capability IDs remain stable.

Apply the required migration

Stabilize the standalone topology before adopting the added job family. A process migration, capability expansion, and provider upgrade need separate evidence and rollback decisions.

Retain the compatibility pins

The reviewed snapshot selects these values in source:

The upstream commit identifies reviewed source, not a built Hermes image or model route. Changing either deployment without changing connector source does not establish compatibility with the new artifact.

Decide when a new connector version is required

Create and admit a new immutable connector version when a change affects any of these properties:

• capability IDs, kinds, schemas, risk, approval, retry, streaming, or idempotency semantics;
• provider method, path, query, request body, response, or SSE event mapping;
• endpoint normalization, tenant binding, credential scope, redirect policy, or secret resolution;
• operator binding, delegated identity, approval generation, cancellation, or result integrity;
• artifact bytes, dependencies, manifest digest, upstream baseline, host lifecycle, or effective endpoint capacity.

A documentation clarification alone does not require a connector version. It still needs the source revision that proves the corrected statement.

Record future entries completely

Each future entry should state:

1. release or explicit unreleased status and UTC review date;
2. full AIP source commit, tree, and clean or reconstructable dirty state;
3. connector, image, manifest, catalogue, release, Hermes, and model-route identities;
4. added, changed, fixed, security-relevant, deprecated, and removed surfaces;
5. caller, operator, storage, endpoint, credential, and provider migrations;
6. rollback and compatibility boundary;
7. exact deterministic, image, fleet, path, and live qualification result, or not_run;
8. deprecation introduction, replacement, and removal date only when source or release policy defines them.

Do not backfill release history from filenames, mutable tags, or source presence. Mark unknown history as unknown.

Related documentation

• AIP release notes
• Migrate bundled connectors to the fleet
• Hermes scheduled jobs
• Hermes configuration
• Qualify the Hermes Agent connector
• Connector upstream baselines