Non-http server agent

[Hendler]

I maintain JACS, an agent identity/provenance system that already has its own keys, signing, and trust model. We are evaluating how to interoperate with this draft without turning every agent runtime into a public web server.

Relevant sections:

• Meetings/feedback channels: https://www.w3.org/community/agentprotocol/2025/06/20/meetings-communication/
• Agent Identity / did:wba resolution example: https://w3c-cg.github.io/ai-agent-protocol/protocol.html
• Agent Discovery / /.well-known/agent-descriptions: https://w3c-cg.github.io/ai-agent-protocol/protocol.html

Problem

The current draft describes:

• did:wba documents resolving under a web origin such as https://agent.example.com/alice/did.json
• discovery under https://{domain}/.well-known/agent-descriptions
• agent descriptions hosted at stable public URLs

That works well for web-native agents, but many real implementations are libraries, CLIs, sidecars, workers, or local runtimes rather than public origin servers.

For those systems, the practical model is:

1. The agent runtime generates identity/discovery artifacts.
2. Another component publishes them under the controlling domain:
   • static hosting
   • CDN/object storage
   • reverse proxy
   • gateway
   • CI/CD publication step
   • sidecar service

Request

Please clarify in the draft that the protocol does not require the agent runtime itself to be the HTTP server for:

• DID documents
• agent description documents
• /.well-known/agent-descriptions

Proposed clarification

Something along these lines:

An implementation MAY generate DID documents and agent-description documents in one component and publish them through another component, provided the published resources remain under the controlling HTTPS origin and accurately reflect the agent’s current public identity and metadata.

Why this matters

This would make the protocol much easier to adopt for:

• existing non-web agent systems
• embedded runtimes
• air-gapped or controlled environments with publication gateways
• systems with separate runtime and hosting responsibilities

It would also help implementations like JACS, where the natural path is to export did.json and agent-description artifacts and let an existing web layer serve them.

Questions

1. Is delegated/static hosting already intended, but just not stated explicitly?
2. Should the draft say anything about freshness or publication timing when the runtime and the hosting layer are separate?
3. Would the group want a short non-normative example showing “runtime generates, gateway serves”?