Tool sprawl vs a tool matrix: give each agent role only the tools its job needs

Each AI agent should have access only to the tools, operations and records its role needs. A researcher may need public search and somewhere to save findings. That gives it no reason to change a client record or invite someone to a meeting.

Tool sprawl starts when tools are connected to the platform or session as a whole rather than to a role. Access then accumulates across task types without a matching permission boundary. Each connection has an explanation. Together, they let one role act far beyond its job. Giving agents separate names does not fix this if they inherit the same connectors.

A tool matrix records the boundary: which role may use which operation, on which resources, and under whose approval. Chapter 5 of The Agent Dream Team teaches it as part of ROSTER’s Skills and tools step. The distinction is between access that happens to be connected and access you can justify against an agreed output.

Which tools should each AI agent have access to?

Start with the outputs in the role’s agent charter. For every proposed permission, ask: which agreed output would this role be unable to deliver without it?

A public research brief needs access to public sources and a place to save the brief. Editing a supplied draft needs the draft and editing access. Scheduling an approved meeting needs calendar access. The role’s job determines the tools, even when the same model powers all three roles.

Apply the test to operations, not just services. “Document storage” is too broad. Reading source notes, creating a summary in research/, overwriting a contract and deleting a folder are separate permissions. Name the resources the role may touch and whether it may read, create or change them.

Start each role with an empty tool set. Add what its outputs require. If a task falls outside the charter, it goes back to you or to the role whose charter covers it. Expand access only after deciding that the job itself has changed.

What belongs in a tool matrix?

Put roles across the top and tools or operations down the side. Use explicit entries: no access, read, write within a named boundary, draft only (founder sends), or execute after human confirmation. Keep drafting separate from sending.

Beside every grant, record:

• The output that requires it.
• The permitted operation and resource.
• The control that enforces the boundary.
• The person and mechanism for approval, where required.
• The grant date and next review date.

Record the role’s current trust level alongside its access. A list of connected services cannot tell you whether the editor may change source notes or whether a calendar write needs confirmation. The matrix should make those decisions readable without reconstructing the setup conversation.

A human gate does not justify an otherwise unnecessary tool. First establish that the role needs the operation. Then decide how execution is controlled.

Worked example: from shared connectors to scoped roles

This example is hypothetical, adapted from chapter 5’s starter roster. A solo founder needs a competitor brief, a newsletter draft and help arranging meetings. The Research Specialist, Draft Editor and Ops Coordinator initially inherit the same search, document, calendar, inbox and CRM connections.

The first audit asks what each role actually produces. The research brief requires public sources and summary storage. The newsletter role needs reviewed summaries and a draft folder. Meeting preparation belongs to the Ops Coordinator. Neither a competitor brief nor a newsletter draft requires CRM access.

Here is the proposed replacement:

Tool or resource	Research Specialist	Draft Editor	Ops Coordinator
Public web search and page retrieval	Public research only	No access	No access
research/: public-source summaries only	Read and write summaries	Read	No access
drafts/: internal newsletter drafts	No access	Read and write drafts	No access
Calendar	No access	No access	Read; founder confirms every write
Private task list	No access	No access	Read and write
Internal pending-send/ folder	No access	No access	Create message drafts
Inbox and email send	No access	No access	No access
CRM, payments and publishing	No access	No access	No access
Current trust level	L2	L2	L2

For this illustration, assume each role has completed onboarding at L2 under the book’s rules. Outputs ship only when they meet written conditions you can check outside the model; everything else is flagged for your review. Consequential actions still need confirmation.

Now run a task through the proposed design. The founder asks what three competitors include in their entry plans and what each plan costs. The researcher uses public pages and writes research/competitor-brief.md. After the founder reviews it, the editor reads that file and writes drafts/newsletter.md. If a price is missing, the editor sends a research question back to the researcher. It gets no search connector of its own to meet the deadline.

The Ops Coordinator works from a separate founder brief. It proposes a meeting and waits for the founder to confirm the event, time and attendees before anything changes in the calendar. It writes any accompanying message in pending-send/; the founder reviews and sends manually. No folder in this example triggers a send or publication.

Keep client briefs and confidential records outside the research folder. Enable version history for private drafts and task-list changes. Enforce the folder permissions: the researcher must not overwrite the newsletter, and the editor must not rewrite the evidence it received.

The finished brief, draft and meeting proposal remain possible. The unrelated access comes out.

Where is the permission boundary enforced?

Chapter 5 distinguishes three levels. Write down which one supports each matrix entry.

Native enforcement: the platform or runtime blocks a role from calling tools outside its permitted set. The restriction works independently of the model’s willingness to comply.

Workflow enforcement: the role proposes an action, while execution sits behind a separate approval step. A message draft that only the founder can send is one example.

Procedural enforcement: the charter forbids an action that the connected tools would still permit. This depends on the model following instructions. The book treats it as a temporary control and calls for founder review before anything leaves the role.

