Hi — I'm working on OM World, a protocol for a decentralized intent economy. We're specifying a Tool Registry primitive — what an agent can call to act on the world — and ATD is the closest existing system I've found that treats discovery + capability mapping as a first-class concern rather than as an afterthought inside an agent framework.
Three design questions where your experience would be valuable:
1. What's the minimum capability entry needed to invoke (not just find) a tool?
We're trying to specify a registry entry as: tool_id, version, provider, interface (typed input/output), boundary (local/relay/public), operation_class (read/write/destructive/admin), attestation_method, stateful (bool), plus pricing/SLA. What's in ATD's persistent registry that an agent loads before invoking a tool — typed I/O schemas, failure mode catalog, side-effect class, all of the above?
The reason for the question: discovery alone doesn't make a tool callable. We want the registry to carry enough that an agent can invoke correctly without re-running discovery per call, which is the wasteful pattern your motivation section calls out.
2. Drift detection: capability change without version change
If a tool's behavior changes without a semver bump (silent API change, breaking semantics with same signature), how does ATD detect that? Re-verify-on-load (every agent session), verify-on-trust-window (e.g., 24h), verify-on-failure (after first incorrect invocation), or a continuous background watcher? We're trying to figure out where the verification cost should live in our protocol's registry.
3. Cross-team registry sharing — trust model
If Team A runs discovery, produces a registry, and shares it with Team B — what's the trust model that lets Team B use Team A's registry without re-verifying? Signed attestation from Team A's principal? A reproducible discovery transcript that B can replay? Or is shared trust impractical and B should always re-discover?
This connects to our attestation_method field on registry entries — sig, tee, oracle, zktls, none — but the cross-team case is where the model gets tested.
Happy to share the OM World registry spec section if useful. Thanks for separating discovery + conformance into distinct skills — that decomposition is exactly what we needed to see done somewhere outside the spec.
Hi — I'm working on OM World, a protocol for a decentralized intent economy. We're specifying a Tool Registry primitive — what an agent can call to act on the world — and ATD is the closest existing system I've found that treats discovery + capability mapping as a first-class concern rather than as an afterthought inside an agent framework.
Three design questions where your experience would be valuable:
1. What's the minimum capability entry needed to invoke (not just find) a tool?
We're trying to specify a registry entry as:
tool_id,version,provider,interface(typed input/output),boundary(local/relay/public),operation_class(read/write/destructive/admin),attestation_method,stateful(bool), plus pricing/SLA. What's in ATD's persistent registry that an agent loads before invoking a tool — typed I/O schemas, failure mode catalog, side-effect class, all of the above?The reason for the question: discovery alone doesn't make a tool callable. We want the registry to carry enough that an agent can invoke correctly without re-running discovery per call, which is the wasteful pattern your motivation section calls out.
2. Drift detection: capability change without version change
If a tool's behavior changes without a semver bump (silent API change, breaking semantics with same signature), how does ATD detect that? Re-verify-on-load (every agent session), verify-on-trust-window (e.g., 24h), verify-on-failure (after first incorrect invocation), or a continuous background watcher? We're trying to figure out where the verification cost should live in our protocol's registry.
3. Cross-team registry sharing — trust model
If Team A runs discovery, produces a registry, and shares it with Team B — what's the trust model that lets Team B use Team A's registry without re-verifying? Signed attestation from Team A's principal? A reproducible discovery transcript that B can replay? Or is shared trust impractical and B should always re-discover?
This connects to our
attestation_methodfield on registry entries —sig,tee,oracle,zktls,none— but the cross-team case is where the model gets tested.Happy to share the OM World registry spec section if useful. Thanks for separating discovery + conformance into distinct skills — that decomposition is exactly what we needed to see done somewhere outside the spec.