Can an AI agent do better by hiring help?

An experiment by Adrian Föhl, Düsseldorf. What happened, in two parts: part 1, an agent hires help · part 2, catalogued but not hired.

This page is the full report of that experiment, written like a short thesis: the summary first, then the question, the hypothesis, the method, and the results at the end.

This is an experiment, not a product or a service for sale. Every number on this page comes from logged runs; the results page has the per-task detail.

1. The question, and why it matters

People used to find a supplier through a search engine. If agents do more of the work, an agent may do the finding instead: it needs a skill it does not have, looks up who offers it, and hands the work over. A company could then offer what it knows or does as an agent and be found by other agents, the way an app is found in an app store.

That idea hangs on one assumption: that an agent with the option to hire help actually does better than an agent working alone with the web and its tools. If it does not, a directory of agents is a catalogue for people, not a marketplace for agents. That assumption is what this experiment tests.

2. The hypothesis

A note on method first: every hypothesis and every pass-or-fail rule on this page was written down before the test it belongs to was run, so that the outcome could not be bent afterwards. The dates are in the results.

Main hypothesis (written before any test ran). For recurring checking tasks on a website, an agent that can find and hire specialist agents through a directory solves more tasks correctly than the same agent working alone, at no more than 50 percent more cost and time.

Six rules for "supported" were written down with it, among them: the agent with the directory solves at least 12 of 16 checking tasks and at least 4 more than the agent alone; it does not hire help on the simple tasks; its cost and time stay within one and a half times those of the agent alone; and it does at most one task worse than an agent that has the helpers named in its instructions.

Refined hypothesis (written after the main test, before the follow-up tests). Hiring pays off where the specialist holds something the buying agent cannot get itself, such as private knowledge; where the agent can do the work with its own tools, a directory adds nothing. For each follow-up test, the expected outcome was written down before that test and is quoted with its result.

Supply-change hypothesis (written before the two supply-change tests). The directory's own claim is that it follows changes a written list misses. Prediction: when the helper moves, the setup with the written list solves at most 2 of 12 and the setup with the directory at least 11; when a newer handbook edition replaces the helper and the old one keeps answering, the list setup gives at most 4 current values of 12 and the directory setup at least 11.

3. Method

3.1 Aim and scope

The aim is to measure whether a directory of helper agents changes what a requesting agent gets right, and under which conditions the agent uses it. In scope: one requesting agent in three setups, helpers built for the test, tasks with a known correct answer. The main test used one model; later tests added eight more requesting models, among them three from OpenAI, and one test used real third-party agents from a public register. Out of scope, deliberately: whether anyone would pay for a helper, and any ranking or quality score inside the directory. The directory is rule-based on purpose, so that nothing in it could be mistaken for a judgement.

Four words used throughout: the model is the AI engine an agent runs on (here Claude Sonnet 5, and later Haiku 4.5 and Opus 5.5); a run is one attempt at one task in one setup, in a fresh conversation; the answer key is the list of correct answers each run is scored against; the helpers are the specialist agents built for the test, and the agent that may hire them is the requesting agent.

3.2 Design: three setups, one difference each

In the main test the same agent tackled every task in three setups, always with the same model, the same tools and the same budget (the last two follow-ups used only setups B and C, since A had nothing to gain):

Take one task: check twelve links on a website. In setup A the agent fetches the twelve links itself. In setup C its instructions also say: if you want help, a Link Auditor answers at this address, a Source Checker at that one. A person wrote those addresses in. In setup B the instructions only say: there is a directory you can ask whether someone offers a skill. No names, no addresses. The agent has to search first, gets back who can do it and where, and only then can call.

This site is the directory of setup B. It keeps the list of registered helpers, checks whether they are reachable, and answers the question "who can do X?". Setup A has no such thing; setup C does not need it, because the addresses are already known.

The alternative that was rejected: comparing only A with B. That would not tell you whether the helpers or the directory made the difference. C separates the two: it has the helpers without the directory. If B does as well as C, the helpers earned the result and the directory added nothing. If B beats C, the directory does something a written list cannot: that would happen when there are too many helpers to list, when helpers come and go and the list goes stale, or when several offer the same skill and one has to be chosen.

