/discover demo: clarify agent vs. heuristic, and track path to real in-browser Traverse + WASM model selection

[enricopiovesan]

The /discover page is a useful public signal that the capability registry is live and growing. The hero copy and visual treatment currently overstate what the page does relative to a real agent + runtime loop. This issue asks for clearer labeling of the current demo, documents the gaps, and tracks the stronger version the team has described (real Traverse instance in the browser with a WASM AI model selecting capabilities at runtime).
No prior context assumed — everything below is based on the public page and the stated direction.

Current behavior of /discover (as of observation)
What is real

The page fetches live registry data (catalog.json / equivalent).
Counts such as published versions, active capabilities, and namespaces reflect the live catalog.
Capability cards link to real published contracts (e.g. core.normalize-participants@1.1.0).
The page is static (Astro, no backend) and re-queries the registry on “Discover another workflow”.

What is simulated / heuristic

There is no hosted LLM and no MCP agent loop on the page.
Composition is a client-side heuristic: group active capabilities by namespace, then order namespaces that have 2+ capabilities into a pipeline (ingest → interpret → decide → act) using a simple verb heuristic on capability names.
The graph animation (idle → running → completed) is a browser-side simulation of execution order.
No real WASM capability binaries are invoked.
The page’s own “How this is actually built” section states this clearly, including lines such as:
“That’s the entire ‘agent’ — a composition heuristic running on live data, not a hosted model deciding anything.”
“that sequencing is simulated in the browser, not a real invocation of the WASM binaries.”
Terminal-style log output also records: “simulating execution order -- nothing here invokes the real WASM binaries”.

Tension with hero / primary messaging

Headline: “Watch an AI agent build a workflow out of real capabilities.”
Supporting copy: “This isn’t a mockup… Nothing on this page is precomputed or faked.”
Diagram labels include “AI Agent”, “MCP”, and “Runtime” as if an agent loop is active.

The fine print is accurate; the primary framing is ahead of the implementation. Visitors who only read the hero can reasonably conclude a live agent is selecting and running capabilities.

Why this matters

Trust in the registry story
The live catalog and real contracts are a genuine strength. Overstating the agent layer risks discounting the real part when people inspect the page.
Alignment with C-DAD / MCP claims
Traverse’s broader positioning emphasizes machine-readable contracts, MCP exposure, and AI agents that can discover and invoke governed capabilities with traces. /discover is currently the most visible public “agent” surface; the gap between framing and behavior is therefore high-impact.
Future demo quality
The team has indicated a planned upgrade: a real Traverse instance running in the browser, with a real WASM AI model selecting capabilities at runtime to complete a goal. Clear separation between the current heuristic demo and that future demo will make the upgrade more credible when it lands.

Requests / proposed changes
A. Short-term (current /discover page)

Align primary copy with actual behavior
Options (pick one or combine):
Soften the hero to something accurate, e.g. “Watch live registry capabilities composed into a pipeline” or “Explore real capabilities from the public registry.”
Keep “AI agent” language only if a clear, prominent disclaimer appears above the fold (not only in a lower “How this is actually built” section).
Explicitly label the current mode, e.g. “Demo mode: heuristic composition + simulated execution (live catalog).”

Make the simulation status unavoidable
Keep or surface the existing log lines (“simulating execution order…”, “nothing here invokes the real WASM binaries”) in a more visible place.
In the legend or state panel, distinguish “simulated step” from “real capability invocation.”

Preserve the good parts
Live catalog fetch.
Links to real contracts.
Ability to re-query and show different namespaces/pipelines.
Transparency section (it is already one of the more honest technical explanations on a marketing page).

B. Medium-term (planned real in-browser demo)
Track a distinct, stronger demo with explicit acceptance criteria so it does not get conflated with the current page.
Suggested target behavior

A real Traverse runtime instance loaded in the browser.
Real published WASM capability artifacts executed (not only animated).
A WASM-hosted (or at least browser-constrained) model that selects capabilities at runtime to satisfy a user goal, using the live registry/contracts.
Contract validation enforced before invocation (invalid inputs/permissions rejected).
Execution traces produced and inspectable in the UI.
Clear failure/replan behavior when a capability errors or is unavailable.

Suggested acceptance criteria for calling it a “real agent” demo

Goal → discovery → selection is performed by a model at runtime (not a fixed verb heuristic).
Selected capabilities are actually invoked as WASM; outputs come from the binaries.
Each invocation produces a trace artifact visible to the user.
Selection is constrained by contracts (schema, permissions, placement), not free-form name matching.
At least one non-trivial goal path that requires ordering multiple capabilities and handling a missing/failed step.
Page copy accurately describes what is live vs. still simulated (if anything remains simulated).

Open questions for the team

Will the model weights/inference run fully in-browser as WASM, or will selection still call a remote endpoint while only capabilities run locally?
Will MCP be in the loop on the public demo, or will the page talk to the runtime more directly?
How will you version or feature-flag the current heuristic demo vs. the real instance so both can coexist during transition?

Suggested issue outcomes

Copy and labeling updates on /discover so primary messaging matches current behavior.
A tracked milestone or linked issue for the real in-browser Traverse + WASM model selection demo, with the acceptance criteria above (or the team’s refined version).
Optional: a short public note (changelog, blog, or page banner) when the real demo replaces or sits beside the heuristic one, so visitors can tell the difference.

Closing
The live registry, real contracts, and willingness to document the heuristic in the technical section are already valuable. Tightening the framing on /discover protects that credibility and makes the promised real in-browser agent demo land more cleanly when it ships.
Happy to adjust acceptance criteria or split this into separate issues (copy fix vs. future demo tracking) if that is easier to work with.