Build the Suite: What Separates a Technology Firm from a Consultancy

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.

What Building Enterprise AI Actually Looks Like Right Now

The hype around generative AI makes it sound like companies simply “turn on” AI and watch the magic happen. In reality, deploying AI inside large organizations is messy, technical, and deeply human.

Through conversations with builders working on enterprise AI deployments, a clearer picture emerges of what the work actually looks like on the ground.

The Marketing vs. Product Reality Gap

AI companies are still figuring out how to talk about what they build. Marketing teams often experiment with language to position their platforms at conferences and events, while product teams sometimes cringe at the terminology being used.

Part of the challenge is that the industry itself is evolving in real time. Everyone—from engineers to executives—is still forming opinions about how AI systems should be described, positioned, and sold. The result is a constant negotiation between what sounds compelling on stage and what accurately reflects the underlying technology.

The Rise of the “Forward-Deployed” Builder

A growing role in enterprise AI is the forward-deployed product or engineering role. These builders sit somewhere between product manager, consultant, and engineer.

Instead of building software in isolation, they embed themselves in real customer deployments. Their job is to translate a customer’s operational reality into something the platform can support.

Typical responsibilities include:

  • Understanding a customer’s existing workflows and systems
  • Designing how AI agents integrate into those environments
  • Testing and validating that systems behave correctly in production scenarios
  • Acting as the bridge between engineering teams and enterprise stakeholders

Each large deployment often involves a small pod—engineers and product specialists—working closely with a single customer.

Enterprise AI Is Still Mostly Strategy

One surprising reality: many large organizations want AI but don’t yet know what to do with it.

Companies frequently arrive with enthusiasm but little internal expertise. In many cases, a single internal champion pushes the initiative forward without a broader AI team behind them.

As a result, AI vendors often end up helping customers define their strategy before they even implement anything. Conversations quickly shift from “Can we deploy AI?” to questions like:

  • Where in our workflows does automation actually make sense?
  • What customer interactions should remain human?
  • How do we measure success for an AI agent?

For many enterprises, AI adoption begins as a strategic exercise rather than a purely technical one.

The Hidden Work: Testing, QA, and Reliability

Much of the real work in AI deployments isn’t glamorous.

Ensuring that AI systems behave reliably—especially in customer-facing contexts—requires extensive testing and quality assurance. Teams spend significant time verifying that agents respond correctly across thousands of scenarios.

For example, a customer-service AI agent might need to correctly handle thousands of variations of a simple request like “Where is my order?” — across different policies, authentication states, and edge cases. Each of those paths needs to be validated before automation can be trusted.

In practice, this means:

  • validating conversation flows
  • testing edge cases and failure modes
  • ensuring integrations work across multiple internal systems
  • implementing human-in-the-loop review processes before deployment

The goal is often to handle the “happy path” of common interactions reliably before expanding to more complex scenarios.

Platform vs. Services: A Tension in the Industry

Another emerging tension in AI companies is the balance between building a scalable platform and delivering hands-on services to customers.

Enterprise AI deployments frequently require significant customization and implementation support. Investors and product leaders, however, typically prefer companies that scale through product rather than services.

Many companies are navigating this hybrid model:
a product platform at the core, with a services layer that helps customers adopt it.

Over time, the hope is that repeated deployments lead to reusable templates and more standardized implementations.

The Next Wave: Personalized Software

One theme that keeps emerging across the AI ecosystem is the idea that we’re entering an era of personalized software.

Instead of buying rigid tools, organizations may soon generate or customize applications tailored to their exact workflows. Early experiments already show teams rapidly building demo environments and prototypes for customers using generative development tools.

If this trend continues, the biggest shifts in the next few years may not be just smarter models—but entirely new ways software gets built and delivered.

The Takeaway

The current wave of enterprise AI isn’t just about models or algorithms. It’s about integrating intelligent systems into messy real-world environments.

That requires a new kind of builder—part product thinker, part engineer, part strategist—working directly alongside customers to turn AI from a concept into something that actually works.

The hype cycle is loud.
But the real work of enterprise AI is happening quietly — inside deployment pods, QA spreadsheets, and integration docs.