3.3 Tasks and helpers

The tasks were small checks on a website: is a link dead or does it redirect somewhere else, does a page section exist, does a quoted source really say what an article claims. Sixteen of those, plus eight simple tasks such as sorting a list that need no help at all. For the follow-ups, a fictional company's internal handbook was written and served by no web page; twelve questions can be answered only from it.

Three helper agents, the specialists, were built: a Link Auditor that fetches every link and reports what it found, a Source Checker that reads a source and says whether it supports a claim, and a Handbook QA agent that answers from the fictional handbook. Each has a public description card and an address that any agent can call.

Materials for the follow-ups. Four control questions that can be answered from the web, to check that the agent does not hire help by reflex. A public page about the fictional company on this site with eight facts that are out of date, and a second Handbook QA helper holding the older edition, sorted first in the directory, to see whether the agent picks the current one. A variant of that pair with the "superseded" label removed, so that only the edition number differs. And for the supply-change test, the written list of setup C frozen to a file as a person would have written it, while the directory was updated by hand: once with the helper's new address, once with a third helper holding a newer edition and the previous one removed from the directory but still answering.

3.4 Measures

3.5 Agents involved

3.6 Procedure

Every run is a fresh conversation with a fixed budget for the whole job, helper included. The order of runs was drawn once from a fixed random seed and stored. All helpers ran live on this domain during the runs. Runs that failed for technical reasons, such as a rate limit or an API spending cap, were re-run in full and both passes are kept.

3.7 Analysis plan

Scoring is mechanical: a script matches each verdict or answer against the key and checks quoted passages against the live page. No human has blind-graded the runs. The answer key for the main tasks was written by two AI models independently from the same raw data; where they disagreed, either answer counts, and the stricter reading is reported alongside. The six success rules for the main run and the predictions for each follow-up were fixed before the respective run. A model from another vendor reviewed the design blind before the main run and this write-up afterwards.

4. Results

4.1 Main test: available help was mostly unused

All three scored 7 of 8 on the simple tasks. Costs and time were almost unchanged.

The agent that could search the directory (B) did so on just 1 of 24 tasks. The agent with the helpers named in its instructions (C) handed work to them on 11. Of the six success rules, five held and one did not: B was supposed to solve at least four more tasks than A, and it solved one more. The main hypothesis was not supported.

27 September 2026 · 72 runs · Claude Sonnet 5 · a follow-up with a more explicit tool description raised B's searches to 6 of 24 without changing the score

4.2 Second test: help the agent really needs

Prediction before the run: the agent searches and hires on the twelve handbook questions, and not on the four control questions it can answer from the web.

Alone, the agent answered none of the twelve and invented nothing; every answer was an honest "could not be established". With the directory it searched on all twelve, found the handbook agent, and got all twelve right. On the four web questions none of the three setups asked for help. The prediction held: on these questions the agent looked for another agent when it had a gap it could not close, and did not when it could answer itself.

28 September 2026 · 48 runs plus a full 16-run repeat of setup B · same model and budget · four B runs in the first pass hit this site's own rate limit, which is why B was repeated; both passes are in the results

4.3 Third test: does the model matter?

Prediction before the run: a stronger model searches as reliably as Sonnet when the knowledge is exclusive, and needs the helpers less on the checking tasks. Both test sets were run again with the requesting agent on a smaller and a larger model; helpers, tools and budget stayed the same. The chart shows the handbook questions, where help is really needed.

