TL;DR
Agentic AI connects an AI model to the tools and systems an engineer already works in, so it can gather data and coordinate steps instead of only answering prompts. For Service Delivery engineers, that means faster triage of unexpected product behavior, more technical reach into the surrounding customer environment, and less time rebuilding context between customer sessions.
The Expanding Role of AI in Service Delivery
Over the past year, I’ve been incorporating AI more deeply into my Service Delivery workflow. What started primarily as a tool for analysis, scripting, communication, and validating my own thinking has evolved into something much broader as agentic capabilities have emerged.
What I’ve found most interesting isn’t that AI is replacing pieces of the Service Delivery role. It’s that AI is expanding what an experienced engineer can effectively accomplish.
Service Delivery has always required engineers to operate across multiple technical and organizational domains. On any given deployment, we may move between product configuration, networking, identity management, storage, cloud infrastructure, validating customer requirements, troubleshooting, project management, Engineering, Support, and customer communication.
In many ways, the Service Delivery engineer has traditionally been the integration layer connecting all of those pieces.
Agentic AI is beginning to change that model by helping engineers connect information, tools, and workflows that previously required them to coordinate each step manually.
From Assistance to Orchestration
There is an important difference between using AI as an assistant and giving it the ability to participate in a workflow.
A traditional AI interaction might involve pasting in a log and asking for analysis, generating a script, improving some documentation, or asking a technical question. Those capabilities are helpful, and I still use them regularly.
Agentic AI goes further by connecting AI with the tools and systems involved in the work, allowing it to gather information, perform tasks, and coordinate steps across a workflow.
One of the clearest examples I’ve seen is how quickly I can now move from encountering unexpected product behavior to determining what to do about it. An agent with access to our internal issue-tracking system can search existing Engineering issues to determine whether what I’m seeing has already been reported and help correlate the symptoms with known issues.
If the issue appears to be new, the same workflow can help organize the evidence needed to report it effectively.
The benefit isn’t simply that AI can write a bug report faster. It shortens the path from observing something in the field to determining whether I’m dealing with a known defect, a new issue, or something specific to the customer’s environment.
That same concept applies across Service Delivery. Instead of using AI for isolated tasks, we’re beginning to use it to connect the steps surrounding those tasks.
Expanding the Engineer's Technical Reach
Some of the largest time savings I’ve seen during deployments haven’t involved our product at all, but rather the surrounding infrastructure and applications.
Anyone who has worked on enterprise deployments knows how easily a customer technical session can stall because of something in the surrounding customer environment. Active Directory isn’t behaving as expected. A required network port is blocked. DNS isn’t resolving correctly. A certificate chain is incomplete. Storage permissions aren’t behaving the way everyone expected.
These aren’t necessarily product problems, but they’re still Service Delivery problems because they sit directly on the project’s critical path.
Historically, resolving them depended heavily on whether the engineer happened to have experience in that particular area, how quickly the problem could be researched, or whether the right customer resource was available.
AI changes that equation.
An experienced engineer can use AI to quickly explore unfamiliar technologies, validate assumptions, identify appropriate diagnostic steps, and interpret the results in the context of the deployment. In my own workflow, this often involves sharing diagnostic information in real time with internally developed AI tools that use specialized subagents and skills to help investigate the problem.
I’ve seen this save considerable time during customer technical sessions. Something as straightforward as identifying a blocked port or working through an Active Directory configuration problem can sometimes be resolved during the session rather than becoming another action item that delays the deployment.
The engineer doesn’t suddenly become an expert in every technology surrounding the product. Instead, AI expands the technical territory that the engineer can effectively navigate.
Turning Every Problem into an Opportunity to Learn
That expanded technical reach has another effect that I think is easy to overlook.
It can make engineers better.
Service Delivery engineers naturally develop broad technical knowledge because customer environments constantly expose us to technologies and architectures outside our company’s products. Much of what experienced engineers know was learned because something didn’t work during a deployment, and they had to figure out why.
AI can dramatically accelerate that learning cycle.
If I encounter an unfamiliar Active Directory behavior, for example, I don’t have to use AI simply to find a configuration change that makes the problem disappear. I can use it to understand the following:
- Why the behavior is occurring
- How the underlying technology works
- What should be tested
- How those results relate to the product I’m deploying
The same thing happens across networking, storage, cloud infrastructure, databases, APIs, certificates, and even areas of the product an engineer may not have worked with extensively before.
The best AI interactions don’t just resolve the problem in front of the engineer. They leave the engineer better equipped to resolve the next one.
That’s one of the reasons I’m skeptical of the idea that AI necessarily makes technical roles less skilled. Used correctly, I’ve experienced almost the opposite: AI exposes engineers to more areas of the technology stack and gives them an opportunity to understand those areas faster.
But there is an important qualifier: the engineer has to want to understand the answer rather than simply accept it.
Reducing the Context Tax
There is another cost in Service Delivery that is harder to measure: context.
Before a customer session, an engineer may need to reconstruct what happened during the previous meeting. That may entail reviewing open support cases and Engineering issues, checking product versions, revisiting documentation, examining migration results, and remembering what another team previously recommended.
Multiply that across several simultaneous engagements, and a meaningful amount of time is spent simply rebuilding context.
Agentic systems can reduce that “context tax” by gathering information from authorized systems and presenting the relevant pieces together.
This is particularly useful in complex workflows such as enterprise data migrations. Discovery information, migration logs, product configuration, customer requirements, known issues, lab testing, Engineering escalations, and project status may all be related, but historically they have lived in different systems.
The opportunity isn’t simply to use AI to migrate data. It’s to use AI to help orchestrate the work surrounding the migration.
That distinction is important. Service Delivery isn’t a collection of isolated technical tasks. It’s a continuous process of gathering information, making decisions, executing work, validating results, communicating findings, and adjusting when something unexpected happens.
Agentic AI is particularly well suited to helping connect those pieces.
This is Part 1 of a two-part series. Part 2, “Why Human Expertise Matters Even More in an Agentic World,” will look at what doesn’t change as AI becomes more capable: communication, judgment, and the guardrails that make agentic AI useful rather than risky.
Frequently Asked Questions
- What is the difference between an AI assistant and agentic AI?
An assistant handles specific tasks you hand it, such as analyzing a pasted log or drafting a script. Agentic AI is connected to the applications and systems involved in the work, so it can gather information, perform tasks, and coordinate steps across a workflow.
- How does agentic AI help engineers triage product issues?
An agent with access to the internal issue-tracking system can search existing engineering issues and correlate symptoms with known issues and potential solutions. If the issue looks new, it can help organize the evidence for a report, which shortens the path to determining whether it is a known concern, a new issue, or specific to the customer’s environment.
- Does AI make engineers less skilled?
When used correctly, AI can accelerate learning and expand an engineer’s technical knowledge by helping them understand unfamiliar technologies, investigate problems, and validate solutions. The key is using AI to develop understanding rather than simply relying on it for answers.
- What is the "context tax"?
The context tax refers to the time and effort required to reconstruct information across different systems and activities. In Service Delivery, this can mean reviewing support cases, Engineering issues, documentation, and previous recommendations before a customer session. Agentic AI can help reduce this overhead by gathering relevant information from authorized systems and presenting it together.
