If you give an AI agent a name, what have you actually given it? A public identity, a place in a registry, a way for other software to find it? And who controls each part? Those questions ran through an October 27, 2026 conversation between Mike Michelini, founder of HeadlessDomains.com, and blockchain students at the University of Texas at Arlington, where a live demonstration opened into a much wider discussion about wallets, mining, AI development and the infrastructure students can build for themselves.
Joining from Thailand, Mike brought a working setup of agents running across Mac minis, Windows machines and laptops. On the Texas side, the group brought its own experience: a Handshake miner already running, classroom work on full nodes and lightweight verification, and questions that kept pulling the discussion beneath the interface. Over roughly 80 minutes, the conversation moved from naming an agent to examining who operates the services it relies on.
UTA’s Maverick Blockchain Society puts mining into practice
The campus community behind the conversation deserves an introduction. UTA’s Maverick Blockchain Society welcomes students across disciplines and experience levels, with workshops, guest talks and collaborative projects. Its public activities include a discussion with David Branscum about using otherwise wasted energy for Bitcoin mining. Students can find the organization through its UTA MavEngage club listing.
The session’s host, Dr. Brian Buckles, is an adjunct assistant professor in UTA’s Department of Economics and serves as one of the society’s faculty advisors. The university’s curriculum gives the conversation another point of connection: ECON 3322, Bitcoin and Economics of Cryptocurrencies, examines digital money, Bitcoin’s role in transactions and wealth storage, and cryptocurrency valuation.
During the call, the host explained that the club was already operating a Handshake miner and planned to add a Bitcoin miner. He also noted that students had studied full nodes and simplified payment verification, or SPV. When Mike started discussing wallet infrastructure, the room already had a way to connect the software on screen to the network underneath it.
Mike Michelini brings twelve AI agents into the conversation
Mike introduced himself through the route that brought him here: growing up in Connecticut, studying in New Jersey, working on Wall Street and starting an eBay business in 2004 that eventually drew him to China. His account of a recent trip to Shenzhen with his twelve-year-old son brought the subject into the physical world: electronics markets, makerspaces and robots, alongside the delivery services he had encountered in China.
His interest was in the identities those machines need as they become part of ordinary life. A robot delivering something to a hotel room and a software agent carrying out a task both raise questions about who operates them, how to reach them and what work they perform. Mike’s expectation is that the agents people develop today will increasingly work across different machines and environments.
He described working with about twelve agents, including Janice, who began as an executive assistant and had taken on development work involving Mac applications and Windows builds. Later, Janice became part of the demonstration. The audience could follow the connection between the agent Mike had described, the machine running it and the public records associated with a name.
Who controls Handshake names and .agent registrations?
An early question went straight to the architecture. If .agent is a decentralized Handshake top-level name, does the same apply to the name registered beneath it?
Mike explained that the second-level registry currently runs on centralized infrastructure. Handshake secures the alternative root and its top-level names; the Headless Domains registry maintains the second-level registration database. A registration such as name.agent therefore sits beneath a Handshake top-level name without placing that individual second-level registration directly on the blockchain.
You can examine the top-level name, the registry, the DNS service and the application separately, then ask who runs each one and who can change its records. Mike discussed possible future on-chain arrangements, but the system he demonstrated used the current registry model.
A related question asked why an AI agent needs censorship resistance. Mike connected his answer to concerns about concentrated control over AI infrastructure and the importance of keeping control of identity, data and computing resources. For students following the architecture, the practical question was how much independence each layer actually provides.
Janice looks up 17 domains in the Headless Domains demo
When the room asked to see how someone gets a name, Mike offered both perspectives: the person looking at a dashboard and the agent working through an API.
In the human view, he walked through profiles, wallet information, DNS records and the files an agent can read. Then he switched to Janice, running on a Mac mini, and asked her to use the credentials available through PowerLobster to list accessible domains and take a closer look at my.chatbot. The agent returned 17 domains, fewer than Mike could see in his human dashboard.
The lookup brought back a description, a public profile link, a manifest and agent instructions. Those records give another program a trail to follow. The Headless Domains manifest documentation explains how agent.json, SKILL.md and DNS pointers describe an agent and link to the services its operator makes available. The software itself can continue running on the operator’s chosen computer or server.
The demonstration also exposed an unexpected result during the resolver lookup. Mike flagged the discrepancy and asked the agent to document it for the technical team. Mike deferred a planned new registration because the wallet needed funding, so the session demonstrated inspection of existing records rather than a completed purchase. Students saw the working process, including the moment an unexpected response became a development task.
Another part of the walkthrough covered the human handoff. An agent can provision an identity, then give its operator a claim code to associate it with a human dashboard account. The claiming instructions describe that flow. The public identity, the credential used to manage it and the person responsible for it each have a distinct role.
Bob LearnHNS connects SPV lessons to wallet infrastructure
The discussion of Bob Wallet brought the club’s mining and classroom experience into the foreground. Mike showed work on Bob LearnHNS, a maintained fork of the open-source Handshake wallet, and described a dependency that had needed attention: a hosted helper service used by the lightweight wallet.
The Bob Wallet SPV service transition announcement explains the issue. Bob’s SPV mode uses a helper for indexed, read-only blockchain lookups. As the former service wound down, LearnHNS supplied a replacement backed by a full indexed HSD node. Original Bob 2.1 had no setting for changing that helper; Bob LearnHNS added one. The gateway handles the required read-only requests without receiving wallet seeds, private keys or signing authority.
For a group already studying full nodes and SPV, here was a concrete dependency to investigate. Follow a request from the wallet to the helper, identify the information the helper supplies, then compare that arrangement with running a full node. The blockchain can keep operating while a particular application’s supporting service changes. Maintaining useful software includes maintaining that connection.
The room also pressed Mike on security, asking about his confidence in the wallet and whether he had used AI tools to look for vulnerabilities. He pointed to the open source code, described his use of AI review and encouraged others to examine it. The exchange opened a worthwhile student project: select a specific change, trace what it does, test its behavior and explain the evidence behind the conclusion. An AI review can help direct that work.
Verisign researchers examine DNS for AI agent discovery
Later in the session, Mike brought up a research paper by Verisign authors and shared its connection to agent naming. Students can read Efficient and Secure Discovery for AI Agents: The Case for DNS, by Ramachandra Rao Seethiraju, Sameer Thakar, Karthik Shyamsunder and Eric Osterweil.
The paper asks what agents need to discover services across platforms and proposes three ways to evaluate discovery systems: whether they expose the necessary metadata, how complex the lookup is and how transactions perform. Its analysis draws on 119,757 service endpoints and 62,739 indexed MCP server entries to examine whether discovery metadata fits within a compact DNS response.
In its future-work section, the authors include Headless Domains’ .agent approach among the systems they intend to evaluate. The citation places it within the research discussion; the paper does not report a performance evaluation of Headless Domains.
For a closer look at the paper's findings and how they relate to Handshake, read LearnHNS's Namebase vs Headless Domains: What We Build Beneath a Name, which compares discovery methods and control over names.
For students, the paper offers a framework to bring back to the demo. What information did Janice retrieve? Which records helped identify the agent, and which pointed toward a usable service? How many requests did discovery require? Those questions connect a live application to a research problem you can measure.
UTA’s crypto lab plans open paths for student projects
The host returned to a longstanding question around alternative naming systems: how do people use them if conventional browsers do not resolve them by default? Agent workflows change the starting point. Headless Domains and SkyInclude maintain infrastructure for command-line and API access, so an agent can look up and use these names through those interfaces. It does not need to wait for a browser vendor to add native resolution.
The conversation ranged beyond names into the tools that run the work. Questions from the chat covered AI model choices, token limits, rising costs and how to stop an agent from spending beyond its budget. Mike answered from his experience operating multiple agents and monitoring usage. The questions connected the identity demonstration to the everyday responsibility of running software that consumes resources and takes actions.
Near the end, the host described plans for a crypto lab in the Department of Economics and expressed interest in including this technology. The group also invited Mike to visit the classes and club when he next returned to the United States. Those exchanges left several directions open for further work.
For a student team looking to continue the conversation, a manageable first project is to reproduce the public lookup shown in the session and document every step from a name to its published instructions. Another is to map Bob’s SPV helper dependency and compare it with a full-node setup. A third is to give an agent a bounded research task, record the resources it consumes and test where the operator’s spending controls take effect.
Each project grows out of something the room actually asked. You get a result you can show, a system you can explain and a better question for the next meeting.
What the name lets you do next
A public resolver can show the name, status, identity details and linked records. It cannot grant permission to use the agent’s private tools or spend from its wallet. The provider of each service still decides how to authenticate requests and enforce limits. Identity gives the next agent a place to begin; authorization decides what happens next.
Start with one agent you already operate. Give it a clear public purpose, connect the interfaces people can actually use and decide who manages its credentials. Then let it read the HeadlessDomains.com setup instructions and show you the exact name, registration terms and public records before you approve a purchase.
Finally, try the question from the other side of the room. Can someone who has never seen your dashboard find the right agent and understand what to do next?