Dillweed Namespace Standard (Draft Proposal)
A Governed Coordination Layer for Agentic AI Systems
Agents can call tools. What they lack is a stable way to discover, evaluate, and route to the right capability across time. Agentic AI systems face a coordination problem that protocols alone cannot solve — they can connect to tools, but cannot reliably find, trust, and use them across providers, at scale.
The question is not whether agents can call tools. It is whether they can do so through a naming and trust layer stable enough to survive scale, substitution, and time.
A registry answers "what exists?" A namespace answers "what should be used?" As agentic systems scale, this distinction becomes the difference between a directory and infrastructure. The Dillweed coordination layer is one proposed answer to that problem — offered as a standard model with a specific governance implementation.
Abstract
Agentic AI systems are proliferating faster than the infrastructure needed to coordinate them. Protocols like MCP and A2A solve the connection problem. They do not solve the coordination problem: how agents discover capabilities reliably, how names remain stable across provider changes, how trust accumulates over time rather than being re-established at every boundary.
This document describes an abstract namespace model for addressing that gap, and proposes the Dillweed Namespace as a concrete implementation of that model. The two are presented together but are conceptually distinct: the model describes what a governed coordination namespace must do; the Dillweed implementation describes one specific instantiation with defined governance, provenance, and stewardship.
Other implementations of the model are possible and may emerge. This document aims to define the model well enough that any implementation — including this one — can be evaluated on its merits. If this layer is not established deliberately, it will emerge implicitly — fragmented across platforms, inconsistent across agents, and unstable over time.
A namespace structure and URI syntax for naming capabilities durably. A resolution protocol for mapping names to invocable endpoints. A governance model for maintaining continuity and trust over time. A layered trust framework designed for accumulation, not just point-in-time verification.
The Coordination Problem
Modern AI systems can connect. They cannot reliably find, trust, and use each other. The gap is not protocol — it is coordination. Today's ecosystem provides APIs, agent frameworks, and interoperability protocols. What it lacks is a stable way to name capabilities, discover them in context, evaluate trust, and route actions reliably across systems and over time.
Without a coordination layer, large-scale agentic deployments face predictable failure modes:
- Capability discovery is ad hoc and non-transferable across systems
- Names and identifiers are unstable, breaking agent workflows when services change
- Trust must be re-established at every integration point with no accumulated history
- Routing logic is embedded in individual agents rather than resolved from shared structure
A governed coordination namespace addresses all four failure modes simultaneously — by providing stable names, durable identity, accumulated trust, and shared resolution structure.
Why Existing Approaches Fall Short
| Approach | What It Solves | What It Leaves Open |
|---|---|---|
| MCP | Standardizes agent-to-tool connections | Naming, routing, long-term identity |
| A2A | Enables inter-agent communication | Stable namespace, resolution layer |
| MCP Registries | Discovery of available services | Governance, continuity, trust accumulation |
| AgentDNS / ANS | DNS-like resolution proposals | Governed namespace, stewardship model |
Registry vs. Namespace
"What exists?"
- Stores entries
- Records what is registered
- Answers lookup queries
- Optimized for enumeration
"What should be used?"
- Organizes meaning
- Accumulates trust over time
- Enables contextual selection
- Optimized for resolution
A registry stores entries. A namespace organizes meaning, accumulates trust, and enables action. This distinction becomes critical at the scale agentic systems are approaching — and it is the distinction this document is built around.
The key function of a coordination namespace is not storage. It is answering: "Given this context, what should happen next?"
Namespace Structure and Syntax
3.1 Design Principles
A viable coordination namespace must satisfy five structural properties. These are properties of the model, not specific to any implementation:
- Memorability — Usable by humans and agents without lookup overhead
- Distinctness — Low ambiguity across linguistic and technical contexts
- Extensibility — Accommodates many categories, subcategories, and capability types
- Durable Control — Long-term stewardship by a single accountable party
- Semantic Openness — Not locked to a single product, trend, or technology generation
3.2 URI Format
The Dillweed Namespace uses a URI scheme that signals addressable resolution intent rather than simple labeling:
dillweed://<domain>.<category>.<function>
dillweed://research.market.intel.vendors
3.3 Naming Rules
- All path components must be lowercase ASCII letters, digits, or hyphens
- Components are separated by periods; no other separator is permitted
- Each component must be between 2 and 64 characters
- The root scheme
dillweed://is reserved and governed solely by the DNSO - Registered identifiers must be unique within their category scope
- Version suffixes may be appended using a colon:
dillweed://tools.search.web-retrieval:v2
Capability Records
Each namespace entry resolves to a Capability Record (CR) — a structured document that defines what a capability is, how it behaves, and how it can be used. The CR is the atomic unit of the resolution system.
4.1 Record Schema
| Field | Description |
|---|---|
| name | Fully qualified Dillweed namespace path |
| description | Human-readable summary of the capability's purpose |
| endpoint | Base URI or connection string for invocation |
| protocol | Invocation protocol: mcp, rest, grpc, a2a, or custom |
| input_schema | URI or inline JSON Schema for accepted inputs |
| output_schema | URI or inline JSON Schema for returned outputs |
| trust_tier | Trust classification: verified, trusted, canonical, or experimental |
| permissions | Enumerated allowed actions for consuming agents |
| version | Semver string for the capability implementation |
| signature | Cryptographic signature from the DNSO for verified entries |
| last_updated | ISO 8601 timestamp of the most recent validated update |
4.2 Example Capability Record
{
"name": "research.market.intel.vendors",
"description": "Vendor comparison and analysis capability",
"endpoint": "https://api.marketintel.ai/vendors",
"protocol": "rest",
"input_schema": {},
"output_schema":{},
"trust_tier": "verified",
"permissions": ["query", "summarize", "export"],
"version": "1.2.0",
"signature": "abc123...",
"last_updated": "2026-03-20"
}
Resolution Model
The namespace becomes operational through resolution. A resolver takes an agent's intent, queries the namespace, applies trust and policy filters, and returns an invocable capability. In the Dillweed stack, the resolution layer is implemented by DillClaw, operating directly against the Dillweed Namespace. The full DillClaw protocol and API are specified at dillweed.com/dillclaw-spec.html.
5.1 Resolution Flow
Parse
Validate the namespace URI against syntax rules. Reject malformed paths before any network request.
Registry Lookup
Query the authoritative Dillweed Registry for candidate Capability Records matching the path.
Trust Filter
Apply the caller's trust policy. Reject entries below the required trust tier. Callers may require verified status or apply custom logic.
Contextual Selection
If multiple candidates remain, select the best-fit capability based on context, version preference, and required permissions.
Invoke
Execute the capability using the endpoint and protocol from the Capability Record. Return the result to the calling agent.
5.2 Interoperability
The resolution protocol is intentionally protocol-agnostic at the invocation layer. A resolver may return endpoints for MCP servers, REST APIs, A2A-compatible agents, or custom protocols. The namespace remains viable across protocol generations without becoming obsolete as underlying standards evolve.
A Worked Example
To make the resolution model concrete, consider a procurement agent tasked with vendor due diligence. It needs to find, evaluate, and invoke a capability it has never called before — through a namespace it can trust without knowing the underlying provider in advance.
The agent expresses intent
A procurement agent is asked to compare shortlisted software vendors. It does not have a hardcoded tool for this. Instead, it queries the resolver: "I need a vendor comparison capability with at least verified trust, query and export permissions."
The resolver queries the namespace
DillClaw searches the Dillweed Registry for entries matching dillweed://research.market.*.vendors with trust_tier: verified and permissions including query and export.
Candidates are returned and filtered
Three entries match. One is experimental — rejected by the agent's trust policy. One is trusted but lacks export permission. One is verified with full permissions and a 14-month usage history. That entry is selected.
The Capability Record is resolved
The resolver returns the full CR for dillweed://research.market.intel.vendors — including the endpoint, schema, version, and DNSO signature. The agent validates the signature and confirms the schema matches its expected input format.
The capability is invoked and the result returned
The agent calls the endpoint with its vendor list. The capability returns a structured comparison report. The agent notes the namespace path in its audit log — so the same capability can be retrieved reliably in future sessions, regardless of which server currently serves it.
This scenario illustrates why the namespace matters in practice. The agent never needed to know the underlying provider. It needed a stable name, a trust signal it could rely on, and a resolution layer that could answer "given what I need, what should I use?" — not just "what exists?"
Multiply this interaction across thousands of agents, dozens of capability categories, and years of provider turnover. Without a stable namespace and trust layer, every agent must maintain its own capability map — which fragments, drifts, and breaks at every provider change. With one, the map is shared, governed, and stable.
Trust Model
Trust is layered, not binary. It is not inferred from existence alone — it is accumulated through validation, usage, stewardship, and policy over time. This is what separates a namespace from a registry.
7.1 Trust Tiers
Verified
Identity confirmed, endpoint tested, DNSO review complete. Suitable for production use.
Trusted
Proven reliability and usage history. Elevated from community standing through track record.
Canonical
Preferred or default resolution target within its category. Assigned by the DNSO for reference implementations.
Experimental
Limited validation or early-stage capability. Use with explicit acknowledgment of provisional status.
7.2 Trust Accumulation
- Capabilities that maintain valid registrations, stable endpoints, and consistent schemas over time accrue a usage history visible to resolvers
- Resolvers may expose this history to consuming agents as a contextual trust signal
- The DNSO may promote capabilities across tiers based on demonstrated reliability
- Revocation is immediate and namespace-wide: a suspended registration is untrusted across all resolvers simultaneously
7.3 Namespace-Anchored Identity
Within the Dillweed Namespace, identity is anchored to the URI path rather than to any specific credential or endpoint. A capability's identity is its namespace path — trust accumulated against that path persists across endpoint changes as long as the steward maintains the registration. This is the property that makes long-term trust accumulation meaningful.
Governance
This section describes two distinct things: first, the abstract governance model that any coordination namespace requires; second, the specific stewardship arrangement proposed for the Dillweed implementation. These are separable. The model could in principle be implemented by a different operator; the Dillweed implementation is one instantiation with specific, documented continuity properties.
8.1 The Abstract Governance Model
A durable coordination namespace requires governance that provides four properties regardless of who operates it:
- Continuity — The namespace must outlive any single product cycle, company, or technology generation
- Accountability — Decisions about naming, registration, and trust must be traceable and contestable
- Consistency — Rules must be applied uniformly; preferential treatment undermines the trust layer
- Openness — Any qualified party should be able to register; the namespace is not a closed ecosystem
8.2 The Dillweed Stewardship Arrangement
The Dillweed implementation of this model is governed by the Dillweed Namespace Stewardship Office (DNSO). The DNSO's purpose is continuity assurance — ensuring the namespace persists, remains trustworthy, and remains accessible across time — not control for its own sake.
The DNSO's current stewardship rests on 28 years of single-owner domain provenance, registered trademark protection across three classes, and a domain portfolio of approximately 230 assets. These are structural continuity properties, not claims of authority. They exist to answer a simple question any serious adopter will ask: will this namespace still exist and mean the same thing in ten years?
Stewardship is explicitly designed to transfer. Governance instruments are being structured so that the namespace can outlive any individual steward — similar to how a trust or foundation holds assets for beneficiaries beyond the founder's tenure. The DNSO role is that of a long-term custodian, not a gatekeeper.
A coordination namespace derives legitimacy from adoption, not declaration. The Dillweed Namespace does not claim authority by assertion. It offers a well-structured model, documented continuity, and transparent governance — and invites adoption on those terms. The community grants legitimacy; this document only makes the case for why it is worth granting.
8.3 Governance Constraints
- All namespace decisions must be logged and reviewable
- Registration criteria must be published and applied consistently
- Revocation actions must include documented justification
- Dispute resolution mechanisms must be defined and accessible
- Stewardship may expand over time without breaking continuity of existing registrations
8.4 Registration Requirements
| Requirement | Description |
|---|---|
| Identity verification | Verifiable contact information and organizational affiliation where applicable |
| Capability Record | Complete CR as defined in §4.1 submitted at registration time |
| Schema validation | Referenced schema must be accessible and valid at time of registration |
| Stewardship commitment | Registrant commits to endpoint maintenance and notifying the DNSO of material changes |
| Use compliance | Capability must comply with the acceptable use policy published by the DNSO |
Stack Positioning
The Dillweed Namespace operates as the middle layer in the emerging agentic AI stack — between human-scale distribution systems and capability-level implementations. Each layer serves a distinct role; none can substitute for another.
Human Gateway Layer
Access, identity, governance at platform scale. Examples: Meta, Google, Apple, Microsoft, Salesforce. The Dillweed Namespace is designed as a neutral coordination root no single platform controls — valuable to all of them for exactly that reason.
Dillweed Namespace Layer ← this document
Structure, continuity, meaning, and trust for agentic coordination.
DillClaw Resolver Layer
DillClaw is a resolver layer designed to handle discovery, trust evaluation, routing, and capability invocation against the Dillweed Namespace. Full specification at dillweed.com/dillclaw-spec.html.
Capability Layer
Tools, agents, data sources, and services registered within the namespace and invocable through the resolver.
This reflects a classical infrastructure pattern: the most durable layers are those that are neutral, independent, and provide coordination that competing parties can adopt without ceding ground to each other. The value of neutrality compounds over time.
Why Not Blockchain?
Blockchain systems are optimized for registration. They answer who owns something, what exists, and what changed. They do not solve real-time capability selection, contextual trust evaluation, low-latency resolution, or coordinated invocation.
- Immutable ownership records
- Decentralized registration
- Tamper-evident history
- Trustless consensus
- Real-time capability selection
- Contextual trust evaluation
- Low-latency resolution
- Coordinated invocation
In an agentic ecosystem, the scarce resource is not record-keeping. It is resolution. The Dillweed Namespace is designed for resolution, not registration — and the governance model is designed for continuity, not decentralization for its own sake.
What Must Be Demonstrated
This document is a proposal, not a settled standard. The Dillweed Namespace becomes meaningful infrastructure through demonstrated adoption, not through assertion. Without these milestones it remains conceptual. With them, it becomes operational.
Public Registry Endpoint
A publicly accessible registry returning Capability Records for registered namespace entries.
End-to-End Resolution Workflow
At least one complete resolution flow — from namespace URI to invoked capability — implemented and documented publicly.
Protocol Interoperability
A documented integration with at least one of MCP, A2A, or a major platform gateway layer.
Developer Adoption
Real developer usage: at least one external capability registered and actively maintained within the namespace.
Trust Accumulation in Practice
At least one capability demonstrating a track record of stable registration and elevated trust tier classification.
Asset Provenance
The Dillweed implementation is anchored in a controlled asset portfolio with documented long-term provenance. This provenance supports the governance model's continuity claim — it demonstrates the kind of durable, single-steward control that a coordination root requires to be taken seriously as infrastructure.
Conclusion
The AI ecosystem is expanding rapidly. The limiting factor is no longer access to capability. It is the ability to find the right capability, trust it, and use it correctly — through infrastructure stable enough to survive scale, substitution, and time.
The namespace model described in this document proposes one structure for meeting that requirement. The Dillweed implementation proposes one instantiation of that model, with specific continuity properties that make it a credible long-term coordination root.
The legitimacy of any coordination namespace — including this one — must be earned through adoption, not granted through declaration. This document aims to make the case clearly enough that adoption is worth considering. The rest is demonstrated, not argued.
Coordination roots, if they emerge, are not.
For capability registration, stewardship partnership, or technical integration inquiries, contact the Dillweed Namespace Stewardship Office via dillweed.com.