Beyond AI Integration: Jeremy Bruck of West Monroe on Building an Enterprise Operating Layer

I'm a partner at West Monroe, where I lead our operational intelligence capabilities. I work with organizations across industries, including private equity firms and their portfolio companies, to help them scale AI across the enterprise and turn it into measurable results.

I've spent over a decade helping companies use data and AI to make better business decisions, and a big part of my job is helping leaders figure out where AI can create the most value and then working with them to actually capture it.

This gap tells me business leaders are grading themselves on integration and calling it connection.

When a leader says AI is connected across the business, what they usually mean is that the tools have access to the data. Everyone has an enterprise account, and a few workflows have an agent bolted on.

Connected means something harder. It means the AI shares one understanding of your customers, assets, orders, and contracts, and the relationships between them. It means the context carries through as work moves across teams, approvals, and systems instead of starting over every time it changes hands. It means a decision in one function shows up as an action in another.

That's what the 40% statistic reveals. You can layer AI on top of legacy architecture and get a genuinely useful assistant. What you can't get is a business that runs differently, because the layer underneath still can't tell the AI what's happening.

If you unplug the AI and nothing about the operation changes, it wasn't connected. It was adjacent.

An application waits for someone to open it. An operating layer is already running when you show up.

Take a claims exception or a job that misses its service window. In the application model, someone notices the issue, opens a tool, prompts the AI, reads the output, makes a decision, then goes and updates three other systems. AI helps, but the cycle time barely moved because the human is still the integration layer.

In the operating layer model, the event itself starts the work. The system already knows what the asset is, who the customer is, what happened last time, and what the contract allows. It evaluates policy, decides whether this routes to a person or executes on its own, and then does the downstream updates. The operator sees a decision with the reasoning attached, plus an approval gate if the risk warrants one. Every decision is documented, so there's a clear audit trail. The operator's attention and decision-making become scaling levers, and businesses can now handle exception volume more efficiently.

An example is a services business where dispatch ran on undocumented processes. Whoever was on shift decided who went to which job based on gut feel about who was close and who was good, with no real visibility into SLA risk or parts availability until the job was already blown.

We built a structured process with SLA risk and parts availability in mind. Now, every ticket gets scored for SLA risk and customer criticality the moment it's created, matched against technician location, skill, certification, and parts readiness, before a person ever looks at it. The dispatcher's job shifted from making every call to reviewing the small number of jobs the system genuinely can't resolve on its own.

Before, SLA breaches were a fire drill, and roughly one-third of jobs needed a second visit because of a wrong part, a wrong skill match, or a bad diagnosis the first time. After two quarters, breaches were down by about a third and repeat visits fell by a similar margin, because the system was catching failure patterns no dispatcher has time to see across hundreds of tickets a week.

None of the solutions implemented required foregoing the ticketing system or replacing the field team. It required giving the AI the same context a great dispatcher carries in their head and making sure that context doesn't walk out the door when that person takes a vacation or leaves the company.

Alignment often reflects ambition more than operational readiness.

Generally, leadership agrees that AI matters and that their company should move faster. But alignment starts to break down when the conversation shifts from strategy to execution. Whose workflow gets redesigned? Which controls change? Which roles change? That conversation hasn't happened yet in most companies, which is exactly why the strategy still looks so unified.

That's why the 91% and the 57% figures can both be true. One is measuring consensus on a direction. The other is measuring whether anyone has done the operational work to make it happen. Executives, for the most part, know that the technology usually works, but the organization isn't set up to use it.

It's easy to align around a strategy. It's much harder to align around the investments, organizational changes, and tradeoffs required to make that strategy real.

Honestly, not much ground actually gets "lost." The workflows that get redesigned are usually the ones that were already leaning hardest on one person, for example, the operations manager holding the process together in their head or the scheduler working around a system that was never built for how the business actually runs. Redesigning that workflow tends to elevate that person, because their judgment becomes the actual design input instead of a private tax they paid every day just to keep things moving.

