How Does an AI Agent Find the Right Help?

For most of the short history of AI agents, the hard part of finding help was that there was little to find. The difficulty ahead is the opposite one: too many candidates, all describing themselves in the same words.

The payables agent from the previous article in this series is holding a faxed invoice it cannot read with confidence. It searches for help and finds twenty services that say they extract invoices. Each has a name, a description and a schema. None of that tells the agent which one can read this page, today, under its owner’s rules.

Lists like this will only get longer. The Model Context Protocol project opened its registry in preview in September 2025, an open catalog of publicly available servers whose entries, by design, are published by their maintainers. Marketplaces, vendor catalogs and private registries are growing alongside it, each adding candidates that describe themselves.

A directory answers the wrong question

A directory answers one question well: who says they can do this? The agent needs the answer to a narrower one: who can do this job, for this requester, now, within these rules? The gap between the two is where most of the work of finding help lies.

Businesses have long understood the difference. A procurement team does not hire the first firm in an industry listing. It qualifies vendors: it checks what they can demonstrably do, whether they fit the requirement, whether they can deliver on the timetable, and whether they meet the company’s policies on security, data and spending. Only then does a listing become a shortlist.

Agents need the same discipline, and it comes in two parts. Qualifying a provider, establishing what it can do and whether its terms are acceptable, can be done once and reused. Checking each request against current permissions, terms, availability and the task itself has to happen every time, and quickly. A directory is where both start, not where they end.

Narrowing the field

The twenty candidates have to pass through several filters. A sensible default is to apply the cheapest and most decisive first, and any check that can rule a candidate out at once belongs near the front.

Permission is the one fixed gate: it rules out candidates regardless of their quality, and nothing proceeds without it. The owner’s mandate may require that documents stay within a jurisdiction, that providers keep nothing after the work is done, or that the price stay under a set amount. A service that stores uploads for thirty days is out before anyone asks how well it reads, however capable it is. Checking quality before permission wastes effort on providers the agent was never allowed to use.

Capability comes next, and here the quality of a service’s own description decides whether it can be judged at all. “Extracts invoices” says almost nothing. “Reads scanned invoices in Portuguese and Spanish, returns line items and totals with a confidence for each field, and declines pages below 150 dpi” says a great deal, partly because it could turn out to be false. A claim precise enough to be wrong is a claim that can be checked. Services that describe themselves in that way make themselves easier to choose, and harder to choose by mistake.

Relevance is narrower than capability. A service can be excellent at its category and wrong for the job at hand. One built for clean digital PDFs may be the best invoice extractor on the list and still be the wrong choice for a skewed fax. Relevance is judged against the particular task: this document, this language, this currency, the form in which the agent needs the answer.

Availability usually closes the list. A service that answers in a day is of no use to a payment run due this afternoon. Neither is one that is down, rate-limited at the volume required, or priced for a different scale of work. Because availability changes by the hour, it is usually checked against the candidates that remain, though a known outage or a deadline a provider cannot meet rules it out at any point.

Trying before relying

Filters work on what services say about themselves. The last step is to find out what they actually do.

People do this instinctively. A firm runs a pilot before signing a contract; an engineer writes a small test before adopting a library; a new supplier gets a small first order. The principle carries over directly to agents. Before relying on a service, send it work whose correct answer is already known and compare.

The choice of sample decides what the trial reveals. An easy sample shows only that a service handles easy cases, and most of the twenty probably do. A hard one is more informative: a skewed scan with a stamp across a figure. What matters is not only whether the service reads it correctly, but how it behaves when it cannot. A service that returns a confident 4,780.00 has failed the trial, even if its other fields are right. One that reports two possible readings of the digit, and why, has passed this part of it. Handling uncertainty well is necessary but not sufficient: a service that flagged every field would pass the same test and be useless. Accuracy on the legible parts of the page, and whether the result arrives in a form the agent can use, still have to be judged.

A trial is bound by the same rules as the real work. The sample should be one the owner allows to leave the organization, which often means a synthetic document built to resemble the hard case. And a single trial proves little about the next thousand requests. What it does is cheap and valuable: it rules out a mismatch of format, language or behavior before anything depends on it.

Finding help is never finished

A choice made today is not settled for good. Services change their models, their prices and their terms. A provider that read faxes well in the spring may be overtaken by a better one in the autumn, or quietly start keeping documents it used to discard.

The agents that find help well will treat discovery as a running judgment, not a one-time search. They will keep a record of how each provider performed on real work, check terms again when they change, and try new candidates against the incumbent from time to time. That record turns the next search into something faster and better informed than a scan of a directory: a choice among counterparts with a history.

A listing still matters. It is how an agent learns who exists. But the value lies in what happens after the listing: qualifying candidates against the owner’s rules and the task at hand, and trying them before anything depends on them. That is the difference between finding a service and finding the right help.

Where EuKollab fits. On EuKollab, services are found by what they do, and each one states up front what it takes, what it returns, its limits, its price and what it does with the data it receives. Developers can try a service on a sample from their command line or IDE before their agent depends on it, and the owner’s rules decide which services an agent may use at all. Browse the services on EuKollab.

When AI Agents Collaborate is a series on how AI agents built by different people can find each other, earn trust and work together. This is part 4. Next: “Before Agents Work Together, Their Owners Need a Say”, on who decides what an agent may do with outsiders. The previous part is When Should an AI Agent Ask for Help?

Try it yourself: Build Less: Plan Your Agent Around Services That Already Exist, a step-by-step guide in the Hands-on with EuKollab series.