Blog

Lessons from the Field: How Agentic AI Is Expanding Service Delivery – Part 2

Why Human Expertise Matters Even More in an Agentic World
By Justin Flynn
November 3, 2026

TL;DR

As agentic AI becomes more capable, human expertise becomes even more important in Service Delivery. AI can help engineers work more efficiently, but effective communication, technical judgment, and accountability remain essential. Experienced engineers must be able to evaluate AI-generated recommendations, recognize potential risks, and establish appropriate guardrails to ensure AI supports their work without replacing human oversight.

The Human Side of Agentic AI in Service Delivery

In Part 1 of this two-part series, I wrote about how agentic AI is expanding what an experienced Service Delivery engineer can effectively accomplish: moving faster from a problem to a diagnosis, extending an engineer’s technical reach into unfamiliar territory, and reducing the “context tax” of rebuilding what’s already known before a customer session.

None of that changes what the job is actually about. If anything, it raises the bar on the parts of Service Delivery that AI can’t do for you.

Communication Is Part of the Engineering

Technical ability is only part of Service Delivery. A significant portion of the job is communication:

  • Explaining technical problems to customers
  • Translating engineering findings into something actionable
  • Setting expectations
  • Documenting decisions
  • Escalating issues clearly
  • Explaining why the path everyone expected to take isn’t going to work

I’ve always considered communication one of my strengths, but I’ve noticed something unexpected since incorporating AI more heavily into my workflow: my communication has continued to improve even when I’m not actively using AI.

I frequently use AI as a thought partner. I challenge my interpretation of a technical problem and ask whether an explanation is clear. I then sanity-check my reasoning and test an argument for weaknesses. I also remove unnecessary complexity and consider how a customer might interpret what I’m about to say.

That repeated process forces clearer thinking.

Over time, I’ve found those habits carrying into verbal communication as well. I organize technical explanations more quickly, separate facts from assumptions more deliberately, anticipate questions earlier, and get to the important point faster.

That matters because AI can help prepare an explanation, but it can’t own that explanation for you.

Eventually, when you’re sitting in front of a customer or colleague, someone will ask a question you didn’t anticipate. You need to understand the architecture, explain your reasoning, respond to pushback, and recognize when you don’t know the answer.

While AI can help sharpen communication, it cannot substitute for the ability to communicate.

AI Amplifies Expertise, but It Can Also Expose Its Absence

This brings me to what I think may be one of the most important lessons I’ve learned from using these tools.

A convincing (but wrong) AI answer can look remarkably similar to a correct one.

An engineer with strong product and technical knowledge can recognize when a recommendation doesn’t fit the architecture, when an assumption is wrong, or when a proposed action carries unnecessary risk. They can also challenge the output, provide missing context, and recognize when further validation is required.

Someone who relies too heavily on AI may not recognize those problems.

In that sense, AI can amplify expertise, but it can also expose its absence.

AI is ultimately a tool, and like any advanced tool, its value depends heavily on the person using it. As the capabilities of our tools advance, our ability to use them effectively has to advance with them.

Product knowledge doesn’t become less important in an agentic environment. I think it becomes more important.

If engineers increasingly supervise work performed by agents, they must understand that work well enough to evaluate it. AI is not a substitute for knowing the product, understanding the customer’s environment, or being able to explain and defend a recommendation.

The engineer remains accountable for the outcome.

Useful Agency Requires Guardrails

Accountability is also why enterprise agentic AI shouldn’t mean giving autonomous systems unrestricted access to customer environments. The model I’ve found most useful is deliberately constrained.

In our environment, agents can work with authorized systems and specialized tools to help:

  • Gather context
  • Search existing issues
  • Analyze technical evidence
  • Examine migration data
  • Assist with lab validation
  • Prepare escalations
  • Develop customer-ready communication

But different boundaries apply to actions that could affect production environments, customer systems, or shared information. Those restrictions aren’t obstacles to effective AI. They’re what make useful agency possible. Read versus write access, lab versus production environments, scoped credentials, approval gates, auditability, and human review become part of the architecture.

