Beyond the skill library – choosing the right expertise for agentic AI (Reader Forum)

In enterprise network operations, the value of agentic AI depends on whether agents can bring together the right expertise, tools, and evidence for the problem at hand.

It’s easy to create something that looks like an AI agent: give a model a prompt, connect it to a tool or a set of documents, and ask it to handle a task. The harder question is whether it knows what to do next, and if it’s using the right evidence.  When it doesn’t, failure is rarely obvious.  Instead, the agent gives a confident answer, and someone acts on it.

Agentic skills are one way to close this gap between a plausible response and an answer grounded in the right evidence. A skill is more than a prompt, a document, or an API call. At its best, it packages expertise into a reusable workflow: what information to gather, which tools to use, how to interpret the results, and what to do next. 

In practice, many skills describe the task but leave tool choice and result interpretation to the model, making outcomes less consistent. The agent coordinates the skills; the tools provide the capabilities, and the skills guide how they’re used.

But simply giving an agent more skills won’t automatically make it more capable. What matters is whether it can compose the right skills around the intended outcome and use the skills selectively as the situation unfolds.

From one broad skill to a coordinated investigation

Consider a user who can connect to Wi-Fi but can’t start a video call. A skill built only to check wireless connectivity might confirm that the user is connected, but it won’t explain why the call isn’t working. The problem could involve wireless conditions, identity, DNS, routing, a service provider, or the application itself.

A better approach starts with a broad troubleshooting skill that establishes what is happening: Is the issue real? Is it an outage or degraded performance? Who is affected? From there, the agent can call more focused skills to investigate the areas that fit the evidence.

If one user is affected, for example, the agent might examine that user’s wireless connection and relevant access services, such as DHCP, DNS, or authentication. If those look healthy, it can follow the service path toward the application itself and examine relevant network and provider dependencies. If several users across a site are affected, the agent can skip the individual client checks and look at what those users share locally, such as the site’s DHCP, DNS, or authentication servers, or its security gateway. If users at several sites are affected, the common factor is more likely to sit centrally, in an identity provider, a load balancer, or the application itself.

This is what nested, or composable, skills make possible: a high-level skill coordinates more specialized capabilities, calling them when needed and carrying context from one step to the next. The agent doesn’t need to invoke every skill or run every test. It needs to connect relevant evidence across the service delivery chain, use normal results to rule out possible causes, and narrow down the likely fault domain.

The value isn’t simply running more tests; it’s correlating the right evidence to understand the user’s experience.

More skills can mean more failure modes

Adding a skill for every new gap can seem like the natural fix, but every skill an agent can access gives it another option to weigh. A large, flat library can slow the agent down and increase the chance it chooses the wrong skill. How each skill is scoped matters too. Skills that are too broad may not give the agent enough direction. Skills that are too narrow can proliferate into a collection of one-off workflows, while overlapping skills can direct an agent to the wrong tools or produce inconsistent results.

Not every step in an investigation needs a skill or model reasoning, at all. Take a DHCP failure. An alert from the access point and a synthetic DHCP test from the same site provide independent signals. Simple rules can use those signals, along with how many clients are affected and whether the failure recurs, to determine whether the issue is isolated or site wide. For bounded, well-understood conditions like this, a deterministic check is often the better tool. It’s repeatable: the same evidence produces the same answer. It’s auditable: you can see which rule fired and why. And it’s grounded: actions can be tied to verified state rather than a model’s confidence. This isn’t the absence of expertise, but expertise hardened into rules once a problem is understood well enough. 

Skills earn their place when a problem is ambiguous and crosses domains, such as when dependencies span wireless, network, and application services.

A single elaborate reasoning process for every task can add cost and delay without improving the answer. Skills should help define the appropriate path: what to check, when to expand the investigation, and when to ask a person to review the findings.

DIY skills still need domain expertise

Organizations will have good reasons to build some skills themselves. They understand their own applications, operating procedures, sites, and business constraints. That context can make an agent more useful.

But generating a skill from documents, or asking a model to create one, is not the same as validating it.  Does the skill call the appropriate tools? Are the results being interpreted correctly? Does it know what the evidence can and cannot establish?

Those questions require domain expertise. In network operations, for example, a basic reachability check may show that a destination responds, but it may not establish whether users can actually join the call. Knowing which additional evidence to gather, and how to interpret it, takes expertise in the systems being investigated.

A practical approach is to build around what is unique to the organization and use specialist capabilities where the work depends on trusted data and domain knowledge. An organization might supply its own operational context while drawing on networking expertise and tools to investigate wireless, switching, identity, security, WAN, and application dependencies.

Make learning deliberate, too

Past incidents can help an agent investigate future problems, but they shouldn’t automatically become new rules. Findings need to be checked and categorized before they are reused. Otherwise, an incorrect conclusion can be repeated until it appears authoritative. Even reviewed findings should point to where to look, not override what the live evidence shows. 

The same discipline applies to skills themselves. Organizations should evaluate them against realistic scenarios, confirm that they use the right tools and evidence, and test whether the right skill is selected for a given problem and whether it stays inactive when it isn’t needed. They should also verify that conclusions follow from the results, and that workflows are efficient, without unnecessary tool calls or model reasoning. Good output separates observations from inferences and states the likely fault domain, alternatives, confidence level, and recommended next checks to run.

The future of agentic AI won’t belong to agents with the largest skill libraries. It will belong to agents that can assemble the right expertise, tools, and data for a specific outcome; carry context across the investigation; and know when they have enough evidence to act, and when to bring in a human. 

Mike Hicks is Principal Solutions Analyst at Cisco ThousandEyes. He is a recognized expert in network and application performance, with more than 30 years of industry experience supporting large, complex networks and working closely with infrastructure vendors on application profiling and management. He is the author of “Managing Distributed Applications: Troubleshooting in a Heterogeneous Environment” (Prentice Hall 2000) and “Optimising Applications on Cisco Networks” (Cisco Press 2004).