Hi — I'm working on OM World, a protocol for a decentralized intent economy. JECP's framing — Joint Execution Capability Protocol — suggests something distinct from the usual single-agent execution model: multiple agents coordinating around shared capability. That's exactly the shape we keep hitting in our Tool Registry and Execution Proof work. Three design questions.
1. Capability vs commerce coupling
The C in JECP is both Capability and Commerce. In your spec, are these inseparable (every capability has a commerce dimension; even free capabilities have a zero-priced commercial declaration) or independently composable (you can have capability-only invocations and commerce-only flows)? Our spec tries to keep tool-registry (capability) and any commerce layer cleanly decoupled, but I'm curious whether the JECP decision was forced by some experience that pulled them back together.
2. Joint execution failure recovery
In single-agent execution, failure is the agent's responsibility. In joint execution, failure has more shapes — partial-completion (agent A did its part, agent B failed), divergent-output (both agents executed but produced inconsistent outputs), or coordination-failure (the agents never reached agreement on what to execute). What's JECP's discipline — is recovery declared at intent issuance ("if joint fails, fall back to single"), at coordination time (agents negotiate compensation), or post-hoc (dispute resolution)?
3. Registry discoverability of "jointness"
When an agent looks up a capability in the registry, does it learn the capability is joint (requires multi-agent coordination) before invoking, or does "jointness" surface at runtime? The former simplifies planner reasoning; the latter is what most multi-agent systems do today because joint orchestration is implicit. We have an operation_class field in our registry entries (read | write | destructive | admin) — wondering if joint belongs as another axis or as a separate field entirely.
Happy to share the OM World spec — and the JECP-CLI work suggests you're operationally close to running this rather than just speccing it.
Hi — I'm working on OM World, a protocol for a decentralized intent economy. JECP's framing — Joint Execution Capability Protocol — suggests something distinct from the usual single-agent execution model: multiple agents coordinating around shared capability. That's exactly the shape we keep hitting in our Tool Registry and Execution Proof work. Three design questions.
1. Capability vs commerce coupling
The C in JECP is both Capability and Commerce. In your spec, are these inseparable (every capability has a commerce dimension; even free capabilities have a zero-priced commercial declaration) or independently composable (you can have capability-only invocations and commerce-only flows)? Our spec tries to keep tool-registry (capability) and any commerce layer cleanly decoupled, but I'm curious whether the JECP decision was forced by some experience that pulled them back together.
2. Joint execution failure recovery
In single-agent execution, failure is the agent's responsibility. In joint execution, failure has more shapes — partial-completion (agent A did its part, agent B failed), divergent-output (both agents executed but produced inconsistent outputs), or coordination-failure (the agents never reached agreement on what to execute). What's JECP's discipline — is recovery declared at intent issuance ("if joint fails, fall back to single"), at coordination time (agents negotiate compensation), or post-hoc (dispute resolution)?
3. Registry discoverability of "jointness"
When an agent looks up a capability in the registry, does it learn the capability is joint (requires multi-agent coordination) before invoking, or does "jointness" surface at runtime? The former simplifies planner reasoning; the latter is what most multi-agent systems do today because joint orchestration is implicit. We have an
operation_classfield in our registry entries (read|write|destructive|admin) — wondering ifjointbelongs as another axis or as a separate field entirely.Happy to share the OM World spec — and the JECP-CLI work suggests you're operationally close to running this rather than just speccing it.