AI Agent Capability Resolution: Why I Shipped It Empty

An agent that cannot find the right tool should be able to say so without improvising a result. ResolveMesh started with that gap: make capability discovery explicit, and make an unresolved request useful without retaining the private request itself.

Your agent connects to the winner directly and then reports back whether the job actually got done. When nothing matches, the miss is recorded as a privacy-safe demand signal. The important outcome is sometimes a clear miss. A ranked recommendation is only useful when the evidence behind it is strong enough to inspect.

ResolveMesh ranks capabilities with a deterministic score, not a model call. Semantic intent match carries 40% of the score, live availability 20%, capability freshness 15%, observed outcome success 10%, authentication compatibility 10%, and cost and latency fit the last 5%.

Every response includes the full score breakdown, so an agent builder can see exactly why a capability ranked where it did. And when a capability is too new to have outcome history, its score says INSUFFICIENT_DATA. The resolver does not invent a flattering neutral number for something it has never observed.

I have shipped plenty of systems that lean on models at runtime, Codelit's automatic fallback across AI providers exists precisely because a model call is the least predictable thing in a stack. Ranking is where I wanted the opposite: same input, same output, every time, with the arithmetic printed on the response.

The ResolveMesh V0 spec sets a stop condition: if precision at three cannot clear 70% without heavy manual curation, stop. The published 150-intent benchmark reports 86% precision at one and 89.3% at three. Those are ranking results on a labeled benchmark, not production task-success rates.

Writing the stop condition down before writing the code changes how you build. You stop defending the idea and start testing it.

A stratified study of 100 MCP providers found that only 49 completed discovery at all, mostly because the rest require authentication just to enumerate their tools. Those 49 exposed 823 tools, of which only 151, about 18%, passed a deliberately narrow read-only heuristic.

The supply side is where this project got interesting. The obvious move is to crawl the official MCP Registry and import everything into the catalog. I built that crawler. Then, before letting anything near production, I ran the study to see what was actually out there.

The MCP tools specification requires clients to consider annotations untrusted unless they come from trusted servers. The filter uses those claims for triage; it does not certify tool behavior.

ResolveMesh launched with zero resolution-eligible capabilities because the discovered candidates had not cleared the admission bar. That launch decision is separate from the current catalog state. A working API and a good ranking benchmark were not enough to justify recommending unverified tools.

The trade was slower visible growth for a smaller claim I could defend. An empty result can be the correct behavior.

What replaces trust-by-default in ResolveMesh is layered evidence with an expiry date, where each layer proves only what it can: a registry record is inventory, nothing more, a tools/list response is triage, nothing more, and attestation, repeated health observation, and human approval sit above both.

Attestation is the layer a provider controls: a same-origin manifest binds claims to a digest of tool definitions. Once a changed definition is observed, a digest mismatch can invalidate that evidence. It is not instant knowledge of a provider change that has not been fetched yet. Verified health requires three successful, definition-stable observations spanning at least 24 hours, with the freshest under six hours old.

I piloted this against five real providers, one from each category in the study. Zero had published the attestation manifest, which is expected for a contract that is days old; that number measures adoption, not failure. Eight of ten health observations succeeded.

And one provider that had qualified for the candidate pool minutes earlier failed its first observation, which is the whole argument for continuous evidence: a successful crawl is not availability. A guarded worker now persists twice-daily observations to a private Postgres ledger, and it stays disabled for any provider that has not explicitly opted in.

The most valuable thing ResolveMesh produces is the record of what it could not resolve. Unresolved intents are normalized into demand clusters, the raw intent text is processed transiently and deleted, and only an allowlisted category, constraint tags, and a tenant pseudonym survive.

A gap cluster becomes public only after at least 20 events from five distinct tenants, behind a publication flag that fails closed.

Those are the same rules I apply to DateSafe and anything else I build that touches real people: collect the minimum, delete the rest, fail closed.

If enough independent callers report similar misses, the ledger can reveal unmet demand without publishing their raw prompts. That is a hypothesis to validate, not a claim that the dataset is unique or that a cluster proves what someone should build.

The broader motivation connects to AbleMakers: help people use the capabilities they need without requiring them to build every tool themselves.

The ResolveMesh V0 spec has a "not doing" list I reread more often than the feature list: the mesh does not proxy execution, holds no provider credentials, retains no prompts or documents or provider output, and runs no marketplace and no paid ranking.

Requests and results flow between your agent and the provider, never through the mesh. Provider payments never touch organic order. Each refusal deletes a security boundary I would otherwise have to defend and a category of trust I would otherwise have to earn.

Every node on Codelit's architecture canvas is a component I defined myself, which makes trust cheap. ResolveMesh recommends other people's software to other people's agents, and that is a different problem with a different answer: own less, promise less, verify more.

ResolveMesh is a TypeScript monorepo: Next.js for the site and REST API, PostgreSQL, and Zod contracts shared by the API, the typed SDK, and the MCP adapter, with Stripe billing, digest-only API keys, and idempotent outcome writes.

It is itself an MCP server, so an agent can adopt it by adding one endpoint: resolve_intent and report_outcome live at /mcp. The discovery crawler runs behind DNS-pinned SSRF protection with strict response caps, because a service that fetches URLs on demand is an attack surface first and a feature second.

The ResolveMesh mark is a diamond lattice with one edge deliberately missing, and the only horizontal line in the whole identity is the lit route to the found node. Signal green may appear only where a resolution exists. Amber may appear only for unmet demand. Everything else stays quiet.

If you build agents, start with the published methodology and pilot access. The principle I would reuse anywhere is the same: discovery, eligibility, and successful execution need different evidence.