The alignment breaks down for a plainer reason than politics. Reimagining a workflow, managing the change, and driving adoption is genuinely hard, unglamorous work. It's a different skill set than doing something "the way it's always been done" or managing the current technology. It needs dedicated capacity most teams don't have sitting around, and for a lot of companies, it's simply not a strength yet because they've never had to do it at this scale before.

The organizations that get through it treat that capacity as its own workstream, not something the technical build will handle on the side. They put someone in charge of the change and the adoption specifically, sometimes someone brought in just for that skill, and they give that work a dedicated budget and a seat at the table alongside the business and technology leaders.

Deep integration is key to ensuring AI is worth its investment, but that integration needs guardrails. The key is making sure you stay in control of the parts that make your business unique. That comes down to three things:

First, own your context. That means the way your business actually works: your customers, assets, relationships, and the business rules and institutional knowledge that aren't written down anywhere. That's often a company's most valuable asset, and it's surprisingly easy to hand over without realizing it.

Second, own your decision logic and operational state. You should always know how decisions are being made and where work stands. If that only exists inside a vendor's platform, switching becomes far harder than the contract suggests.

Third, own your audit trail. Every decision, why it was made, who approved it, and what happened next should remain yours.

Vendor lock-in isn't determined by how deeply you integrate. It's determined by what you can't take with you when you decide to move on.

The line isn't ours to draw. We co-design it with the client since it is a risk decision, not a technical one. When determining whether something executes automatically or requires a person, we are typically evaluating questions like, "Can this be reversed easily? What touches safety or a regulated process? What do current accuracy and evaluation metrics look like for a given output?"

It's also worth noting that the line for human intervention isn't fixed. It moves as trust gets earned. Something that needs a human sign-off in month one can execute on its own by month six, once the pattern has proven out across enough real cases.

These systems are also built to surface mistakes clearly. Every action keeps its reasoning attached, so when something goes wrong, it's possible to see why the system did what it did, reverse it, and know the cost right away instead of finding it weeks later during reconciliation. That mistake and its corresponding result feed back into the system so it can learn, similar to how positive results are fed back into the system, as part of its recursive learning loop.

Sequencing. I used to believe you could build the shared foundation first and the use cases second. The thought was that if companies got things like the context layer, data model, and governance right, then applications could be deployed quickly to capture value because the foundation was in place.

Technically, that's still true. Organizationally, it fails. Foundation-first programs run 12 to 18 months without delivering a result anyone outside the project can actually see. Then budgets change, executive sponsors move on, and a solid platform gets shelved before it ever proves its value.

The organizations furthest along have flipped that approach. They pick one workflow and one KPI, deliver value quickly, and build the foundation underneath that first win. The second use case moves faster than the first, and the third is faster than the second, because the underlying capabilities are already in place. Well-executed programs and failed programs often have the same components; it is the way they are ordered that differentiates them.

Start at the KPI and work backward. Most 90-day plans fail because they start at the other end, with the data or the tool, and focus on selecting tools and automating workflows.

KPI: Pick a number that is important to the business that has struggled to move.

Action: Understand what actions need to be taken, either by humans or agents, to impact the metric.

Intelligence: Determine what intelligence is needed to take the action.

Data: Define the data needed to generate the intelligence.

Take attrition in retail banking as an example:

One action to impact the metric is a banker calling a specific household that has a high likelihood of churning.

The intelligence is knowing which household to reach out to today and why.

The data is the household's holdings, activity, prior outreach, and market intelligence like interest rate movements and financial market shifts, all resolved into one record instead of scattered across four systems.

Getting there in 90 days follows roughly the same arc:

Weeks 1 to 3: Connect the first sources of data and spend real time watching how the work actually happens today, not how it's documented on paper. That's what sets the baseline everything else gets measured against.

Weeks 4 to 8: Redesign the key workflows, including what gets prioritized and what the person or system acting on it needs to move the metrics. Bring on additional data sources as needed.

Weeks 9 to 13: Put a working version in front of a real group of users. Measure the results against the baseline, and adjust the outputs and workflow based on results.

The result at day 90 should be a KPI being impacted as real users use new intelligence and workflows to make decisions and take action. The second KPI or workflow should be ready to move faster than the first one because the context and the controls have a starting point from the datasets and intelligence that already exist in the platform.