Internal AI-Agent System Access Triage Automation: Routing Fixed by Real Tool Inventory, Not by Job Title

A multi-agent team chat that routes questions to whichever specialist sounds most relevant is a genuinely useful shortcut most of the time — most questions really do belong to the agent whose role obviously covers them. The shortcut breaks down precisely on the question type where it matters most to get right: "who has access to this system?" is a factual question with one correct answer, and a role description was never meant to answer it. A security specialist reasonably sounds like it might have broad access to many systems by virtue of the job — but sounding relevant and actually holding the tool are two different things, and only one of them is true.

A roster built to describe agents in human terms — title, summary, general area of ownership — is the right data for routing a general question about who handles a topic area. It's the wrong data for a question with a hard factual answer, because a title is a description someone chose, while actual tool access is a fact recorded in the system's own permission tables. Any routing decision built entirely on the descriptive layer will occasionally produce a wrong answer that sounds completely reasonable, precisely because titles are written to sound reasonable — the gap only becomes visible when someone asks the specific factual question the description was never meant to answer.

The defect surfaced through a real conversation, not a test case: an owner asked the internal team chat who had access to a specific module, and triage handed the question to the security specialist agent, who answered that it had access — while holding zero tools for that module. The very next message, asking that same agent to actually use the access, forced the truth out: it had none, and passed the request along to a second agent, who confirmed the same thing a second time before anything could actually happen.

The fix changes what data the routing decision has available, not just the prompt wording around it. A new database function computes, for every agent in the roster, the real list of modules its currently available tools touch — read directly from the same permission tables that decide what an agent can actually call, not from any manually maintained description. The computation deliberately excludes the handful of baseline modules every agent shares, so the resulting list only shows what actually distinguishes one agent's access from another's. That computed list is attached to each roster entry as a new field the triage model sees on every routing decision, alongside the existing title and summary it already had.

The triage prompt then adds one explicit rule addressing exactly the failure that occurred: a question about a specific system should be routed only to whichever agent's computed list actually contains it, and an agent without that system in its list should not be chosen to answer — even when its job title sounds like a reasonable fit. This is paired with a matching rule in each individual agent's own instructions: an agent may only claim it has access to a system if a tool for that system is literally present in its own tool list, never inferred from how closely its job description sounds related to the topic.

The fix doesn't rely on the prompt rule alone to hold up over time — an executed proof embedded in the same migration checks the real, computed output directly: it looks up the security-role agent's own roster entry and asserts its module list does not contain the module from the original incident, then looks up the agent that actually holds the relevant tool and asserts its list does contain it, raising an exception if either check fails. That means a future change that accidentally broke the computation, not just the prompt, would be caught the next time this migration's tests run.

Someone asks the internal team chat who has access to a given system. Before the fix, the answer depended on which agent's job title sounded closest to the topic. After the fix, the routing decision checks each agent's actual, computed tool-derived access list — and an agent whose role sounds related but whose tool list doesn't include that system is passed over in favor of the one whose list actually does.

A question about which specialist can actually act on a given system gets an answer grounded in the same permission data that governs what an agent can really do, not in how convincing its job title sounds. That removes a specific, already-observed failure mode — an agent confidently claiming access it doesn't have — and does it for every system in the roster at once, rather than only for the one module involved in the incident that surfaced the gap.

This fix is specific to routing questions about system-level access inside Centriu's own internal multi-agent team chat — it is not a general-purpose access-control mechanism for a client-facing product, and it does not change what tools any individual agent actually holds, only how correctly a routing decision reflects those existing tools. A team looking for a general recommendation engine that suggests which agent to talk to for open-ended, non-system-specific questions will find that this rule is scoped narrowly to the "who has access to X system" case, not a wholesale replacement of the existing role-based routing for every other kind of question.

Routing a factual access question by job title treats a human-written description as if it were a permission record — reasonable most of the time, and silently wrong exactly when it matters most. Centriu's fix replaces that guess with a value computed directly from the same tool-permission data that governs what an agent can actually call, checked by an executed test against the specific real incident that exposed the gap, so the routing decision for a system-access question is now grounded in a fact rather than a plausible-sounding title.