Revised October 19, 2026.
“Move my meeting to Friday” sounds like a small request. The assistant still needs to find the right event, decide whether “meeting” means one occurrence or a series, and establish whether changing it will notify other people.
As more applications become available to an agent, finding a calendar tool becomes a smaller part of that problem. There may be several operations with similar names and quite different consequences. I want to make an ordinary request without having to explain the integration catalog first.
In Maya, I call the work of finding and presenting the capabilities needed for a task Progressive Capability Discovery, or PCD. The aim is to give the agent enough to proceed without putting the entire tool library in front of it for every request. That choice has to earn its place by helping the task succeed.
A connected system needs a way to choose
Someone can connect mail, a calendar, documents, and other services because each is useful occasionally. A question about tomorrow’s commitments still does not need instructions for every operation in every connected application.
Tool descriptions occupy space alongside the request, relevant evidence, and conversation. A large catalog can also put superficially similar choices next to one another: find an event, edit an occurrence, edit a series, or send an invitation. The system has to distinguish those choices even if the person asking never sees them.
PCD lets a broad library remain available while presenting a more relevant set for the task at hand. In the meeting example, that should help the agent find the event and the appropriate ways to change it. The point is to make the next decision easier without hiding a capability the task will need later.
This is a shared engineering problem. Anthropic’s advanced tool use article and tool-search documentation describe deferred loading and searching for relevant tool definitions. That work provides useful comparison material for thinking about discovery; Maya’s implementation and its results need to be assessed on their own.
Finding a tool leaves two more questions
A tool can be a good match for the request and still be unusable. The calendar connection may have expired, or the current session may not have the access the catalog description implies. Finding the entry does not repair the connection.
Even a working connection leaves the question of what the person authorized. Changing a meeting may send notices to every attendee. If the person only wanted to explore another time, a technically successful edit would produce the wrong outcome.
I keep relevance, availability, and authority distinct when reviewing this part of an agent because each resolves a different uncertainty. Discovery identifies what could help, while execution checks establish what can run now. The requested task and the applicable controls still determine whether this particular action is allowed.
The person should be able to tell the difference too. A proposed change may await a decision; an attempted change may fail. Reporting that the meeting has moved requires a result from the calendar, not a plausible plan or a successful search for a tool.
A smaller selection can miss something important
Discovery adds a failure mode of its own. The initial selection may omit the capability the task needs. A description might be incomplete, the request ambiguous, or the available catalog different from the one used in an earlier evaluation.
For a narrow workflow, I would often start with a fixed tool set. If the same few operations reliably cover the job, a discovery step creates more work and another place to fail. A smaller prompt is not a sufficient reason to introduce it.
Maya’s broader personal environment makes selective discovery worth exploring, but recovery belongs in the design. The assistant needs a way to recognize an inadequate selection, reconsider what it needs, or come back with a useful question.
Take the meeting series again. If the first selection offers only a single-event edit, the assistant should notice that it cannot yet carry out a request to move every occurrence. Editing the first event and reporting success would conceal the missing capability. Asking which occurrences are intended, or finding an appropriate series operation, would move the task forward honestly.
A remembered capability can outlive its connection
A catalog describes what an integration is meant to do. It does not establish the integration’s current health. The application may be unavailable, access may have changed, or the destination may reject a request that worked yesterday.
This makes discovery part of operating the system. When an operation fails, the assistant needs enough information to explain whether anything changed and whether another attempt is appropriate. If a request reached the destination but its acknowledgment was lost, a blind retry can create a duplicate action.
That is a different problem from selecting the wrong tool, and it deserves its own test. A demonstration that finds the correct operation once can leave both connection failures and uncertain outcomes unexamined.
Anthropic’s code execution with MCP is related reading on progressive disclosure and managing what enters the model’s context. I take from it a practical design question: how much does the model need to see at this point in the work? The answer can change as the task develops.
Measure the outcome, including the recovery
A discovery evaluation should include an ordinary success, a missed initial selection, an unavailable connection, and a request the assistant should withhold or clarify. Synthetic inputs make it possible to define those outcomes without sending real messages or changing someone’s calendar.
Compare the result with a sensible baseline. Count any additional discovery calls, retries, and recovery work when assessing cost or latency. Record the task set, tool catalog, and relevant model and tool versions alongside comparisons of task outcomes, cost, or latency. A token reduction that comes with more incorrect or unfinished tasks would be a poor trade for a personal OS.
The final status needs to agree with the destination, including when the result remains uncertain. If a calendar edit reached the service but no confirmation came back, reporting success would hide a problem the person may need to resolve. If nothing changed, the assistant should say that plainly. Discovery has to support this operational clarity to be useful to someone relying on the result.
For Maya, the goal is to let me ask for something in ordinary language while the system works out an appropriate means of helping. When the first selection is imperfect, can the assistant still reach the right outcome without exceeding the authority it was given?
Related reading
Personal Cognitive Digital Twins: when memory needs judgment
Discover more from Ajith Vallath Prabhakar
Subscribe to get the latest posts sent to your email.