Biggest remaining risks to serious adoption of Traverse (post-v0.10)

[enricopiovesan]

Context

v0.10.0 delivered meaningful progress on governed composition, durable traces, browser-hosted execution, cross-host fixtures, stricter publish gates, and honest demo labeling. The architecture is stronger.

This discussion captures the highest-priority remaining risks that still stand between “strong foundation” and “something a risk-averse engineering team will seriously consider adopting.”

Library density / chicken-and-egg is deliberately excluded — it is real but secondary to the risks below.

The goal is the same as earlier discussions: surface concrete gaps with clear closing criteria so they can be tracked, prioritized, or consciously deferred.

---

1. Cross-host behavioral identity is still not publicly proven

Risk
The core value proposition is: same capability binary → contract-identical behavior across hosts. Until this is demonstrated publicly and reproducibly, skeptical teams will treat the claim as aspirational.

Current state
Bounded native WASI profile, native cross-host fixture evidence, CLI fixture runner in CI, and a governed hello-world fixture corpus with comparison contract exist. This is necessary infrastructure, not yet the public proof.

What would close the gap

• Same WASM artifact + same contract version executed in at least: browser, Node/CLI, and one native host (e.g. Swift), ideally one additional target (edge or cloud function).
• Public, reproducible comparison of outputs and full execution traces.
• Explicit written policy defining what “identical” means (bit-identical vs contract-identical under allowed non-determinism such as clocks, randomness, or host-specific resource limits).
• Artifacts and comparison results that any third party can re-run.

Until this exists, the “run anywhere” claim remains the single largest credibility risk for serious adoption.

---

2. Authoring friction and the Rust / skill-path tension

Risk
Most organizations will not rewrite business logic in Rust solely to obtain portability and traces. If the primary authoring path remains Rust-centric, adoption stays limited to teams already comfortable with that stack.

Current state
Official authoring still requires Rust. Claude skills (traverse-capability-author and related) exist and aim to interview → contract → ABI-compliant WASM → human-reviewed PR. The path is real but not yet proven as first-class.

What would close the gap

• Published data (or at least qualitative reports) on success rate, correctness, security, and ABI compliance of skill-generated capabilities.
• Clear residual skill required of the human reviewer — can a non-Rust person meaningfully approve, or is deep Rust expertise still mandatory?
• Explicit product stance: is “author by description + review” a supported primary path, or still experimental?
• Guidance on which classes of capability are safe for pure LMM generation versus which still require human Rust expertise.
• Measured cycle time from intent to reviewed, publishable capability for a representative set of small and medium capabilities.

Without a credible non-Rust (or skill-primary) path with known economics, the practical authoring surface remains too narrow.

---

3. Governance cost vs. perceived benefit for small / medium changes

Risk
Immutable contracts, registry PRs, CI gates, risk metadata, and fail-closed use-case surface coverage are excellent for high-stakes or shared capabilities. They become a liability when a team needs to ship a small internal change quickly.

If the private / app-scoped path is not dramatically lighter than the public governed path, teams will route around the system for anything that is not obviously reusable. Once that happens, the “everything runs under the same contract model” advantage erodes inside the organization.

What would close the gap

• Honest data (or qualitative reports) on time-to-publish for small vs complex capabilities.
• Clear, documented escape hatches or private/app-scoped publication paths that stay lightweight while still producing traces and respecting placement/permission constraints.
• Explicit criteria for when full governance overhead is justified versus when it should be relaxed.
• Evidence that the private path does not become a second, divergent runtime model.

---

4. Composition still requires non-trivial host glue in real systems

Risk
A rich catalogue of atomic capabilities only delivers transformative value if non-trivial workflows can be assembled mostly by wiring published capabilities rather than by writing a large custom orchestration / policy layer.

Current state
v0.10 added a declarative workflow planner (schema-shape compatibility), MCP proposal lifecycle (propose → schedule with bounded parallelism → export/promote under governance), and durable orchestration with checkpoint/recovery. This is a major step. It is not yet proven at the level of real multi-step business workflows.

What would close the gap

• At least one non-trivial reference workflow (retries, compensation, partial failure, multi-capability transactions or sagas) implemented with minimal custom glue.
• Metrics or qualitative evidence showing the ratio of pure capability composition versus host-specific or one-off code.
• Runtime or pattern support for the common failure and recovery shapes so each application does not reinvent them.
• Clear guidance on where the boundary sits between “capability wiring” and “still needs host orchestration.”

---

5. Operational and performance unknowns under real load

Risk
WASM near-native performance is plausible for many business-logic workloads. Continuous or high-throughput domains still lack public numbers and clear operational stories.

What would close the gap

• Benchmarks for realistic workloads (not only micro-benchmarks), covering latency and memory overhead of contract validation + placement.
• Clear stories for storage, retention, back-pressure, and recovery when capabilities are interrupted.
• Guidance on when a local companion service is required versus pure browser / WASM.
• Public data that lets a team answer “will this be acceptable under our load profile?” without having to instrument the runtime themselves.

---

6. Agent reliability and recoverable failure modes

Risk
MCP exposure and machine-readable contracts are a strong foundation. The open question is whether agents can discover, reason about, compose, and respect placement/policy constraints without large custom system prompts that re-describe the whole system, and whether failures are quickly diagnosable and recoverable via traces.

What would close the gap

• Demonstrations of agents composing multi-capability workflows primarily from contracts and traces.
• Measurement of how much additional prompt context is still required.
• Documented failure modes when an agent proposes an invalid composition or violates a placement constraint, and evidence that the runtime + traces make these recoverable without deep runtime expertise.
• Clear distinction between “agent can invoke” and “agent can productively compose and recover.”

---

Suggested prioritization for closing these risks

Highest leverage for serious adoption right now:

1. Public multi-host behavioral identity evidence (Risk 1).
2. Measured, credible non-Rust / skill-primary authoring path (Risk 2).

These two currently create the largest gap between “interesting architecture” and “something a risk-averse team will bet on.” The others remain important but secondary once identity and authoring are credible.

Happy to refine any of these into separate tracked issues with acceptance criteria, or to adjust the framing if the team already has work in flight that addresses parts of them.