Skip to content

A provider can contribute knowledge and tools, but not an assistant of its own #56

Description

@scotwells

What

A capability document contributes knowledge, tools and skills, and composition flattens every entitled service into one assistant — one persona, one prompt, one flat tool set, one step budget. A provider can give Patch material; it cannot give Patch behavior. spec.serviceAgentRef is required on every document and currently points at nothing.

Proposal: a provider registers an A2A agent it hosts itself, and Patch delegates to it. A new spec.agents[] on the capability document carries a name, a routing description, an agent-card URL (gateway-rewritten like MCP endpoints are today), a reviewed allow-list of card skill IDs, and a time/count budget. Composition registers one delegation tool per agent; only the description enters the prompt.

Why it matters

It finishes the distribution pitch: providers publish once and reach every entitled project — but with their own voice, their own procedures and their own model, instead of contributing paragraphs to somebody else's prompt. It also fixes context contention. A service with 20 tools and 40KB of docs currently crowds out every other entitled service; as a delegated agent it costs one line.

Success looks like

  • A provider registers an agent and an entitled project's next conversation can route to it — no redeploy.
  • The agent is reachable only through skills that passed review.
  • A provider outage degrades the turn, never fails it.

Decisions someone has to make

  • Whose model? A provider-hosted agent burns its own tokens, and usage aggregates one model per conversation today. Either providers route through the AI gateway (authoritative, constrains them) or they self-report usage (trivial, gameable). A flat per-delegation meter is nearly free and worth having either way.
  • Whose identity? Patch asserting projectName is simplest; minting a short-lived delegated token lets the provider run its own TokenReview/SAR — the same path Patch already runs. The second is most of the reason to host your own agent.
  • Pinned card or live card? Pinning the reviewed card is what makes review mean anything, and it means providers cannot ship agent changes without re-review.
  • Delegation-only, or user-addressable? Letting a user pick "the StreamCo agent" directly adds an entry point with its own entitlement checks and conversation storage.

Constraints and risks

  • Allow-list parity. MCP tools are enforced twice, in Patch and at the gateway. Delegation has to keep that — skillSelector.include checked against card skill IDs, and the catalog rewriting the card URL to a gateway route. Without it a provider can grow a skill after review and Patch will route to it.
  • Provider output is data. An agent's response needs the same provenance framing a loaded skill body gets; it informs an answer, it never instructs Patch.
  • Conversation state. Patch's contextId is not the provider's. Multi-turn delegation needs a durable per-(conversation, agent) mapping or the second turn forgets the first.

Size

Medium. The A2A library we already depend on ships both the client and the extension support this needs, and Patch already implements the server side of this exact contract. The work is the schema plus validation, a delegation tool in composition mirroring the per-turn MCP session lifecycle, the credential decision above, and catalog-side registration and review.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions