Beyond the Roadmap: Six Constraints that Decide Whether Your AI Pilot Ever Ships

Takeaways from “Astreya Talks AI,” featuring Lauren Frazier, Abhilash Mana, Edward Betancourt, and Debashree Chatterjee

Google Cloud Next and ServiceNow Knowledge 26 announced new SKUs, agents, and reference architectures, but the harder question stayed mostly unanswered. What does it take to run AI inside an environment that already carries two dozen tools, a CMDB nobody fully trusts, and a supplier transition sitting on the calendar?

Our panel started there. Below are the six takeaways, the constraints most worth acting on, in the panel's own words, with the practical next move for each.

1. Context is the scarce resource

The constraint: Your models are good enough already, but the knowledge they need is scattered across systems that will never live in one place.

One theme that stood out for me definitely was that the conversation is shifting from model efficiency to enterprise context. We have lots of models. They are already efficient enough. What is challenging right now is to give the right trusted context to these models."

— Debashree Chatterjee, VP of Enterprise AI Practices

Old architecture on borrowed time. Copying data out of six systems into one warehouse assumes fragmentation is a temporary condition that Debashree says "will [not] stay valid for very long anymore," because enterprise context stays spread out no matter how many pipelines you point at it. ServiceNow's zero copy connector and context engine, delivered through Workflow Data Fabric, exist because duplication stopped paying for itself.

Her conclusion: "The next competitive edge is not who has the better model, but basically who would actually give the right context to these models."

The move: Scope your next AI project around context delivery. Write down what the agent has to know, where that lives today, and how it gets there without a copy.

2. Platform agnostic is a decision you make per job

The constraint: Your systems of record were chosen decades apart with little (if any) consideration for each other. Some have modern APIs. Some have a green screen and a batch window.

"Platform agnostic" is a buzzword, but what does it really mean for your business? The panel gave it a working definition: architect from the outcome backward.

We don't architect solutions driven by platform or a platform feature. Rather, we have to solve based on the business outcome that we have to achieve. And then we see which platform, which platform feature, is the best fit."

— Debashree Chatterjee

Imagine a customer wants to close an account. The agent needs payment history, billing, and any holds, so that context comes through ServiceNow's zero copy connector with nothing duplicated. Then the agent has to act, and the system of record turns out to be a COBOL platform with no API, which takes Integration Hub off the table. The action goes to RPA.

We don't wait on a single platform. Rather, what we are doing is we are selecting a platform or a platform feature based on the job the AI agent has to do. And that is really the platform agnostic [approach] that we follow. And that really helps us to industrialize AI faster."

— Debashree Chatterjee

One major risk to note: "If you're locked into one ecosystem's AI story, you're exposed."

The move: Split every use case into a context step and an action step, then evaluate them separately. Two platforms is a common and correct answer.

3. Start in IT operations, where nobody has to grant you permission

The constraint: You can’t get budget or air cover for AI until something visible works.

The place to engage or start engaging is basically the non-disruptive areas, which is like in IT operations. A lot of analysis is done on an everyday basis, dealing with everyday issues, tickets. You look at at least a couple of dozen tools that you connect to, dashboards you look into, analyze information from various sources. So this is an easy place to start."

— Abhilash Mana, SVP of Practices

Astreya started here about a year ago and still sees the most value here: MTTR reduction on the order of 60% – 70% under good conditions, deeper diagnosis on the tickets that repeat, repeat problems named and managed before they page anyone.

There is a political return too. "Once you … start seeing value, then the entire organization starts [to back] you on your journey. And that's where you kind of start expanding the scope to larger areas."

The move: Find the analysis your operators repeat most often this quarter. That is your pilot.

4. Thin-slice the use case

The constraint: Your service desk cannot absorb a big bang, and your data will not survive one.

Abhilash's example: an agentic assistant for your service desk operators does not require every use case on day one.

If you think you're confident about the knowledge base your team has built over a period of time in SharePoint or Google Drive, or even in ServiceNow, using that itself is good enough to kind of give you a knowledge base summarization in context of the [ticket]. That is a good place to start. You don't have to necessarily take the entire life cycle of a ticket and start putting an agent to resolve it."

— Abhilash Mana

The move: Ship the smallest slice an operator can see working. Widen coverage as you repair the data and context behind it.

5. Fix the data that blocks the first use case, then move

The constraint: Your CMDB has missing and/or stale fields, and every team follows the SOP differently. 

If you run AI on [a messy CMDB], you're going to get … faster wrong diagnoses or, you know, wrong answers. The idea is [to fix] that first before [you] deploy anything on top of it."

— Abhilash Mana

Our CTO sees the same wall from the architect's side of the house. Teams consolidate their data sets, then discover missing fields, unpopulated fields, and inconsistent adherence to SOPs. The architect trying to build on top of it "basically hits a wall and says, 'I'm not quite sure I can fix this.'"

How do we go after, first of all, understanding where my gaps are in the data quality, let alone fixing it? ... Roughly, the way we think about it is 70 different checks on quality."

— Edward Betancourt, Chief Technology Officer

You can run 70 diagnostic checks in just a few weeks. A full cleanup can take years, but Debashree warns that “waiting for perfect conditions is not the right [approach].”

The move: Assess data quality before you scope the AI work. Repair what blocks use case one then sequence everything else.

6. Nobody is buying autonomous, so build for trust and then for an operating model

The constraint: Your Risk, Audit, and Legal teams have to sign off, and they will ask who is accountable when the agent is wrong.

Governance ran through both conferences. ServiceNow framed it around empathy, bias control, transparency, and accountability. Google framed it around fairness and safety, privacy, and transparency. However you frame it, customers arrive at the same place.

Organizations are also underestimating ... They go and talk about autonomous — nobody will buy that. You need to have a trusted system. You need to have a system which is explainable, which is having the right human in loop. And then you go ahead and implement your AI solution."

— Debashree Chatterjee

The next 12 to 18 months change the job from building agents to running them.

Like we are managing people, we are going to manage AI agents very soon. And that is where ... AI observability, or AI governance, versioning, rollback, etc. will become very, very important going ahead. So if you ask me, next 12, 18 months: let's not just build AI agents …  let's build an AI operating model so that we are valid even after 12, 18 months from now."

— Debashree Chatterjee

The move: Before you scale past pilot, define entitlement, lineage, agent monitoring, explainability, and rollback. If you cannot say who owns an agent and how you version it, you are not ready to expand.

Where Astreya fits

Two points from the panel are worth naming.

1. Tribal knowledge can become an asset. Every managed services conversation produces the same two questions. Will anything fall through the cracks if my supplier changes, and will the new supplier bring real efficiency? Both trace back to operational knowledge that lives in a few people's heads. AI OpsHub is our answer to that. One pane of glass for IT operations, integrated with the tools already in your environment, running the loop: detect, diagnose, identify the fix, validate it, resolve, write the result back to your ITSM.

It's how that individual that is the expert in the service does it. We call it, put it on paper, and then we can start understanding how do we identify that process. Our expert will still remain there. He or she will become the person [whose process] we are automating in our platform. So we take that tribal knowledge and we bring it to life in an [agentic manner] as much as possible."

— Edward Betancourt

2. Agents are built for real white spaces. We have 36 AI agents in the ServiceNow Store and Databricks Marketplace, more in progress, and over a hundred more built internally.

We didn't build all these AI agents just to fill the marketplace. We built these for all the operational white spaces that we discovered, which native features cannot solve."

— Debashree Chatterjee

That origin dictates our sequence. Reuse what you have already paid for, build only where the gap is real, and arrive with patterns that have run in production. Debashree calls them "the proven patterns which we inherit as learning and the knowledge to our customers."

The honest version of the 18-month question

We asked the panel how a team can avoid getting caught flat-footed a year and a half from now.

Abhilash pointed at the gap between what AI can already do and what enterprises actually consume, which remains enormous, and at cost, which keeps falling. Both accelerate adoption over the next 12 to 24 months.

Edward was shorter. Be strategic about how you use AI and give it time to produce results. "Stay true to the plan, and let's have a conversation again in six months."

We would like to have that conversation with you.

If you are deciding where to start, or you piloted something and it stalled, let's talk. A short conversation with our practice leaders will tell you which of these six constraints is your actual bottleneck, which is usually the difference between a pilot and an operating model.

Talk to our team | Explore AI OpsHub | See our AI agents on the ServiceNow Store