Where you have only procedural enforcement, disconnect dangerous tools or move execution into a separate gated workflow. A folder name or file prefix can help you notice a violation; it cannot prevent one.

Check the actual configuration against the matrix. A successful connection test does not establish that a forbidden operation will be refused. For remote MCP servers, MCP OAuth is not tool authorization explains why a valid token does not decide what a tool call may do.

Approval must identify the action that will execute, including its destination, content and affected records. Approving a filename is insufficient if its contents can change afterwards. Require fresh approval for a changed action. Without confirmation, execution stays blocked.

Which actions need a human gate?

Chapter 5’s default is human confirmation for email sends, external calendar changes, file overwrites, CRM modifications, payment or billing actions, and publishing. The practical question is what undoing the action would cost, including consequences already visible to someone else.

Its action table separates five classes across the Agent Trust Ladder: internal reads (up to L5, logged), reads from untrusted sources (capped at L4, with the source recorded in the output), private, reversible writes (capped at L4, with version history on and a weekly report), shared writes or changes costly to reverse (capped at L3, with founder confirmation before execution), and external, public, financial or legally binding actions (capped at L3, confirmed every time). Updating a private draft with version history belongs in the third class; overwriting a shared document belongs in the fourth. State that boundary before granting write access.

A higher level for routine work never removes an L3 confirmation gate on consequential actions.

Trust belongs to the role, not the model. It governs autonomy within the permitted scope; it does not add tools. Under the book’s rules, adding a tool changes the charter and resets the role to L2 or below. Evidence from the old assignment does not establish how it will handle the new access.

These levels and ceilings are the author’s operating policy, not tested reliability thresholds.

Can a read-only tool carry information outward?

Yes. Chapter 5 identifies an easily missed path: an external search query or fetched URL leaves the system. A role holding a private client brief could include its contents in a query, despite having no email-send permission.

For each role, check the combination of private data, untrusted input and an outward channel. Then follow the handoffs. Dividing capabilities between two agents does not close the path if the first can pass untrusted instructions to the second as authority.

In the hypothetical roster, the founder supplies a public research question without client identifiers or confidential details. Keep that browsing step separate from private context, including stored files the researcher could read. Where your platform supports restrictions on queries and destinations, enforce them. A request to “be careful” remains procedural.

Treat retrieved text and handoff content as material to assess. Neither changes the receiving role’s permissions.

How often should you audit the matrix?

Chapter 5 calls for a weekly check for unexpected tool use and a monthly audit. They answer different questions. The weekly question is whether any role invoked a tool in a way that surprised you. A surprise is a signal: either the role worked correctly and the matrix needs updating, or the role acted outside its charter and the tool comes out.

At the monthly audit, compare the matrix with the configuration. Does every permission still support an agreed output? Are shared resources still bounded? Has a connector changed its tools, scopes or descriptions since you approved it? If you cannot tell, treat it as changed.

The book also asks for a short review of every permission older than ninety days, which is why each grant carries a date. This is a review trigger, not automatic expiry. Permissions that pass stay; those that fail are removed or gated. Date the decision.

Those intervals are maintenance rules, not evidence of an optimal audit frequency. Update the matrix when a role gains a tool or its mandate changes, rather than waiting for the next calendar entry.

Try this today

List every tool or connector your agents can reach. Next to each, write the role that needs it and the output it supports. Include inherited access. Every tool without a role is removed this week.

Then test one role:

1. Write its minimum permissions. Split each connector into operations and resources. Compare what the role currently holds with what its outputs require. Remove the surplus.
2. Isolate the test. Use dummy files and a test environment with the same relevant permission rules. Keep customer records and live destinations out of reach.
3. Prove an allowed operation works. Using the role’s access, save a dummy summary in its permitted folder. Inspect the saved file and execution record.
4. Attempt a forbidden operation. Using that same access, attempt a harmless write to a dummy file outside the permitted folder. Require evidence that the permission control refused the write and that the target stayed unchanged. A model choosing not to try does not establish enforcement.
5. Test one approval gate. Replace the consequential action with a harmless logged action while retaining the approval checks. First approve a request and confirm it executes. Then submit a fresh request, withhold approval and inspect both its state and execution record. It must remain blocked or expire without execution.

If a check cannot be run, record not run. If the records cannot establish its result, record unverified. Keep consequential execution disconnected until its boundary is established. The separate agent stop drill checks whether you can interrupt the run and revoke access.

File the dated matrix beside the charter, with the test results, unresolved permissions and next audit date. A pass supports the specific operation and configuration you tested. It does not certify the whole roster.

Cite this:Tool sprawl vs a tool matrix: give each agent role only the tools its job needs.Len P. van der Hof. https://lenvanderhof.com/en/blog/tool-sprawl-vs-tool-matrix/ · Published 7 November 2026.