Hi — I'm working on OM World, a protocol for a decentralized intent economy. AgentCard's framing — standardized identity & capability schema for AI agents with a Rust reference implementation — sits exactly where our Tool Registry primitive needs to plug in.
1. Schema minimality vs extensibility. A schema for identity + capability has to balance — minimal core (works everywhere, forces extensions for real use) vs rich core (covers more use cases, harder to interop with). Where did you draw the line, and what made the deciding cases?
2. Identity vs capability separation in the schema. Are identity and capability one schema (single document covers both) or two separate but linked schemas (identity references capability sets)? Each affects how an agent updates one without invalidating the other.
3. Rust reference implementation as normative. Shipping a Rust reference alongside a spec is one way to handle ambiguity ("what the implementation does" becomes the answer). Is the Rust impl normative (other implementations must match), illustrative (other implementations may differ in unobservable details), or both depending on the spec section?
Happy to share OM World's Tool Registry spec. Reference-implementation-as-spec is a real pattern; your discipline would inform whether OM World should ship one alongside its v0.2 freeze.
Hi — I'm working on OM World, a protocol for a decentralized intent economy. AgentCard's framing — standardized identity & capability schema for AI agents with a Rust reference implementation — sits exactly where our Tool Registry primitive needs to plug in.
1. Schema minimality vs extensibility. A schema for identity + capability has to balance — minimal core (works everywhere, forces extensions for real use) vs rich core (covers more use cases, harder to interop with). Where did you draw the line, and what made the deciding cases?
2. Identity vs capability separation in the schema. Are identity and capability one schema (single document covers both) or two separate but linked schemas (identity references capability sets)? Each affects how an agent updates one without invalidating the other.
3. Rust reference implementation as normative. Shipping a Rust reference alongside a spec is one way to handle ambiguity ("what the implementation does" becomes the answer). Is the Rust impl normative (other implementations must match), illustrative (other implementations may differ in unobservable details), or both depending on the spec section?
Happy to share OM World's Tool Registry spec. Reference-implementation-as-spec is a real pattern; your discipline would inform whether OM World should ship one alongside its v0.2 freeze.