[FEATURE] Allow visitors to interact with each agent

[edenreich]

Summary

Make the registry interactive: visitors should be able to open an agent's
card and chat with the live deployed instance from the browser.
Authenticated flows (OAuth 2.0 / OIDC) gate access where the agent declares
a security scheme; an SLA / health signal on each card communicates whether
the agent is reachable before the visitor commits to a session.

Today the registry is a read-only catalog browser. Adding interaction turns
it from a discovery surface into a try-before-you-host surface.

Motivation

• Visitors currently have to clone, configure, and run an agent locally to
  evaluate it. Interactive chat collapses that to one click.
• Agent authors lose conversions because their card looks like
  documentation, not a product.
• A health / SLA pill makes "this agent is alive" legible without reading
  the source repo.

Scope (proposed)

• Opt-in interactive: true flag per catalog entry. Only opted-in agents
  get the chat affordance; everything else renders as today.
• HTTPS-only everywhere. Agent endpoints, OAuth redirect URIs, and
  artifact URLs must all be https://. Non-HTTPS interactive agents are
  rejected at catalog-aggregation time; non-HTTPS artifact URLs returned
  at runtime are not rendered. The registry itself is served over HTTPS
  (GitHub Pages), and mixed content would break the chat anyway - we
  enforce it explicitly so the failure mode is a clear error instead of a
  silent browser block.
• Chat UI: full-page route (/agents/<name>/chat) reached by clicking the
  card's primary action. Anonymous session by default; OAuth-gated when the
  agent's A2A card declares a security scheme we support.
• Health gate: before mounting the chat, probe the agent's
  /.well-known/agent.json (or equivalent). If unreachable, render a
  disabled state ("Agent is currently not available").
• SLA / status badge on the card: rolling availability % over a fixed
  window (e.g. last 24h), sourced from a scheduled cron rather than the
  visitor's browser.
• OAuth 2.0 / OIDC (PKCE, public client) with a curated provider allowlist
  maintained in this repo. Self-hosted Keycloak / Authentik intentionally
  excluded in v1 - misconfigured authorization servers are a phishing risk
  to visitors.
• Session ID generated client-side per chat and used as the A2A
  contextId so the agent can correlate turns.
• Artifacts presentation per session: A2A artifacts are stored on the
  agent side; the agent returns URLs in its responses. The chat view
  renders these per-session (list + download / inline preview where the
  media type is safe). The registry stores no artifact bytes. Client-side
  per-visitor session list is capped at 5 active sessions (LRU
  eviction of the oldest session ID); the per-artifact / per-session
  size contract is the agent's responsibility - we document the
  expected contract for interactive agents and surface whatever quota
  state the agent exposes.

Non-goals

• Not a hosted chat platform. We are not running the agents - the agent
  owner does.
• Not multi-turn workflow building, MCP tooling, or file uploads in v1.
• Not a replacement for infer agents add <name> for serious evaluation.
• Not a way to bypass the agent owner's own auth / billing / quotas - we
  forward the visitor's token; the agent enforces.
• Not an artifact store. Artifacts live on the agent and are referenced
  by URL; the registry only renders them. Visitors should download
  anything they want to keep - the agent may GC artifacts on its own
  retention schedule.

Open architectural questions (resolve before Phase 1)

1. Transport. The registry is a static site on GitHub Pages with no
   backend. Three options for how the browser reaches the agent:

   • (a) Browser → agent directly. Requires CORS on every interactive
     agent. Cheapest, but constrains who can opt in.
   • (b) Edge proxy (Cloudflare Worker / Vercel Edge). Adds infra, but
     enables real rate limiting, header scrubbing, and a centralized OAuth
     callback.
   • (c) Visitor-supplied inference-gateway URL. Punts the problem to
     the visitor; usable for power users only.

2. Where does the interactive flag live?

   • In inference-gateway/agents/agents.yaml per entry (registry-curated;
     no ADL change).
   • In the agent's own agent.yaml ADL spec (agent-author opt-in;
     requires inference-gateway/adl schema bump + regen here and across
     SDKs).
   • In this repo as a separate policy file.

   The OIDC allowlist clearly belongs in this repo. The interactive
   flag's home is the open question - agents.yaml keeps it out of the
   ADL surface; ADL puts the author in control.

3. OAuth client registration. Each allowlisted IdP requires a
   registered OAuth public client. Do we (the registry) own one client per
   provider - simpler, but the consent screen says "Inference Gateway
   Registry" regardless of which agent - or does each agent author
   register their own and pass client_id via the agent card (more
   accurate consent, more author work)? Affects the trust model.

