Don't Buy More AI Software. Hire an AI Workforce.

Everyone has AI software now. But who actually owns the job?

Every enterprise software category is going through the same transformation. Legacy products are adding copilots and chat interfaces. New products are being built as “AI-native.”

Every vendor is telling us that their software can now reason, recommend, automate, or even act.

And yet, there is a question I don't think we are asking enough:

Who owns the outcome?

Because making software intelligent is not the same as making a job disappear.

The first wave: AI on top of legacy software

Take a typical enterprise IT product.

For years, it has required an operator to navigate dashboards, configure policies, run reports, interpret alerts and execute actions.

Now we put an AI assistant on top of it.

You can ask questions in natural language. The software can summarize things. It might even execute some actions. But fundamentally, you still own the job.

The AI has made the software easier to operate. It hasn't necessarily made the responsibility disappear.

The second wave: AI-native products

The next generation is more interesting.

Imagine an AI-native server compliance product.

You can ask:

“Check all my servers against our compliance framework.”

The agent discovers the environment, identifies gaps and perhaps even recommends or executes remediation. That's a significant improvement. But then the remediation touches another system.

A change request needs to be raised in the ITSM.

The network team needs to approve something.

A patch needs to be tested.

An application owner needs to validate it.

A maintenance window needs to be scheduled.

Someone needs to follow up.

Someone needs to verify that the change actually worked.

And someone eventually needs to report:

“We are now 96% compliant. The remaining 4% is pending because these three teams haven't completed their actions.”

At this point, the product has reached its boundary. And the ownership of the outcome returns to the IT operator.

That's the fundamental limitation of a product-centric AI agent.

It may be autonomous inside the product. But the job doesn't necessarily live inside the product.

What if we changed the unit of value?

Think about how a good managed services team operates.

You don't hire a managed service provider because you want someone to operate ten different software products. You hire them because you want a job done.

You might say:

“Keep my infrastructure compliant.”

And they figure out how to achieve it.

They use your existing ITSM.

They work with your endpoint tools.

They navigate your monitoring platforms.

They execute scripts.

They raise change requests.

They talk to your network team.

They follow up with application owners.

And where automation isn't possible, they put people on the problem.

The tools are their means of execution. They are not the service itself.

The customer buys the outcome.

This distinction becomes even more important in an AI-native world.

Consider the service desk

Today, an enterprise doesn't expect a service desk engineer to say:

“Sorry, that's a Wi-Fi problem. I only handle endpoint issues.”

Or:

“That's a printer problem. Please raise a ticket with another system.”

Or:

“Your application access issue belongs to the application management tool.”

A good service desk engineer is expected to navigate across all of these.

They diagnose the problem.

They determine what needs to happen.

They use whichever tools are necessary.

They involve the right teams.

They follow up.

They verify the resolution.

And they close the loop.

The job is “resolve the employee's IT issue.”

It isn't “operate the endpoint management product.”

That distinction should define how we build AI agents for IT.

Instead of building one AI agent for endpoint management, another for network management, another for application monitoring and another for ITSM...

Why not build an AI workforce around the jobs that IT teams actually own?

An AI service desk worker.

An AI server compliance worker.

An AI patch management worker.

An AI infrastructure operations worker.

Each one operating across the entire technology landscape required to get its job done.

And this matters because enterprises aren't greenfield

This is perhaps the most important part. Most enterprises already own hundreds of software systems.

Some are modern. Some are AI-native. Many are legacy.

Some have excellent APIs. Some have terrible APIs.

Some are homegrown.

Some cannot be integrated at all.

But the business outcome doesn't change because the enterprise has bad software.

A managed services provider has historically dealt with exactly this problem.

If something can be automated, automate it.

If two systems can be integrated, integrate them.

If they can't, use another method.

If automation isn't possible, deploy people.

The outcome remains the responsibility of the service provider.

AI workers should work the same way. They shouldn't require the enterprise to first replace its entire software stack before they can deliver an outcome.

They should navigate the mess.

This changes how we should buy AI

And this is where I think the industry needs to rethink its pricing conversation.

There has been a lot of discussion around the economics of AI voice and other AI services, with pricing naturally getting anchored around units such as minutes, tokens and usage. Sarvam, for example, currently publishes usage-based pricing for its AI APIs, including Voice Agents at ₹2 per minute.

That's perfectly logical when you're buying an API.

But it becomes a very different question when you're buying an AI worker.

If I'm hiring an AI worker to own server compliance, why should I care how many minutes it worked?

Or how many API calls it made?

Or how many tokens it consumed?

Or how many different tools it had to invoke?

If the worker keeps 10,000 servers compliant, the underlying compute cost is an implementation detail.

The value is the outcome.

This is exactly how managed services have historically been sold.

You define KPIs. You define SLAs.

The provider figures out how to deliver them.

The economics underneath may consist of people, software licenses, automation, infrastructure and processes.

But the customer buys the outcome.

The next question for every AI vendor

So perhaps enterprises should start changing the questions they ask their AI vendors.

Not:

“What features does your AI have?”

Not:

“How many tools can your agent integrate with?”

Not even:

“How much does it cost per user, asset, minute or transaction?”

Instead:

“What job will you own?”

And then:

“What KPI will you commit to?”

“What SLA will you underwrite?”

“What happens when the job crosses your product boundary?”

“Do you still own the outcome when another team's system, process or approval is involved?”

This could fundamentally change the market.

Because once enterprises start buying AI based on outcomes, vendors will naturally begin designing their products, operations and pricing around those outcomes.

The market will stop rewarding vendors simply for building cheaper AI software.

It will start rewarding those who can deliver better outcomes at lower total cost.