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 select 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.
Conformance Terminology
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in BCP 14 [RFC 2119] [RFC 8174] when, and only when, they appear in all capitals, as shown here. Most of this document is narrative rather than normative; the naming rules in §3.3, the Capability Record schema in §4.1, and the governance constraints in §8 are the primary normative sections.
§3.3 Naming Rules: the uniqueness bullet was rephrased to make explicit that uniqueness applies to the (name, version) pair among non-revoked records, and that a revoked pair may be re-registered with the prior record retained in the registration log. No normative behavior changed; the rule is unchanged from what is already enforced by conformant Registry implementations and stated in Registry Specification §3.3.
The Dillweed Namespace is not an agent runtime, model provider, application framework, marketplace, or replacement for DNS, PKI, or identity infrastructure. It is a proposed coordination layer for naming, trust accumulation, resolution, governance, and continuity across agentic capability ecosystems.
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 select them 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
- Invocation target selection 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, invocation target selection, 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. Two scheme forms are defined: the full form dillweed:// for human-readable contexts, and the canonical short form dllwd:// for machine, protocol, and infrastructure contexts. Both forms are semantically equivalent and governed by the same naming rules.
dillweed://<domain>.<category>.<function>
dllwd://<domain>.<category>.<function>
dllwd://research.market.intel.vendors
3.3 Naming Rules
Namespace paths are normative. The following rules define what constitutes a valid Dillweed namespace path; they are binding on registries, resolvers, and any other implementation in the stack.
- A namespace path MUST contain at least two dot-separated components. Periods are the only permitted component separator.
- Each component MUST consist of lowercase ASCII letters (a–z), digits (0–9), and hyphens (U+002D).
- Each component MUST be between 2 and 64 characters inclusive.
- A component MUST NOT begin or end with a hyphen.
- The root schemes
dillweed://anddllwd://are reserved and governed solely by the DNSO. - The combination of
nameandversionMUST be globally unique among non-revoked capability records. A revoked(name, version)MAY be re-registered; the revoked record remains in the registration log for auditability. Implementations enforce this uniqueness rule at registration time and return an appropriate error when a duplicate is submitted. - Version suffixes may be appended using a colon:
dllwd://tools.search.web-retrieval:v2.
Internationalized namespace components are reserved for a future revision and are expected to follow IDNA 2008 (RFC 5891) punycode conventions. See Appendix A.
3.4 URI Scheme Identifier
The canonical short-form URI scheme for the Dillweed Namespace is dllwd://. This scheme is the preferred form for use in machine-readable contexts, protocol headers, resolver queries, registry records, and infrastructure configuration. The full form dillweed:// is the preferred form for human-facing documentation, standards submissions, and public communications where the source mark should be legible without prior context.
The dllwd:// scheme identifier is grounded in the domain registration dllwd.com, held by the founding steward under continuous ownership, which provides an independent prior art anchor for the scheme name. Both scheme forms resolve through the same DillClaw™ resolver infrastructure and produce identical resolution results. Implementations MUST treat the two forms as semantically equivalent.
Use dllwd:// in code, configuration, resolver queries, capability records, and API references. Use dillweed:// in standards documents, white papers, and human-readable explanations. Either form is acceptable in specifications; the canonical short form is preferred where brevity aids clarity.
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. The schema summarized here is governed in full by the Registry Specification v0.1; this section defines the fields that are essential to the namespace model.
4.1 Record Schema
| Field | Description |
|---|---|
| name | Fully qualified Dillweed namespace path, conforming to §3.3 |
| 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: experimental, trusted, verified, or canonical (see §7.1) |
| permissions | Enumerated allowed actions for consuming agents |
| version | Semver string for the capability implementation |
| signature | Ed25519 DNSO signature (format dnso_v1_<base64url>). See Registry Specification §5. |
| last_updated | RFC 3339 date-time in UTC with second precision (YYYY-MM-DDTHH:MM:SSZ). Non-UTC offsets and fractional seconds MUST NOT be used. |
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": "dnso_v1_WZ8oHbterECAL0P_D1Rtq...",
"last_updated": "2026-03-20T14:22:05Z"
}
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 resolution protocol, trust-scoring algorithm, and API contract are specified in full in the DillClaw Resolver Specification v0.1; this section describes the resolution model at the level needed to understand the namespace design.
5.1 Resolution Flow
Parse
Validate the namespace URI against the syntax rules in §3.3. 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
The calling agent invokes the capability directly using the endpoint and protocol returned in the Capability Record. The resolver does not sit in the invocation path unless a separate implementation explicitly chooses to proxy.
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
The four trust tiers are presented below in order from lowest to highest trust. Promotion criteria and governance semantics for each tier are specified in the Registry Specification §9.
Experimental
Limited validation or early-stage capability. Default starting tier for new registrations. Use with explicit acknowledgment of provisional status.
Trusted
Demonstrated reliability and usage history. Endpoint tested and found stable over a meaningful period. Promoted from experimental through track record.
Verified
Identity confirmed, endpoint tested, DNSO review complete. Suitable for production use by agents without explicit trust override.
Canonical
DNSO-designated preferred implementation for its category. Assigned sparingly and only by the DNSO for reference implementations.
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. The operational details of DNSO governance are specified in the Governance Framework and the DNSO Operations Charter.
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 200 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. The long-term continuity mechanism is specified in the Continuity Protocol.
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 handling discovery, registry lookup, trust evaluation, candidate ranking, and invocation target selection against the Dillweed Namespace. Specified in the DillClaw Resolver Specification v0.1.
Capability Layer
Tools, agents, data sources, and services registered within the namespace and invocable through the resolver.
Anthill Observability Plane
An orthogonal governance telemetry layer spanning L2–L4. Anthill ingests neutral coordination signals from resolvers and registry operations, providing the DNSO with a verifiable, append-only record of namespace ecosystem health. It does not gate resolution or invocation; it observes them. Specified in the Anthill Observability Plane Specification v0.1.
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. The observability plane (L5) is shown as orthogonal because it monitors the operational layers without participating in them — a structural prerequisite for credible governance, not an optional add-on.
Three additional specifications address sub-concerns the diagram above does not expand. The Registry Specification defines the authoritative persistence layer that backs the namespace. The Governance Framework and the DNSO Operations Charter operationalize the governance model in §8. The Continuity Protocol defines the long-term stewardship transfer mechanism.
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.
A complete reference implementation of the namespace stack — Registry, DillClaw Resolver, and Anthill Observability Plane — is operating on local infrastructure, with each service passing the conformance test suite for its corresponding specification under launchd auto-start. The DNSO Ed25519 public key is published at dillweed.com/dnso_public.pem. All currently published capability records in the registry are signed against this key and verifiable by any party. Public deployment of the registry endpoint is the next milestone.
Public Registry Endpoint IN PROGRESS
A publicly accessible registry returning Capability Records for registered namespace entries. Currently operating on local infrastructure with full API surface; public endpoint deployment pending.
End-to-End Resolution Workflow ACHIEVED
At least one complete resolution flow — from namespace URI to invoked capability — implemented and documented publicly. The reference implementation demonstrates this flow end to end through the DillClaw Resolver against the Registry, with full trace capture.
Protocol Interoperability PENDING
A documented integration with at least one of MCP, A2A, or a major platform gateway layer.
Developer Adoption PENDING
Real developer usage: at least one external capability registered and actively maintained within the namespace.
Trust Accumulation in Practice PENDING
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.
Future Work (Non-Normative)
This appendix records items intended for a future revision of the Dillweed Namespace Standard. It is non-normative: nothing in this appendix imposes conformance requirements on implementations. It is included to disclose the anticipated direction of the specification so that implementers can make informed decisions about extensibility and ecosystem participants can plan for forthcoming changes.
A.1 Internationalized Namespace Components
The current specification restricts namespace components to lowercase ASCII letters, digits, and hyphens to guarantee unambiguous byte-level comparison and stable canonical JSON signing. A future revision is expected to extend the component rule to accept internationalized names encoded per IDNA 2008 (RFC 5891) punycode, with a clear normalization rule that prevents the same logical name from producing distinct signed records. This change will affect §3.3 and the downstream Registry and DillClaw specifications.
A.2 Machine-Readable Governance Instruments
The governance instruments described in §8 are currently expressed in natural-language prose across this document, the Governance Framework, and the DNSO Operations Charter. A future revision is expected to publish machine-readable governance instruments — signed policy documents, registration rules expressed as executable validation logic, and promotion criteria expressed as testable predicates — so that the rules governing the namespace are enforceable by code, not merely stated in documents. This change will affect §8.3 and the Governance Framework.
A.3 Structured Registration APIs and Automated Stewardship
The current specification describes registration (§8.4) as a process requiring DNSO review for identity verification and stewardship commitment. A future revision is expected to introduce tiered automation: a self-service registration path for experimental tier capabilities with automated validation; a review-mediated path for trusted and verified tier promotions; and a fully manual path for canonical tier assignment. This change will affect §8.4 and the Registry Specification.