Examples of Enterprise AI Guardrails
Guardrail Purpose
Read vs. Write Access Controls whether an AI agent can only retrieve information or also modify data and configurations.
Lab vs. Production Environments Separates testing and validation activities from systems supporting live business operations.
Scoped Credentials Limits an agent’s access to the specific systems, resources, and permissions required for its tasks.
Approval Gates Requires explicit human authorization before designated actions can proceed.
Auditability Provides records of agent activity so actions and outcomes can be reviewed and verified.
Human Review Ensures AI-generated findings, recommendations, and outputs are evaluated by a qualified person when appropriate.
The objective shouldn’t be maximum autonomy. It should be maximum useful leverage within acceptable risk.

Moving the Service Delivery Engineer Up the Stack

What interests me most about agentic AI isn’t the possibility of removing engineers from Service Delivery.

It’s the possibility of expanding what an engineer can effectively own.

Less time can be spent searching across systems, reconstructing context, performing repetitive analysis, formatting escalations, or researching every unfamiliar environmental issue from scratch. More time can go toward architecture, customer decisions, exception handling, risk management, and solving problems that genuinely require experience and judgment.

That changes the role.

The Service Delivery engineer increasingly becomes an orchestrator: defining objectives, establishing constraints, evaluating evidence, supervising execution, and stepping in where human judgment matters.

The underlying technical knowledge doesn’t disappear. It becomes the foundation that makes that orchestration possible.

We’re still early in this transition, and I don’t think anyone knows exactly where the boundary between AI assistance and autonomous execution will ultimately settle.

But based on what I’m already seeing in the field, I’m increasingly convinced that the most interesting question isn’t whether AI can do an engineer’s job. It’s how much more a knowledgeable engineer can accomplish when AI becomes part of how that job is done.

The future of Service Delivery may not be fewer engineers doing the same work.

It may be stronger engineers capable of delivering far more than the traditional boundaries of the role ever allowed

Frequently Asked Questions about Agentic AI Guardrails

Agentic AI refers to AI systems that can plan and carry out multi-step tasks using tools and connecting to other enterprise systems, rather than simply responding to individual prompts. In Service Delivery, these agents can help streamline workflows by gathering context, searching existing issues, analyzing technical evidence, and preparing escalations and customer-ready communications. The engineer remains responsible for evaluating the results and accountable for the outcome.

A convincing but incorrect AI answer can look remarkably similar to a correct one. Engineers with strong product and technical knowledge can recognize when a recommendation doesn’t fit the architecture, when an assumption is wrong, or when a proposed action introduces unnecessary risk. As engineers supervise more work performed by AI agents, they must understand the underlying products and systems well enough to evaluate the results, challenge questionable recommendations, and explain their reasoning to customers.

Enterprise AI agents should operate within authorized systems and clearly defined permissions, with safeguards appropriate to the risks associated with their actions. Common guardrails include read versus write access controls, separation of lab and production environments, scoped credentials, approval gates, auditability, and human review. OWASP’s guidance on excessive agency also emphasizes limiting agents to the permissions necessary for their tasks and requiring human approval for high-impact actions.

Human-in-the-loop refers to maintaining human oversight at appropriate points in an AI-driven workflow. This can include reviewing AI-generated findings, validating recommendations, approving actions before execution, or intervening when human judgment is required. In enterprise Service Delivery, this oversight is particularly important for actions that could affect production environments, customer systems, or business-critical operations.

I don’t believe so, although it’s difficult to predict exactly how AI will reshape the profession. Service Delivery has evolved considerably over the decades, but one fundamental requirement has remained consistent: the human element. Communication, customer relationships, expectation management, and technical judgment are essential throughout the customer engagement, from the initial sales handoff through deployment and ongoing operations. Agentic AI can automate repetitive tasks, accelerate analysis, and expand what engineers can accomplish, but those capabilities don’t eliminate the need for experienced professionals who can navigate complex customer environments and take responsibility for outcomes. I see AI transforming the role rather than replacing it.

  • As CTERA’s Enterprise Service Delivery Manager, Justin leads the successful deployment and adoption of CTERA solutions across strategic enterprise accounts. With over 20 years of experience in IT infrastructure, systems engineering, and customer success, he specializes in aligning technology with business goals, driving operational readiness, and delivering long-term value for CTERA customers.

    Enterprise Service Delivery Manager

Contact Us

This field is for validation purposes and should be left unchanged.

Categories

Authors