In late 2026, two researchers tested something any company that has put an AI assistant in front of several departments recognizes from experience: what happens to that assistant's accuracy as the catalog of connected tools it can reach keeps growing. They started from a real production assistant with 110 specialized helpers and 584 connected tools, and measured accuracy as the catalog grew from 10 to 110 helpers — how often the assistant picked the right tool for vague requests — the kind an actual person types on an actual day.
The result: across three different AI models, accuracy dropped between 16 and 23 percentage points as the catalog approached real-world corporate scale. The authors split the problem into two parts. One is the assistant simply failing to locate, among so many similar options, the right tool for that request. The other is subtler: even when the right tool is right in front of it, the sheer number of similar options confuses it — accuracy under the best possible scenario also dropped by roughly 10 points.
Neither problem is a lack of intelligence in the underlying AI model. It's a design problem. And it's the same design problem that stops a new hire in their tracks when someone hands them the entire company manual and says "figure it out" — without saying which routine, which system, and who needs to sign off on what first.
A growing catalog, a shrinking accuracy
A recent piece on tool design for AI assistants, published by the specialized outlet Machine Learning Mastery, points to the same pattern in a different experiment. When researchers compared giving an assistant access to an entire tool catalog at once against automatically filtering it down beforehand to only what's relevant to that specific request, tool-selection accuracy more than tripled — from 13.6% to 43.1% — while the size of the instruction sent to the model was cut in half.
The technical explanation has two parts, but the practical effect is a single one. First, every described tool takes up room in the assistant's reading capacity before it even reaches the person's actual request — the same coverage estimates that the list of available tools alone can consume 5% to 7% of that capacity. Second, when the list is long, the assistant tends to lose track of the options buried in the middle of it, an effect already documented in research on how AI reads long stretches of text. The result is predictable: the wrong tool gets picked, or the right one gets picked with the wrong details filled in.
None of this is a one-off glitch. It is the expected behavior of any system — human or not — forced to choose among many similar options with no tiebreaker at all. An assistant with access to 80 different functions to "help with whatever comes up" is not more useful than one with 6 well-chosen functions for a specific routine. It is less useful.
More access confuses, it doesn't fix
The most intuitive fix, when an assistant gets something wrong, is usually the wrong one: give it access to one more tool, one more system, "just to be safe." It's the corporate equivalent of solving someone's indecision by adding more items to the menu.
Anthropic, one of the companies building these AI models, published engineering guidance pointing the other way: instead of turning every function of a system into a separate tool, the advice is to build a few thoughtful tools, each with a clear and distinct purpose, aimed at the routines that actually matter. The guidance even gives a concrete example: instead of exposing three separate tools to list contacts, list events, and create an event, expose a single tool that handles the entire scheduling task end to end. Tools that overlap, the same guidance notes, distract the assistant from choosing the most efficient path — they don't add freedom, they add noise.
In practice, inside a company, this means the assistant that promises to cover finance, HR, and sales at once, with one generic brief and access to everything "just in case," is not the most powerful assistant in the building. It's the least precise one. And the cost of that imprecision doesn't land on the technology team — it lands on whoever acted on the wrong answer before finding out it was wrong.
What has to be in place
A trustworthy AI assistant is defined by how it was designed, not by how many tools it can reach.
A specific brief per routine. The instruction should be written as if training a new hire for that exact role: what task, in what tone, delivering what format of answer. "Help with whatever comes up" is not a brief — it's the absence of one.
Access, function by function. Each assistant sees only the functions of the routine it covers within a connected tool — not the entire tool, granted because splitting the functions apart "was more work."
Layered scope. An assistant can start as someone's personal experiment, prove it works, and only then "graduate" to team-wide or company-wide use — with approval at every step of that promotion, never by default.
Approval based on risk. Sensitive actions — sending, approving, deleting, changing a value — should pause and ask a person to confirm before proceeding, even inside a routine that is already well-defined and tested.
A named owner. Every assistant needs someone responsible for periodically reviewing its brief and its access. Without an owner, every specific assistant tends, over time and through one-off requests, to drift back into the generic do-everything assistant the research shows doesn't work.
This is how Skyller was designed: every assistant carries a scope, an access role, and an owner defined from the moment it's created, with more than 100 pre-configured agents for common routines available as a starting point — not one generic assistant holding every key at once.
Specialist beats generalist, in practice
The easiest gain to notice is accuracy: an assistant with six well-chosen functions for a specific routine makes fewer mistakes than one with eighty functions "just in case." But the gain that usually settles the internal debate is a different one.
When an assistant is designed for a specific routine, it becomes easy to trust — and easy to hand off to someone else to run the same way, at the same quality, without that person needing to understand how it was built under the hood. It's the difference between a team where only one person knows how to do the monthly close correctly and a team where the right way to do it has become something anyone can trigger.
There's also a less-discussed gain: a narrow-scope assistant is cheaper to run, because it processes less text per request, and easier to audit later, because the range of things it could have done is known and small. A generic assistant with broad access is the opposite on both counts — more expensive per conversation, and harder to explain, during an investigation, exactly what it did and why.
A checklist for the next helper you build
Before creating the next AI assistant for the team, it's worth running through this list:
- List the routine before listing the tools. Start from the repetitive task that eats the most of the team's time, not from the catalog of systems already connected.
- Write the brief like training material, not a loose request. Describe the task, the expected tone, and the answer format with the same care used to train someone new on the team.
- Grant access function by function. Before checking the box for an entire connected tool, confirm which specific functions that routine actually uses.
- Define what requires human approval. Any action that changes something outside the conversation — sending, approving, deleting — should pause and ask for confirmation before it happens.
- Name an owner and schedule a review. Someone needs to be responsible for noticing when that assistant's brief or access has gone stale.