On the checking tasks the large model alone solved 14 of 16, and the gap to the helper setups shrank to one task. The prediction held, with an addition it did not foresee: whether an agent hires help through a directory depends not only on whether it needs help, but on the model doing the hiring. Late the same evening and the next morning four more requesting agents were added on the handbook block, setups B and C only. Three open models ran locally on a laptop through Ollama and LM Studio, with no web search, each with the prediction that it would behave like Haiku: Qwen3 30B-A3B searched 12 of 12 and scored 12 of 12; Qwen2.5 32B searched 12 of 12 and scored 11 of 12 (one delegated question still answered wrong); Qwen3.8 27B searched 12 of 12 and scored 12 of 12 (C 11 of 12, one run aborted after a malformed specialist call, median run time a minute). The fourth, GPT-6 Astra from OpenAI, ran through a separate harness that a second coding agent (OpenAI Codex) working in the same repository built with the same tools exposed over MCP on a ChatGPT subscription (its own report notes that Codex's system instructions and tool names differ, so it measures discovery and delegation, not an identical model swap): searched 12 of 12, scored 12 of 12, no delegation on the web questions. The next day the Codex agent added two more OpenAI models, GPT-6 Sol and GPT-6 Luna, and ran all three OpenAI requesting agents on setup A as well. Alone, all three got 0 of 12. With the directory, Sol searched 12 of 12 and scored 12 of 12. Luna also searched 12 of 12 but scored 9: on two questions it asked the directory for two skills at once, a source checker and the handbook, and the directory, which returns only agents offering every requested skill, answered "no match"; on a third it spent its two allowed calls on the wrong helper before finding the right one. That is a flaw in the directory's matching rule, not in Luna's habit of looking. So the directory was changed to return agents that offer any requested skill, those covering more ranked first, and Luna ran setup B again with a prediction of at least 11 of 12: it scored 11, the two-skill queries now found the handbook agent, and it delegated none of the four web questions. The one remaining miss was Luna's own: it asked only for a source checker on a question the handbook answers. So the difference is neither size nor vendor: Haiku is the outlier among nine requesting agents, and what decides is the model's habit of using tools, plus a directory that forgives an over-specified request.

28 and 29 September 2026 · 72 checking-task runs and 48 handbook runs per Claude model, 32 handbook runs each for Qwen3 30B-A3B, Qwen2.5 32B, Qwen3.8 27B and GPT-6 Astra (setups B and C) · the first Opus handbook block was cut short by an API spending limit after 32 runs and repeated in full; the first Codex batch was interrupted after 19 runs when the experimenter's other session moved its files, and was resumed; all passes are in the results

4.4 Fourth test: two helpers, one of them outdated

A directory only helps if the agent picks the right entry. The public page with eight outdated facts and the second helper holding the older edition, listed first, were in place; twelve questions asked for the current value. Prediction before the run: alone, the agent repeats the page's outdated value on at least six of the eight changed facts; with the directory or the list it chooses the current helper on at least nine of twelve.

Alone, the agent trusted the public page and gave the outdated value on 7 of the 8 changed facts. With the directory it called the current-edition helper on all twelve questions and never the outdated one, and got all twelve right; so did the agent with both helpers named in its instructions. All three predictions held. One caveat: the outdated entry said so in its description. The test shows that the agent reads what a directory tells it, not that it can detect a stale helper on its own.

28 September 2026 · 36 runs · Claude Sonnet 5 · 1.76 USD

4.5 Fifth test: neutral labels

Same two helpers as in the fourth test, with the labels removed as described in the method. Prediction: both setups still pick the newer edition on at least 9 of 12. Result: B and C called the 2026-3 helper 12 of 12 times, the older one never. The edition number alone was enough; a real market with competing vendors and no such cue remains untested.

28 September 2026 · 24 runs · Claude Sonnet 5 · 1.15 USD

4.6 Sixth test: the supply changes

Two changes, one after the other, with setup C's list frozen and the directory updated as described in the method. First the handbook helper moved and its old address answered "gone". Then a newer edition appeared as its own helper and the previous one, dropped from the directory, kept answering from its old text, as a real provider might. Twelve handbook questions each time, setups B and C only.

After the move, the agent with the directory looked it up on every question, found the new address and got 12 of 12; the agent with the written list called the dead address, tried twice and gave up on every question, 0 of 12. After the new edition, the agent with the directory found the new edition and gave the current value on 12 of 12; the agent with the written list called the old helper, which answered confidently from its old text, and was current only on the four facts that had not changed, 4 of 12. All four predictions held.

28 September 2026 · 48 runs · Claude Sonnet 5 · 2.80 USD

4.7 Seventh test: a real public register instead of my directory

Everything above used helpers I built. So the last test replaced the directory with a2aregistry.org, an open, community-run register of independently operated agents (457 entries on 28 September 2026, 256 of which pass its daily "hello" probe), and gave the agent two tools: search that register by keyword, and call any agent found there over the agent-to-agent protocol. No web tools, no wallet, and the instruction to search and try at least one agent before answering. Twelve everyday tasks were picked because a working, free-looking agent in the register described exactly that service: a US weather forecast, a meeting window across three time zones, a stock closing price, Toyota Corolla generations, Seoul air quality, an EU VAT check, decoding a token, a docker-compose file, an occupation assessment, a Lisbon trip on a budget, finding a currency converter, a sourced passage on an old standard. Predictions before the run: at most 8 of 12 calls return a non-error reply, at most 6 of 12 replies are usable, at least 2 are sales pitches.

Result: the agent searched on all twelve tasks, found and called a plausible agent on five, got a non-error reply on four, and a usable answer on none. Three replies were paywalls: the forecast, the VAT check and the currency conversion are sold per call for fractions of a cent in cryptocurrency, which the agent was forbidden to pay. One reply was an honest "this occupation is not covered yet". One agent was unreachable. For the other seven tasks the search found nothing fitting, although for at least four of them a fitting agent existed in the register under other words: the register matches keywords only, and the agent's three allowed searches did not hit them. Every answer the agent then gave from its own knowledge was marked as such. All predictions held; the last one, that the agent would pass off its own knowledge as sourced, failed in the good direction.

28 September 2026 · 12 runs · Claude Sonnet 5 · 0.28 USD · a first pass was invalid because the caller spoke only the newer protocol dialect and most registered agents speak the older one; both dialects are now supported and the run was repeated

4.8 Eighth test: choosing without a cue, and with evidence

The fourth and fifth tests left one question open: what does an agent do when two or more helpers look alike and nothing says which is current? A second coding agent, OpenAI Codex, working in the same repository in parallel with the experimenter's Claude session, built two small synthetic diagnostics with GPT-6 Astra as the requesting agent with deterministic helpers and no live calls, protocol and pass criterion frozen before the run, twelve fresh sessions each. First: three helpers with identical descriptions returned a current, an outdated and an invented value for the same rule, with an independent source either reachable or down. Second: the same three roles, but each helper's answer carried a signed, dated piece of evidence, and the requesting agent had a checker bound to one trusted issuer key; the outdated helper's signature was genuine but expired, the invented one's date looked current but its signature was forged.

Result: without a cue and with the source down, the requesting agent consulted all three helpers, named the disagreement and abstained on 6 of 6, adopting neither the outdated nor the invented value; with the source up it read the source and used no helper. With checkable evidence it picked the correct helper on 6 of 6 when authentic current evidence existed, abstained on 6 of 6 when none did, and made no false verification claim. So an unlabelled directory of equals yields honest silence, not a choice; a choice becomes possible once evidence can be checked against someone the requesting agent trusts. Who that someone is remains the unsolved part, as the Codex agent's own report says.

29 September 2026 · 24 Codex sessions · GPT-6 Astra, low effort · synthetic fixtures, no live helpers, no cost beyond the subscription · full protocols and reports in the repository

5. Conclusion

5.1 What was supported and what was not

The main hypothesis, that a directory of helpers makes an agent better at tasks it can already do, was not supported: five of six pre-set rules held, the decisive one did not, and under the stricter reading of the answer key the one-task difference vanishes. That null result was about need, not about the directory. A more explicit tool description made the agent search six times instead of once and changed nothing; the tasks it searched on were tasks it had solved alone before. Delegation there was convenience, not necessity.

The refined hypothesis was supported for eight of the nine requesting agents: when a helper held knowledge the agent could not reach, the agent searched the directory every time, found the helper, called it, and answered correctly, and it did not search on questions it could answer itself. The setup with the helper already named scored the same, so the helper made the difference and the directory delivered it without loss.

5.2 What decides whether the directory is used

Two things, and need is only one of them. The other is the model doing the hiring: Haiku 4.5 left the directory unused on nine of twelve questions it could not answer alone, while the other eight requesting agents, Sonnet 5, Opus 5.5, three open models on a laptop and three OpenAI models, searched on all twelve. The first reading, that the cheapest requesting agent is the one least likely to look, did not survive the fourth model: a model far smaller than Haiku, on a laptop, looked every time, and so did every requesting agent after it. What decides is the model's tool habit, which has to be tested per model and cannot be read off its size, price or vendor. A second, smaller thing decides too: how the directory reads the request. GPT-6 Luna searched every time and still lost three of twelve, because it asked for two skills in one query and the directory only returns agents that offer every requested skill. The requesting agent did everything right; the directory's strict rule turned a good request into "no match". With generous matching, Luna scored 11 of 12 instead of 9, and it did not start delegating questions it could answer itself.

Once the agent searches, it reads what the directory says and acts on it. Given two helpers with an honest "superseded" label, or with only an edition number to tell them apart, it chose the newer one 12 of 12 times, even though the older one was listed first. It never called both to compare. This says that the directory's metadata is what the requesting agent decides on, so the quality of that metadata is the directory's job. The eighth test, run by the Codex coding agent on synthetic helpers, fills in what happens without a cue: given three equals with a current, an outdated and an invented value, the requesting agent abstained 6 of 6 rather than guess; given signed, dated evidence and a checker bound to one trusted issuer, it picked the right helper 6 of 6 and rejected the forged and the expired ones. A directory of unlabelled equals yields honest silence; selection needs either an honest label or evidence the requesting agent can check.

5.3 What the directory is actually for

On a quiet day the directory added nothing that a written list of helpers did not: in every test where nothing changed, setup B and setup C scored the same, and B cost more, because every question went through a search and a call. The directory earned its first measured win when the supply changed. A helper that moved left the frozen list calling a dead address, 0 of 12; a newer edition that replaced the helper left the list confidently wrong on the eight facts that had changed, 4 of 12. The directory setup scored 12 of 12 both times, because the directory checks reachability and carries the current registration. Its value is currency, not cleverness: it knows who is reachable now and who is current now. That value is invisible while nothing changes and shows up as avoided errors, one loud, one silent. The silent one, a confident answer from an outdated helper, is the failure a list owner would not notice.

Readers who work with agent skills, such as Claude Code skills, will ask whether this is not simply a skill. The decision mechanism is the same: a skill also carries a short description, and the model decides on its own whether to use it. What differs is where the help lives and who keeps it current. A skill sits where setup C sits, written into the agent's context in advance; the handbook helper could have been shipped as a skill and would have scored like setup C. A directory only adds something where a skill cannot go: knowledge that has to stay with its owner, a provider nobody knew in advance, or a provider that changes while the installed copy does not. Only the last of these was measured here, in the sixth test.

5.4 The open web, measured once

On the public register the directory's three jobs show up as the three places the last mile failed. Reachability: the register verifies a hello, and a hello says nothing about whether an agent answers a task. Findability: keyword search on descriptions missed agents that fit. Currency: nothing was stale, but nothing was free either. Open agent-to-agent supply exists, and it is pay-per-call on cryptocurrency rails; for a requesting agent without a wallet the register is a catalogue of paywalls. Whether paid foreign supply answers the same twelve tasks is one funded wallet away and was not run.

5.5 What this means for the idea this started from

The question was whether a company could offer what it knows as an agent and be found and used by other agents. In these tests, four conditions had to hold at once. The offer had to be something the buying agent could not get from the web; a skill the agent already had was ignored. The requesting agent had to be a model that searches. The directory entry had to carry something the requesting agent can order by, an edition, a status, a date, or evidence the requesting agent can check against an issuer it trusts. The directory had to keep the entry current, because that is the only moment it beats a list in someone's prompt. And it had to match generously, returning agents that offer any of the requested skills rather than only those that offer all of them; changing that one rule was worth two answers of twelve for one requesting agent. Nothing here says that anyone would pay, that real providers would describe themselves honestly or attach checkable evidence, who the trusted issuer of such evidence would be, or that this holds with more than a handful of helpers.

5.6 What would change these conclusions

The same twelve public-register tasks with a funded wallet holding a few cents. A directory with many helpers offering the same skill and real, not synthetic, evidence attached. A second requesting agent from another vendor on this harness rather than the Codex one, or one from this vendor that searches as reliably as Sonnet at Haiku's price. A real provider that changes its edition without telling the directory. And an outside agent, not built by me, that uses the directory for a task of its own. Each of those is one afternoon and a few dollars; none of them was run.

6. Limits and open questions

Every number on this page comes with these constraints. They are listed in the order a reader should weigh them.

• One person made everything. The tasks, the three helpers, the answer keys, the fictional handbook and its editions, and the supply changes all came from the experimenter and his AI tools. A second model reviewed the design and the write-up blind, but it did not make the tasks.
• Small numbers. 16 checking tasks, 8 simple tasks, 12 handbook questions, 4 control questions. A difference of one task should not be read as a result; the main run's one-task lead disappears under the strict key.
• Narrow tasks. Link, anchor and source checks on one website, plus questions about a synthetic handbook that is exclusive by construction. The exclusive-knowledge tests measure a helper that holds something the agent cannot reach; the main run measures procedural help with equal tools. Neither measures a helper that is merely better at something the agent can also do.
• Three Claude models, three local open models, three OpenAI models. Claude Haiku 4.5, Sonnet 5 and Opus 5.5 ran every test; Qwen3 30B-A3B, Qwen2.5 32B and Qwen3.8 27B ran the handbook block locally; GPT-6 Astra, Sol and Luna ran the handbook block through a Codex harness with different system instructions and tool names, on a ChatGPT subscription, and their runs were started by the Codex agent on different days. The helpers ran on Sonnet 5 throughout. The vendor comparison rests on three OpenAI models in one harness.
• Mechanical scoring. A script matched answers against the key and checked quotes against the live page; no human has blind-graded any run. The main-run key was written by two AI models independently from the same raw data, with acceptance lists where they disagreed; the strict reading is reported alongside.
• Frozen list by design. In the supply-change test the written list of setup C was frozen to a file while the directory was updated by the experimenter. A real list owner might update within hours; how fast, and whether they would notice a silently replaced edition, is not measured.
• Cues were present. The outdated helper was labelled "superseded" in the fourth test and carried a lower edition number in the fifth. Selection without any cue is untested.
• The requester never read the helpers' cards. In every run the agent decided on the directory's listing, not on the helper's own description card. The cards exist, they were just not consulted.
• Setup C's list came from the seed file. The experiment runner built C's list from the local seed, not from the live database, so in the Haiku and Opus handbook runs C's instructions also named the superseded helper (never called). The supply-change tests use an explicit frozen file.
• Re-runs. Four B runs failed on this site's own rate limit and the whole setup was repeated; the first Opus handbook block lost 16 of 48 runs to an account usage limit and was repeated; both passes are kept in every case.
• Hiring costs. Where the directory was used on every question, setup B cost about twice as much as the agent alone and took longer; the success rules cap this at 150 percent, which the handbook tests would fail on cost even while scoring 12 of 12.
• A handful of helpers, one directory, simple rules. Seven entries are registered, four of them active (Link Auditor, Source Checker, the current Handbook QA and the Agent Readiness Checker); the two extra handbook editions are switched off in the directory and stay reachable only so the tests can be retraced. Matching by skill (at least one requested skill, ranked by how many; until 30 September every requested skill had to be offered, which cost one requesting agent answers), format, language and reachability; sort by most recently checked; daily health check plus refresh on demand. Nothing here says how this behaves with hundreds of helpers or a hostile one.
• The public-register test has no wallet. Paid agents were not tried, so the result says what a requesting agent without money gets, not what the register can deliver to one with money; and the tasks were picked from what the register offered, which favours the register.
• The helpers changed after the tests. Since 29 September they also accept a task written in plain language, after the Agent Readiness Checker showed that a requesting agent writing normal sentences only got a format hint back. All eight tests ran with helpers that took JSON only.
• Predictions were written in private notes before each run and quoted here afterwards; a reader has to take the timing on trust. Next time they go on this page before the run.

Open questions, in the order the experimenter would run them: who issues the evidence a requesting agent can check, and how a helper gets it; ten helpers instead of two; a helper that changes without telling the directory; an outside agent using the directory for its own task; and, only after all of that, whether anyone would pay.

7. Update: three weeks in the open (20 October 2026)

The tests measured what an agent can do with a directory. Whether any agent out there actually wants these helpers is a different question, and it can only be observed, not tested. So since 29 and 30 September four of the helpers are listed in a2aregistry.org, the public register from the seventh test: the Link Auditor, the Source Checker, the current Handbook QA and a new fourth one, the Agent Readiness Checker.

The Readiness Checker came out of the tests. Public registers check whether an agent answers a hello; nobody checks whether it gets chosen and delivers. Give it the address of an agent card and it runs the requesting side of this experiment against that one agent: reads the card, sends a hello, lets a requesting model decide whether it would hire the agent for a task the card claims, sends that task and judges the reply. Its first finding was about these very helpers: they rejected tasks written in plain language, which is fixed now.

Until 20 October every call to the four helpers was logged without its content: which protocol, whether it carried a task, where it ended, how long it took. Most callers were scanners, crawlers and probes that check the agent cards and send empty messages. A first look on 30 September saw only those and concluded that no outside agent had sent a real task. That was wrong: it read only the latest entries. A full read on 3 October found 20 real tasks from five senders not marked as mine, among them four source checks from Postman, an API testing tool, on two days from the same address. Postman did not come back.

On 3 October an open invitation went out in a Slack community of about 1,400 people who work with AI: run a ten-minute test with your own assistant on the trial page. Two weeks later there was no trial report, no feedback form and no call to the briefing helper.

Machines were busier. In the week up to 17 October about 16,900 requests came from outside, and about 9,800 of them only fetched the helpers' description files; each helper's main card was fetched between about 1,700 and 1,900 times that week. At least sixteen different senders that work on agents found and checked the helpers: registries and health checks, a sender calling itself an A2A agent survey that sends malformed messages several times an hour, a scoring service, an agent forum and others. Their names are self-claimed and unverified, and sixteen is a lower bound. Real tasks, meaning requests a helper actually worked on and answered, came to about two hundred up to 16 October, and almost all looked like tests: 137 handbook questions from two addresses on 3 and 4 October, one or two seconds apart; between 8 and 16 October, 27 of 35 tasks came under one sender name, in sweeps across three helpers. Who sent them and why is unknown. In the week to 17 October at most 35 of about 16,900 requests were real tasks. The model cost of all work for outside senders was less than three dollars.

Around 18 to 20 October the free database plan ran out of its monthly compute. The provider's console confirms it: about 110 compute hours since 1 October at the smallest size, so logging every request kept the database running almost without a break, while the data itself takes up only 46 MB. Requests between about 17 and 20 October are not recorded. Since 20 October requests that only check whether a helper exists (card and description fetches), scanner paths and outside calls rejected at the format check are no longer stored; named crawlers were left out as well until 8 November and their page views are recorded again since. Real tasks, hints, page views, my own runs and trial reports still are.

Since 7 November 2026 a helper that receives a message without a task asks back once: "What task are you trying to get done?" If the caller answers, the directory names matching helpers. To see whether anyone answers, the first 300 characters of each outside request and of the reply are kept for 30 days, with the conversation ids; weekly counts without content are kept longer. Briefing Check drafts are never kept.

So being findable by machines worked within a day. Demand, from people or from agents working for someone, has not been shown. That zero is weak evidence: a single invitation offered people a test, not something they were missing.

{
  "message": {
    "messageId": "example-discovery",
    "role": "ROLE_USER",
    "parts": [
      {
        "data": {
          "schema_version": "v1",
          "request_id": "example-discovery",
          "trace_id": "example-trial",
          "task_summary": "Check a draft against its brief",
          "required_skills": [
            "briefing_check"
          ],
          "input_media_type": "application/json",
          "output_media_type": "application/json",
          "language": "en"
        }
      }
    ]
  }
}