4. SLA data source. Cron-driven pings published as status.json in
   inference-gateway/agents alongside catalog.json is the most
   consistent with the existing aggregator pattern. Alternatives: external
   monitoring (UptimeRobot etc.), or agent-self-reported via a status
   endpoint. Pick one before designing the badge.

5. Rate limiting reality. Without a backend, browser-side limits are
   trivially bypassable. v1 honest answer: rely on the agent's own rate
   limiting + the OAuth provider's quotas. An edge proxy (option 1b) is
   the only way to enforce limits at the registry layer.

6. Artifact URL trust. All artifact URLs must be HTTPS (hard
   requirement, see Scope). Open question is which HTTPS URLs we'll
   render: every URL the agent hands us, or restrict to same-origin-as-
   agent (or an agent-declared allowlist) to limit exfiltration /
   phishing surface? Affects how aggressive we can be with inline
   previews vs. plain download links.

Proposed phasing

Each phase should ship as its own PR (and likely its own follow-up issue
linked back here).

• Phase 0 - Architecture decision record. Resolve open questions 1–4.
  Output: a short ADR committed to this repo. No code.
• Phase 1 - Anonymous chat for healthy, CORS-enabled, no-auth agents.
  interactive flag plumbing, chat route, health gate, session ID.
• Phase 2 - SLA / health badge on the card, fed by the chosen data
  source.
• Phase 3 - OAuth 2.0 / OIDC (PKCE) with provider allowlist. Token in
  sessionStorage, refresh-on-401, no localStorage.
• Phase 4 - Rate limiting (likely requires the edge proxy from Q1b)
  and abuse hardening.
• Phase 5 - Artifacts presentation: render agent-supplied artifact
  URLs per session with safe inline previews where the media type allows,
  download links otherwise. Per-visitor session list capped at 5 with LRU
  eviction. URL trust policy per Q6.

Cross-repo impact

• inference-gateway/agents - schema for agents.yaml gains interactive
  (if Q2 resolves that way); aggregator enforces HTTPS for any flagged
  entry at build time; aggregator publishes status.json for Phase 2.
• inference-gateway/adl - only if Q2 resolves toward the ADL spec
  carrying the flag; would require schema bump + npm run codegen here.
• inference-gateway/docs - [DOCS] follow-up ticket at PR time (this is
  a feat:); cover the interactive flow, the auth allowlist policy, and
  how an agent author opts in.

Acceptance Criteria

Phase 1 (minimum shippable):

• ADR merged covering open questions 1–4.
• interactive flag wired through from the chosen source of truth to
  CatalogAgent types and AgentCard.vue.
• Clicking an interactive agent's card opens /agents/<name>/chat
  with a fresh session ID (used as A2A contextId).
• Chat view performs a health probe on mount; disabled state with
  "Agent is currently not available" when the probe fails.
• HTTPS-only enforcement: catalog-aggregation step rejects any
  interactive entry whose agent endpoint is non-HTTPS; runtime
  defense-in-depth check in the chat view refuses to mount against a
  non-HTTPS URL.
• Non-interactive agents render exactly as today (no regression).
• <ClientOnly> wrapping so the SSR build stays green.
• How-to guide added under /how-to/ covering how an agent author
  opts in.
• No test framework exists in this repo; verification is manual via
  npm run dev against a known-healthy mock agent. If automated tests
  are required, introducing a runner is a separate decision and
  should be its own issue.

Phase 2 (SLA badge):

• Status data source live and refreshing on a schedule.
• Availability pill on interactive agent cards.
• Stale-data guardrail (badge hidden / greyed when data is older than
  a configurable threshold).

Phase 3 (OAuth / OIDC):

• Provider allowlist file in this repo with at least one well-known
  IdP wired end-to-end.
• PKCE flow; token in sessionStorage; refresh-on-401; no
  localStorage.
• Clear sign-in CTA when the agent's A2A card declares a security
  scheme matching an allowlisted provider; clear "auth not supported"
  state otherwise.
• Logout / revoke path.

Phase 4 (rate limiting):

• Mechanism chosen per Q1 / Q5 resolution.
• Documented limits visible on the chat view.

Phase 5 (artifacts presentation):

• Agent-supplied artifact URLs render in the chat view per session
  (list + safe inline preview for known media types, download link
  otherwise).
• HTTPS-only enforced at render time; non-HTTPS artifact URLs are
  dropped with a visible warning, not silently hidden.
• URL trust policy from Q6 implemented (render-all vs. same-origin
  vs. agent-declared allowlist).
• Per-visitor client-side session list capped at 5 active session
  IDs with LRU eviction; sixth session evicts the oldest from the
  visitor's "my recent sessions" surface. The agent owns artifact
  retention beyond that.
• How-to documents the expected agent contract: HTTPS URLs,
  recommended retention behavior, and the safe-preview media types
  the chat view supports.