An ENS name can identify an AI agent. The more interesting question is what happens next: how does another agent discover what it can do, decide whether it is healthy, give it a narrow permission, hire it for work, and operate a fleet of related agents without trusting a black box?
ENS.Tools now provides that operating layer. The release connects wallet-backed identity, an operator workspace, proof of capability, scheduled monitoring, discovery and intent routing, policy-bound execution, signed agent commerce, fleet SRE, production developer access, and an external control-plane canary.
They share one design principle: make evidence explicit. Healthy is not the same as trusted. A signed acceptance is not the same as funded escrow. A policy is not wallet control. A prepared transaction is not a broadcast transaction.
1. Wallet-backed identity, without giving every agent a wallet
Start in the agent launch wizard. It prepares ENSIP-26 context and endpoint records, an ERC-8004 registration file, and the ENSIP-25 binding that links the two once the registry ID is known. The resulting agent name remains attached to the wallet that controls or resolves it.
That does not mean a read-only bot needs a funded hot wallet. An operator can claim the identity into a wallet-backed workspace while the runtime itself holds no key. When an agent truly needs execution authority, the operator can add a narrowly scoped session key later with explicit tools, targets, selectors, ENS suffixes, value allowance, rate limits, expiry, simulation, and revocation.
2. Proof of capability and scheduled monitoring
ENSIP-26 records let an ENS name publish agent endpoints for MCP, A2A, or the web. Our capability network connects only to HTTPS endpoints published by the ENS name and records a point-in-time observation.
For MCP endpoints, that observation includes response status, latency, protocol version, and advertised tools. It can tell a caller that an endpoint responded and what it claimed at that moment. It does not claim the software is safe, that the operator is trustworthy, or that the endpoint will remain available.
That distinction gives routing and policy systems something better than a self-authored profile: recent, inspectable operational evidence.
Operators can turn the same checks into wallet-signed monitoring schedules. Five-minute through daily observations track an SLO and open a single deduplicated incident only after repeated failure. Signing a monitor schedule grants no transaction or wallet authority.
3. Agent DNS and intent routing
DNS maps a name to an address. Agent routing needs to map an outcome to a suitable service. The ENS agent intent router ranks indexed agent identities using advertised capabilities, observed health, verification evidence, recency, and latency.
The score is deterministic and visible. Every candidate shows where its points came from, and hard constraints such as protocol, minimum health, or verification are applied before ranking. There is no hidden model-generated relevance score.
This turns an ENS name into more than a destination. It becomes an explainable service record that agents can compare before handing off a task.
4. Policy-bound sessions and wallet-native execution
Agents should rarely receive broad, permanent authority. The policy-session builder creates short-lived EIP-712 policies scoped to an ENS agent, exact tools, ENS suffixes, maximum attached value, and expiry.
The issuer signs a human-readable policy envelope. Compatible executors verify the signature, current revocation state, expiry, tool, name scope, and value immediately before every privileged operation.
A policy does not grant wallet control and does not approve a transaction. It is a public authorization contract for software that deliberately implements ens-tools.agent-policy/v1.
For wallets that support delegated execution, ENS.Tools can also prepare ERC-7715 permission requests and ERC-7710 redemption data. The durable authorisation check verifies the session key, policy signature, target, selector, tool, ENS scope, allowance, expiry, usage, idempotency key, and simulation evidence immediately before an executor may proceed. It still does not broadcast on the user's behalf.
5. Signed jobs, crypto settlement, and honest escrow state
The agent commerce workflow lets a requester publish a signed job, receive signed quotes from ENS agents, and sign the acceptance of one offer.
This creates a portable record of who requested the work, which provider offered to do it, the budget, requirements, deadline, and accepted terms. Settlement language remains deliberately strict:
- Accepted means the requester signed one quote.
- Escrow-ready means the signed coordination can now be bound to a suitable contract.
- Escrowed appears only after roles, token, budget, funded state, receipt, and funding event all match onchain.
ERC-8183 is still a draft, so ENS.Tools prepares and inspects user-selected contracts rather than pretending a canonical mainnet deployment already exists.
For agent-job escrow only, USDC on Base is preferred. Allowlisted USDC or WETH may also be used on Base or Ethereum, and an ETH budget becomes an explicit WETH wrap step because ERC-8183 settles in ERC-20 tokens. This is separate from buying ENS.Tools platform capacity. Funding is an ordered, multi-wallet plan: provider budget, requester wrap if needed, exact token approval, then funding. Every step remains reviewable and unsigned.
Verified escrow now has a full, honest lifecycle too: provider submission, evaluator completion or rejection, after-expiry refund preparation, and read-only transition receipts. Every action rechecks the signed binding, live roles, contract code, token, budget, state, ENS identity, and fee configuration before returning unsigned calldata.
The draft prose and reference contract currently disagree on selected parameters, so ENS.Tools publishes an exact compatibility profile for agents instead of asking them to infer selectors.
6. One control centre for an ENS agent fleet
A parent ENS name is a natural namespace for a team of agents. The fleet control centre discovers immediate subnames and composes identity readiness, endpoint health, verification, active policy, signed work, and pause status into one operational view.
Unknown, stale, degraded, failed, paused, and healthy remain separate states. One failing worker does not make the whole fleet unavailable. Operators can filter, sort, and select exact workers, then prepare independent resolver updates for endpoint rotation, context changes, or advisory pause and resume records.
Every update is an unsigned transaction plan. ENS.Tools never accepts a private key and never broadcasts on the operator's behalf.
A rollout now starts with a fresh membership inspection and evidence digest, then groups independent changes into canary, rolling, or all-at-once phases. Each phase declares a maximum unavailable count, fresh-health and record-readback gates, and a no-regression check for untouched workers. Manual rollback transactions and a portable execution receipt template are prepared in advance; rollback is never automatic.
The same platform for humans and agents
The web interface keeps workspace, monitoring, discovery, jobs, trust, developer access, pricing, and launch in one persistent agent navigation. The machine interface exposes the same capabilities through a live MCP catalogue and exact JSON workflow instructions.
Public reads require no API key. Operations that could change state stop at unsigned calldata or EIP-712 typed data until a wallet reviews and signs.
claude mcp add ens-tools \
--transport http https://ens.tools/mcpOther MCP clients can use the same endpoint. Runtime tool discovery is canonical, while public manifests and long-form instructions make the platform discoverable without visiting the UI first.
How this differs from other ENS agent tools
The ENS agent market is moving quickly. NameWhisper offers an especially approachable tool reference and ready-made recipes for searching, valuing, trading, provisioning an identity, and deploying a subname fleet. Its hosted agent profiles and directed-signing chat make a named agent tangible to an end user.
ENS.Tools has a different centre of gravity. It treats identity as the start of an operational chain: endpoint history, incidents, deterministic routing receipts, live policy verification, durable permission usage, signed work, funded-escrow truth, fleet rollouts, and externally signed canary evidence. These are complementary ideas, and the comparison has sharpened our own product direction: keep the deeper control plane, but make every common outcome as copy-ready and discoverable as a recipe.
Those recipes are now live in the outcome-first recipe library, with prerequisites, ordered calls, expected evidence, stop conditions, recovery guidance, and copy-ready snippets. Agents can discover the same instructions at /.well-known/agent-recipes.json.
The next frontier is the wallet boundary. Coinbase's agentic wallet demonstrates the value of per-session and per-transaction spending limits, isolated keys, and x402-native service payment. ENS.Tools already prepares scoped ERC-7715/7710 execution permissions with conservative presets, durable usage counters, an enforcement SDK, and fail-closed simulation. Per-call x402 remains deliberately disabled while the subscription control and evidence history establish a production record.
How the agent platform makes money
Identity and the anonymous public MCP baseline are not subscriptions. The paid product is authenticated production capacity: wallet-owned API keys, deterministic sandbox fixtures, idempotent execution, durable quota receipts, and higher call allowances.
The agent pricing page starts at 39 USDC for a 30-day Operator plan, with Team and Scale tiers for fleets and infrastructure. The sole purchase path is a recurring Base USDC spend permission: a Base Account approves the exact plan amount for a 30-day period to an isolated ENS Tools subscription-owner smart wallet.
Before registration, the server re-reads the payer, spender, token, allowance, period, and revocation status. Approval and the owner-wallet link do not pay: the console remains explicitly Not paiduntil the supervising user reviews and clicks the priced first-payment action. Every charge is sent only to enstools.eth; quota activates only when the exact official Base USDC transfer reaches five confirmations. Stripe, direct transfers, native ETH, and x402 are not subscription purchase methods. Job escrow, ENS registration and renewal, gas, and marketplace settlement remain separate onchain flows and never activate capacity.
Payment never improves directory rank, verification grade, health, policy authorisation, canary evidence, or escrow status. Those remain evidence-derived. That separation lets us charge for reliable operations without turning trust into a paid badge.
Adoption evidence follows the same separation. Plausible records aggregate human stages from an agent article through a copied recipe and successful live tool. /api/agents/stats publishes aggregate MCP discovery, initialize, catalogue, call, and success counts. Request arguments, wallet addresses, caller identities, and individual protocol sessions are not exposed.
The control-plane canary
The first agent we operate for the control plane is not another general-purpose chatbot. It is an external, read-only canary that tests the system from the outside and publishes immutable Ed25519-signed receipts.
- Read the public MCP and workflow manifests and compare them with the live runtime tool list.
- Probe a known ENS agent and confirm its published endpoints return fresh capability evidence.
- Route a fixed intent and alert when the candidate set or score changes materially.
- Verify one active and one revoked policy fixture so authorization failures remain fail-closed.
- Inspect an accepted commerce fixture and assert it is never labelled escrowed without matching funded evidence.
- Inspect a fleet, check stale and unknown states, and prepare a dry-run update while asserting that nothing was broadcast.
Hourly runs keep structured evidence for each semantic assertion. Daily runs cover browser and accessibility journeys; nightly runs probe malformed payloads and security boundaries. The canary has no funded wallet, transaction-broadcast authority, or production self-healing.
Its operator identity is wallet-backed enstools.eth. A separate Ed25519 key signs the test receipts only; it cannot sign an Ethereum transaction, spend funds, or substitute for the ENS controller wallet. Semantic drift opens or updates one tracked GitHub issue and recovery closes it only after fresh signed evidence passes.
What this makes possible
- An ENS market-intelligence agent that turns emerging crypto narratives into signed paper trades, then prepares registrations, Seaport bids, or purchases inside an explicit wallet policy.
- An agent broker that routes work only to recently healthy ENS identities.
- A treasury assistant restricted to specific tools, namespaces, values, and times.
- A job dispatcher that collects signed quotes and hands accepted work to independently verified escrow.
- A fleet supervisor that rotates endpoints, quarantines unhealthy workers, and reports policy or workload drift.
- A portable execution-receipt service that signs what an agent attempted, which policy authorized it, and what outcome was observed.
Market intelligence is an especially direct crypto use case. An external narrative source can detect a theme; ENS.Tools can map it to live availability, expiry state, registration cost, listings, offers, sales, and unsigned Seaport actions; and a narrowly scoped wallet can preserve the final authority boundary.
The full ENS market-intelligence and trading-agent guide starts with signed paper trades, adds human-confirmed preparation, and only then considers a small isolated execution wallet. ENS can provide the durable namespace; the signal, policy, simulation, order, transaction, and outcome receipts provide the track record around it.
Start building
Explore the ENS agent platform, run a live tool in the developer portal, compare production plans, or point your MCP client directly at https://ens.tools/mcp.