Last week, Parloa and McKinsey & Company announced a formal alliance to help enterprises move AI agents in customer service out of the pilot stage and into production. The split is clean. McKinsey brings readiness assessments, operating model design, governance and data integration. Parloa brings the platform that builds and manages the agents.

I think it’s a smart pairing. It also made me think about my own work.

I work at a contact center AI company, and we have our own partnership with a large systems integrator. Between that partnership and the Parloa news, I keep coming to the same conclusion: building the actual suite is what makes a technology firm different from a management consulting firm. Forward-deployed and professional services work is fairly consultative by nature. That’s fine. But it isn’t what sets you apart.

The lines are blurring

From the outside, AI vendors and consultancies are starting to look alike.

AI vendors now hire forward-deployed engineers and PMs. These people sit with the customer, map workflows, untangle integrations and tune agents against real conversations. Professional services teams run discovery workshops, write process docs and help with change management. That’s consulting work, even if the title says otherwise.

Consultancies are moving the other way. They build AI practices, engineer solutions and partner with platforms so they have something concrete to deploy.

So if both sides send smart people into the customer’s building to solve the customer’s problem, what’s actually different?

What I learned in the field

I spent a good stretch as a forward-deployed PM for AI agents, mostly with healthcare and life sciences customers, like TailorCare. That work is close to consulting. You learn the customer’s world, find where the agent will break, negotiate scope and earn trust one fix at a time.

What I noticed: the most valuable thing I did on any one deployment wasn’t the deployment. It was spotting the problem I’d see again at the next customer, then getting it into the product so nobody had to solve it by hand twice.

A custom integration helps one customer. A connector in the product helps every customer after that. A clever prompt fix helps one customer. An evaluation framework in the platform helps every customer after that.

That’s the asymmetry. Services knowledge mostly lives in people and documents. Product knowledge compounds.

Services should feed the product

I’m not knocking services. Enterprise AI doesn’t ship without them. Parloa and McKinsey say as much in the announcement: the hard parts are often data integration, process and governance, not just the model. I agree.

But for a technology firm, services work has a specific job. It’s how the company learns what to build next. Every field deployment should send something back to the product team: a pattern, a gap, a feature request with real usage behind it.

If services start replacing the product instead of feeding it, you end up with a consultancy that has a software line item. That can be a good business. It’s just a different one.

A few questions I use to tell which one I’m looking at:

• Does the next deployment get easier? If the tenth customer takes as much custom work as the first, the learning isn’t reaching the product.
• Where does the knowledge live? In the heads of a few field people, or in the platform, the configuration and the tooling?
• What happens when the field team moves on? A product keeps getting better without them. A one-off custom build slowly stops working.

Building it for ourselves

This is why I’m now building internal AI: DeploymentOS, our internal field operator context layer. The idea is simple. Everything our field teams learn across deployments should end up somewhere the product and the next team can use it. Today it’s scattered across Slack threads, call notes and people’s memories.

It’s the same principle turned inward. If I believe services should feed the product, our own field operations need a product too.

Why partnerships like this make sense

That’s why I think alliances like Parloa and McKinsey are a good model. Each firm does the thing it’s built for. The consultancy brings transformation expertise and organizational rigor. The technology firm brings a suite that gets better with every customer, including the ones the consultancy brings in.

Our partnership with a large systems integrator works best the same way. They bring reach, industry depth and change management. We bring the product, and we keep investing in it so each joint deployment leaves the product stronger.

The problems come when either side tries to be the other. A vendor that turns into a services shop stops compounding. A partner treated as the product’s replacement ends up rebuilding the same thing for every client.

The takeaway

If you lead forward-deployed or professional services work at an AI company, here’s my challenge: measure yourself by what you send back to the product, not just by what you deliver to the customer.

Consulting is a great motion. But at a technology firm, the suite is the thing that sets you apart.