The Boring Infrastructure AI Agents Need: Identity, Skills, and Retrieval

Agent systems often keep private registries of URLs, tool descriptions, and credentials. Those records drift when a service moves or a new version appears. An agent may call the wrong endpoint while the team believes it reached an approved service.

DNS-AID proposes DNS as a vendor-neutral way to publish, discover, and verify agents and MCP servers. The specific standard may change. The requirement will remain: discovery needs ownership, identity, versioning, and a verification path.

A browser agent can spend tokens rediscovering selectors, navigation, and request patterns each time it visits a site. That exploration may work once and fail after a minor interface change. A reusable skill records the proven path and the assumptions behind it.

Skills need owners and tests. A saved selector can become stale too. Record the site version or last validation date, keep the skill narrow, and detect failure before the agent clicks through a different flow.

A search API that returns one polished bundle limits the agent’s ability to rank, filter, fan out, and preserve intermediate evidence. Perplexity’s Search as Code work explores a lower-level approach where an agent uses code and a sandbox to build the retrieval path it needs.

That flexibility adds cost and risk. Set limits on queries, domains, runtime, and parallel work. Keep citations and intermediate results so a reviewer can understand how the agent reached the answer.

Use code for validation, permission checks, deduplication, budgets, and output schemas. Let the model choose among uncertain search paths or interpret messy pages. This division keeps the agent from spending reasoning tokens on rules the team can state.

Narrow primitives also make evaluation easier. The team can test discovery, skill execution, retrieval quality, and synthesis as separate stages instead of grading one final answer.

Reusable skills and retrieval plans reduce repeated discovery cost. They can also preserve stale assumptions. Attach last-checked dates and invalidation rules. A site change, service version, or repeated execution failure should send the item back to discovery.

The agent needs to know when to trust memory and when to look again. That decision belongs in the system design, not in an improvised prompt.

Track discovery failures, skill invalidations, retrieval cost, unsupported claims, and the time a person spends recovering a run. A lower token bill means little if the saved skill sends the agent into the wrong account.

Boring infrastructure earns its place by making work repeatable and inspectable. The team should see fewer mystery failures as the catalog, skills, and retrieval controls mature.