Ecosystem review / Agent Adapters
Agent Adapters: review and next steps
An adapter translates a provider runtime into Datazup execution contracts. Source support, package availability, monitoring depth and live qualification are separate properties that must be reported separately.
What the evidence supports
The current catalog implementation separately validates capability flags, product integration, runnable state and qualification receipts. Recent source history contains adapter packaging and usage corrections. This review did not execute live provider conformance.
Reevaluation: Reuse the existing catalog and package work. Do not label an adapter production-ready because it appears in the source catalog or can load locally.
The next useful outcome
A named adapter version on a named consumer passes isolation, cancellation, streaming, usage and supported recovery checks with a qualification receipt.
Separate workstream plan
AD-01 · Proposed / reuse existing work
Refresh the capability matrix
Read the current catalog and receipt set, including package and consumer bindings.
Acceptance: Support, monitor depth, runnable state and live qualification are independently visible.
AD-02 · Proposed / reuse existing work
Verify packaged candidates
Reuse the Pi, OpenCode, Cline, Crush and existing adapter dependency work.
Acceptance: Exact immutable artifacts resolve and pass their scoped package gates.
AD-03 · Proposed / reuse existing work
Accept runtime contracts
Test credential isolation, cancellation, streaming, usage and supported recovery for the pilot route.
Acceptance: Failure and accounting behavior match the advertised capabilities.
AD-04 · Proposed / reuse existing work
Qualify one additional route
Choose a demonstrated consumer need and qualify the next adapter on an actual named host.
Acceptance: A revision-bound receipt supports only the tested provider/consumer combination.
AD-05 · Proposed / reuse existing work
Adopt supported routes
Integrate qualified routes into Steward and the assistant, with measured fallback where supported.
Acceptance: Fallback preserves task identity, authority and accounting, and never masks an unqualified route.
Dependencies and sequence
Immutable package carriers, supported credentials supplied through existing secure routes, a named consumer and explicit live-provider grants.
Start with the first eligible unfinished task above, after checking its existing owner and admission. Later tasks depend on the preceding proof where applicable; this ordering does not override a current implementation plan.
Deferred work
Qualifying every provider simultaneously and unsupported fallback routes.
Evidence and updates
This article combines the supplied 8 November ecosystem review with selected current source and retained planning records. It is an editorial snapshot, not a live service census. Detailed revision bindings and task authority remain in Workspace Docs and private execution records. Publish subsequent accepted changes as linked engineering or release notes rather than silently rewriting this baseline.
Shared roadmap · All Agent Adapters articles · Explore all areas
