An AI agent directory is an index, not a shortlist

The short version

• A directory listing is evidence that somebody submitted an entry, not evidence that the agent runs.
• Listing has a reward and updating has none, so entries accumulate and dead ones are rarely removed.
• Entry count is the number every directory advertises and the one that tells you least.
• The things that decide an agent project, permissions, failure behaviour, cost under load and who is on call, appear in no directory field.
• The only directory with a clear payoff is the internal one: one row per agent, with an owner and a review date.

What is an AI agent directory actually for?

Discovery, and not much beyond it. A directory is an index: a name, a one-line description, a category tag and a link, submitted by whoever built the thing and approved by whoever runs the site. Once approved, the entry sits there. That is the entire mechanism, and knowing the mechanism tells you exactly what the output is worth.

Discovery is genuinely useful. If somebody has asked you to 'look into agents' and you do not yet know whether you need a support agent answering customer email, a document pipeline, or a scheduled job with a model in the middle of it, an hour reading a directory will teach you the vocabulary of the category faster than three vendor calls. You also see the shape of the market: which problems have forty tools chasing them, and which have none at all.

The mistake is treating the index as a shortlist. A listing is evidence that somebody submitted an entry. It is not evidence that the agent runs, that it is still maintained, that anybody operates it in production, or that it would hold up against your data and your permissions model. Directories have no mechanism for checking any of that, and the honest ones do not pretend to.

Why do AI agent directories go stale so quickly?

Because listing carries a reward and updating carries none. The submitter gets a link and a trickle of traffic on the day the entry goes live. Nobody is paid to come back eighteen months later and mark the project abandoned. So entries accumulate, dead ones are rarely removed, and the directory's size becomes its selling point rather than its weakness.

The result is easy to confirm. Click through thirty listings and you will find demo links resolving to parked domains, repositories whose last meaningful commit predates the current generation of models, and pricing pages that now say 'contact us' where a self-serve tier used to be. None of this is dishonest. It is simply what an unmaintained index looks like after two fast years.

It is worth comparing a listing to something that does report its own basis. Stack Overflow's 2026 developer survey collected 30,903 valid responses from 169 countries, and its AI tooling question was answered by 17,464 of them. You may disagree with what that sample represents, but you can see it and argue with it. A directory entry gives you no base, no date and no method, so there is nothing to argue with.

There is a second kind of staleness that is harder to spot. An agent built around an early tool-calling pattern may still install and still run, and still be the wrong thing to adopt, because the platform it wraps now does that natively and the wrapper is a layer you would maintain yourself for no gain. Nothing in the listing will tell you this. Only the repository will.

What are the four kinds of AI agent directory?

Most AI agents directories fall into one of four kinds, and they fail in different ways. Working out which one you are reading tells you how much of it to believe before you read a single entry.

The distinction that matters is who pays for the list to exist. If the submitter pays, breadth is the product and ordering tells you nothing. If a platform pays, the catalogue is shaped by what sells the platform, but entries have usually been run at least once. If nobody pays, the list is a side project, which is fine as long as you read it as one.

Four kinds, and what each one is good for

• •Repository lists: a markdown file in a public repo. The weakest curation and the best audit trail, because the commit history shows when every entry arrived and each linked project shows whether it is still alive.
• •Platform stores: run by the company whose runtime you are adopting. Entries are often tested against that runtime, which is real information, but the catalogue exists to make the platform look complete.
• •Independent listing sites: funded by submissions, sponsorship or affiliate links. Useful for breadth. Ordering usually reflects who paid or who submitted most recently, not who is any good.
• •Internal registries: the list an organisation keeps of its own agents, with an owner, a purpose and a review date against each row. The only kind that answers 'who is responsible for this one'.

How do you check a directory listing in ten minutes?

Open the thing itself and look for signs of life. Ten minutes is enough to eliminate most listings, which is the whole point: you are not evaluating anything yet, you are reducing two hundred entries to five that deserve a real day of work.

The checks are boring and they work. They are also the checks a directory will never run on your behalf, because running them costs more per entry than an entry earns.

Apply the same scepticism to any figure a listing quotes at you. Verifying one means opening the source, and the source is often less convenient than the quotation implies. The U.S. Chamber of Commerce's small business technology report is a fair example: its report page does not publish the sample size or the field dates, which sit only in the downloadable PDF. A number you cannot trace to a method is a number you should write qualitatively or not at all.

What to open instead of the listing

What does a directory never tell you?

The five things that decide whether the project works. Who the agent is allowed to act as. What it does when the model is wrong. Where the logs go. What it costs under real load. Who is on call at two in the morning. No directory carries fields for any of these, and they are most of the work.

Take permissions. An agent that reads a shared drive on someone's behalf has to resolve that person's entitlements before it retrieves anything, not filter the results afterwards. Get that wrong and the agent reads documents the user cannot open, which no demo will reveal because demos are run by administrators. A listing cannot express this, because it is a property of your deployment rather than of the software.

Take failure. Most agents are demonstrated on the happy path, where every step returns what the previous step expected. The interesting question is what happens when the fourth call in a five-step chain returns an error, whether the half-finished work is visible to anyone, and whether a human can see where it stopped. There is no directory field for behaviour under partial failure, and there is no way to infer it from a feature list.

Cost is the third gap. Per-request pricing looks trivial in a demo and stops looking trivial once the agent retries, re-reads context and runs on every ticket rather than the three you tried. That arithmetic depends on your volumes, so nobody else can do it for you.

Should you list your own agent in a directory?

Usually not, if you are hoping for buyers. Search demand around these queries is modest and the intent behind it is research. Somebody reading a directory is mapping a category, not choosing a supplier for a build they have already budgeted. Treating directory submissions as a sales channel is a reliable way to spend an afternoon and learn nothing.

Two cases are worth the twenty minutes. If the directory is the platform store for a runtime your users already pay for, being in the catalogue is distribution, and distribution is the one thing a listing can genuinely give you. If it is a well-known repository list, the entry costs a single pull request and sits somewhere people actually read.

What is not worth doing is submitting the same entry to fifty low-quality listing sites. It does not move rankings in a way anybody can demonstrate, and it leaves fifty copies of a description that will be wrong within a quarter, each of them effectively impossible to correct. You have published a stale claim about your own product in fifty places and kept the keys to none of them.

What is a better first step than browsing a directory?

Write down one request you want handled, end to end, including the version of it that goes wrong. Not 'automate support', but the actual message a customer sends, the three systems somebody currently opens to answer it, the judgement call in the middle, and what should happen when the answer is not in any of those systems. That document is worth more than any shortlist, because it is the thing you will test candidates against.

The gap between interest and adoption is where most of this work stalls. Eurostat's 2025 survey of enterprise AI use, which put the questions to 157,000 of the 1.53 million EU enterprises with ten or more employees, reports that 14.21% of non-users had considered using AI technologies and not gone ahead. Considering and not proceeding is a normal outcome, and a directory is a very comfortable place to keep considering.

So set a limit. Pick two or three candidates, give each one a day, and run them against twenty real examples you have labelled yourself, including the five awkward ones. Count how many come back right, read what the wrong ones did, and check what each attempt cost. At that point you are measuring rather than browsing, and the directory has done the only job it was ever able to do.