The open keyspace on agent-endpoint[<protocol>] is one of the stronger design choices here — new protocols slot in without any coordination overhead. Standardizing the bracket convention at the ENSIP level is the right call: it gives the ecosystem a stable foundation and forward compatibility as the landscape evolves, encouraging adoption and experimentation.
The minimalism here facilitates routing and discovery — these records need to just work across chains without dependencies. They govern how clients find and connect to agents.
agent-context being deliberately untyped works for early adoption, but it means clients have no runtime path from the record to its own semantics — no required fields, no type enforcement, no validation without hardcoding prior knowledge of the format.
That’s a concern agent-context’s open format leaves room for, and one where NMS can naturally complement.
Consider a new client looking to resolve agent-context in either scenario:
| Sequence | Without NMS | With NMS |
|---|---|---|
| 1 | resolve agent-context → free-form string | resolve schema → ipfs://Qm… |
| 2 | format unknown — plain text? YAML? JSON? | fetch JSON Schema — fields, types, required constraints |
| 3 | no required fields to check, no validation possible | validate records against schema, flag missing fields |
| 4 | client hardcodes a parser or treats value as opaque | render field descriptions in UI with no prior knowledge |
| Result | client arrives guessing | client arrives knowing |
As the ecosystem matures, an agent’s ENS name could carry both agent-context for bootstrapping and a schema text record pointing to an NMS schema — typed metadata traveling alongside the discovery layer, not competing with it.
The off-chain schema enables runtime discoverability: clients fetch type info, descriptions, and validation rules without hardcoded prior knowledge of the format.
In that context, the dependency is a feature, not a bug.