Blog

The 46-Tool Agent: Why Modularity Beats Monolithic Agents in Production

SVP of AI Strategy & Innovation

The 46-Tool Agent: Why Modularity Beats Monolithic Agents in Production

Key Points

- A single agent given 46 tools for a 9-step OS upgrade completed 70% of the job on its first run, climbed to 92% with tuning, then started going off the rails.
- More tools and instructions crammed into one agent does not produce more capability. It produces more chances for the agent to guess wrong.
- Breaking the same 46 tools into 8 modular, scoped agents took performance from inconsistent to 100% on every run.
- The File Transfer Agent, Alarm Suppression Agent, and Validation Agent are reusable across firmware upgrades and config pushes for other vendors and use cases.
- Modular agent design applies the same discipline that already governs orchestration at scale: modular, reusable, explicitly scoped components instead of one component doing everything.

Give an agent one goal, nine steps, and 46 tools, and it will try to do the whole job at once. That is exactly what we built with one of our AI Innovation Program customers: a single OS Upgrade Agent, fed a full runbook and pointed at every tool it might need to identify the right OS, download the image, distribute it, suppress alarms, execute the upgrade, and validate the result.

It worked. The first run, it completed about 70% of the job correctly. We tuned it and it climbed to 85%, then 90%, then 92%. Then it started going off the rails.

90% Is a Great Demo, It’s Not a Production Number

Automation does not get graded on a curve. A workflow either does the whole thing correctly, every time, or it does not ship. Agents do not get a pass on that standard just because they can reason. If anything, the bar is higher, because an agent is making tool selections a static workflow never had to make.

Think about what you are actually doing when you hand an agent a full runbook and every tool that touches it. You are telling a new digital coworker, here is my entire house, here are all the tools in the garage, go build me a house. It will try. It might get you a house. It might also get you a house with no door, because nobody told it doors matter, and it had 46 tools to choose from and no boundary on which ones belonged to which step.

💡 That is context overload, and it is not a training problem. It is an architecture problem.
More tools and more instructions crammed into one prompt does not produce more capability. It produces more chances for the agent to guess wrong.

Same Total Tools, Grouped by Intent

The fix was not fewer tools. It was the same 46 tools, reorganized around intent instead of stacked onto one agent. We broke the OS Upgrade Agent into 8 specialized, modular agents, each mapped to one or two steps in the original runbook and scoped to only the tools that step needs:

Recommendation Agent: step 1, OS identification
File Transfer Agent: steps 2 and 3, image download and multi-SCP distribution (reusable)
Profile & Inventory Agent: step 4, OS profile creation
Alarm Suppression Agent: step 5 (reusable)
Execution Agent: step 6, upgrade execution
Validation Agent: step 7, pre and post checks (reusable)
Audit & Compliance Agent: steps 8 and 9, delta analysis, audit, status, and closure

Before	After
One agent, 46 tools, 9 steps, no clear line from any step to any tool	8 modular agents, same 46 tools total, each scoped to 1 or 2 steps
Every tool available to every step, all the time	Each agent sees only the tools its step requires
Works 70 to 92% of the time, then drifts	Each agent works consistently, every run
Rebuilt from scratch for the next use case	File transfer, alarm suppression, and validation agents reused across firmware upgrades and config pushes

One Superstar vs. a Team of Superstars

You would not build a team with a single generalist and call it done. You would not hand your electrician a nail gun and ask them to also do the roofing. The same logic applies to agents. When you build specialized agents with tight context and a narrow, explicit toolset, they stop guessing. They do not have 46 options to sort through when the job only ever needed three.

That is the actual math behind modularity. Instead of one agent that does the job 90% of the time, you get nine agents that each do their piece 100% of the time, consistently, on every run.

💡 That is how you scale agentic operations.
Not by making one agent smarter, but by making the boundaries around each agent smaller.

Reuse Is the Real Payoff

Break a monolithic agent into specialized pieces and something else happens along the way: parts of it become reusable. The File Transfer Agent, the Alarm Suppression Agent, and the Validation Agent from the OS Upgrade workflow are not locked to OS upgrades. They apply just as well to firmware upgrades and config pushes for other vendors and use cases.

This is the same lesson every automation team has already learned once. A script that keeps growing to handle one more requirement eventually turns into an unmanaged application nobody wants to touch.

Workflows that grow to 70 or 100 tasks deep get chunked into reusable, modular pieces for exactly this reason. Agents are not exempt from that lesson. If anything, they make the payoff bigger, because a well-scoped agent becomes a standing capability you can run on a schedule, like a CVE assessment agent that checks your fleet against new vulnerabilities every day, independent of whether you are upgrading anything that day at all.

Build It Like You Would Build Anything Else at Scale

None of this requires a different way of working. It requires applying the same discipline that already governs orchestration at scale: modular, reusable, explicitly scoped components instead of one component trying to do everything. Teams already building agent projects on the Itential Platform can structure their agents exactly the way they structure workflows today, as reusable building blocks that combine into a larger system instead of a single agent carrying the whole runbook alone.

💡Production Agents Are Built to Meet Goals at 100%
Because in production, 100% of the time is not a stretch goal. It is the bar our customers set for us, and it is the bar modular agent design is built to meet.

Watch the Session

Director of Customer Success, Holly Holcomb, and I covered this in a session that covered lessons from the AI Innovation Program and the full path to get agents in production safely. The full recording is available to watch on-demand here or below.

Karan Munalingal

Karan Munalingal is the SVP of AI Strategy & Innovation at Itential. Previously, Karan ran systems engineering at Ciena, focusing on carrier ethernet and core switching platforms. At Itential, Karan drives AI strategy enabling global customers to adopt AI-driven automation journeys that modernize and scale network and infrastructure operations.

Keep Learning

The Latest in Agentic Operations

Webinars

Building Production-Ready Agents for Network Infrastructure

Watch now

Blogs

Why Agent Sprawl Is the Next Script Sprawl

Blogs

AI Agents Don’t Earn Trust, They Inherit It

Demos

From CVE to Coverage: Automating Vulnerability Impact Analysis with FlowAgents

Watch now

Blogs

Build Time vs Runtime in Agentic Operations

Frequently Asked Questions

–+

Because it is context overload, not a training problem. An agent given a full runbook and every tool that touches it has to guess which of those tools applies to each step. More tools and more instructions crammed into one prompt does not produce more capability. It produces more chances for the agent to guess wrong, which is exactly what happened when a single agent’s performance climbed from 70% to 92% and then started going off the rails.

–+

A monolithic agent is a single agent given an entire multi-step runbook and every tool it might need, all at once. A modular architecture breaks that same runbook into specialized agents, each mapped to one or two steps and scoped to only the tools that step requires. The total tool count does not change. How it is organized does.

–+

Yes. Once an agent is scoped narrowly enough to do one job well, it stops being tied to the workflow it was built for. The File Transfer Agent, Alarm Suppression Agent, and Validation Agent built for an OS upgrade workflow apply just as well to firmware upgrades and config pushes for other vendors.

–+

As few as the step it is responsible for actually requires, not every tool available across the whole workflow. In the OS Upgrade example, that meant going from one agent with 46 tools to 8 agents each scoped to only the tools its one or two steps needed.

Get Started

Agentic infrastructure operations starts here.

See how Itential connects AI reasoning to governed execution across your entire infrastructure.

Talk to our Experts

Home
Resources
Blogs