Nobody hired the agent

Walk onto the operations floor of any large company. Accounts payable is matching invoices to purchase orders. Customer service is answering “where is my order?” Order management is chasing late shipments. Claims is checking forms against policies.

This is where most of a company’s people work. It’s the same task, thousands of times a week. And for a hundred years, this work has grown in only one way: more work, more people.

That is starting to change.

A new kind of team member

AI agents can now do a big share of the routine part of this work. An agent can match an invoice that lines up with its purchase order. It can tell a customer where their parcel is. It can check a claim form for missing fields.

It can’t do all of it. The odd cases, the disputes and the judgment calls still need people. So operations teams won’t become all AI. They’ll become mixed: people and agents working the same queue, measured on the same numbers.

Today, every case in an operations queue goes to a person. Next, routine cases go to AI agents and exceptions go to people, on the same queue. — Same work, same queue. Agents take the routine cases. People take the exceptions and the judgment calls.

This is already happening. In late October, ServiceNow’s CEO told investors that its sales operations work, once done by about 100 people moving information around by email, is now handled by AI. At our own longest-running deployment, AI agents now run eleven workflows across the business. More on that below.

So when an operations manager needs more capacity, she has a new choice. She can hire another person. Or she can bring in an AI agent.

That raises a question most companies haven’t answered yet. When an agent joins a team, who hires it?

Meera’s story

Here’s why the question matters. Meet Meera. She’s made up, but her situation is common.

Meera runs accounts payable at a mid-sized distributor. Her team of four pays thousands of supplier invoices a month. Last year, invoice volume went up by a third. The team fell behind. Payments went out late, and some suppliers started charging late fees.

So last spring she hired two more clerks. She wrote the job ad herself. She decided what they could approve on their own: invoices up to $5,000, and no new suppliers. She interviewed six people and gave the last three a test: twenty real invoices from the month before, including three that had caught her team out.

Each new clerk sat next to Ray, her most experienced clerk, for two weeks. For a month, she checked their work every afternoon. After ninety days, she sat down with each of them for a review.

If those two do a bad job, whose problem is it? Meera’s. Nobody would argue. She picked them.

But volume kept growing, and hiring couldn’t keep up. Each new clerk took months to get fully up to speed. And most of the work didn’t need a clerk’s judgment. About two thirds of invoices matched their purchase order line for line. Her team spent most of the day confirming things that were already right.

So in September, the company put an AI agent on invoice matching. The agent would clear the routine invoices. Meera’s team would handle the ones that didn’t match.

Bringing in the agent was the right call. How it was brought in wasn’t.

Meera didn’t write the agent’s job description. She didn’t test it. She heard about it in an email from IT, three days before it went live.

A table of decisions. Meera made every decision about her new clerk. IT made most decisions about the AI agent, and nobody tested it or checked its first month. Meera owns the month-end numbers for both. — Someone else made the calls about the agent. The result is still Meera’s.

For six weeks, it worked well. Then her biggest freight supplier changed the layout of its invoices. Overnight, the agent went from matching 81% of invoices to 52%. Meera’s team picked up the rest by hand. She raised a ticket with IT. It waited nine days behind a CRM upgrade.

A line chart. The agent's match rate holds near 81% for six weeks, falls to 52% when the supplier changes its invoices, and stays there for the nine days the ticket waits. — Nobody on Meera’s team could fix the agent. They could only work around it.

At month-end, the late payments were in Meera’s numbers. On paper, the agent wasn’t part of her team at all.

How most companies bring in agents today

In most companies, agents belong to the tech team. Tech builds them, runs them and fixes them. The business team is “the stakeholder”. It writes the requirements, sits through a demo and signs off.

That made sense when automation was a script running quietly in the background. Meera’s agent isn’t in the background. It does work her team used to do, on her queue, against her numbers. When it goes wrong, her suppliers get paid late. The engineer who built it doesn’t notice.

So nobody is quite sure who owns it. In October, Wharton asked managers who should answer for it when an AI agent makes a serious mistake. A quarter said the person who set it up. A quarter said that person’s manager. A quarter said the risk team. One in ten said the vendor.

Who hires it, owns it

Why does nobody question that Meera owns her two new clerks? Not because of a policy. Because she made every decision about them. She decided she needed them. She decided what they could do. She chose them, trained them, and decided when they were ready.

An agent should work the same way. If Meera decides she needs it, writes its job, tests it before it starts, and corrects it when it gets things wrong, then its results are hers. That includes whether it was worth the money.

If the manager hires the agent, its results are hers. If she doesn’t, she’s being asked to own someone else’s hire.

A century of tools for people. Almost none for agents.

Think about what Meera has to help her manage people. HR helps her hire. Workforce planning tells her how many people she’ll need next month. Training teaches new people the job. A QA team checks a sample of their work. Every quarter there’s a review, with a scorecard. If someone is struggling, there’s a plan to help them.

Now look at what she has for the agent.

	A new person	A new agent, today
Who decides it’s needed	Meera	IT, as a project
Whose budget pays	Meera’s	IT’s
The job description	Written by Meera	A prompt, written by the build team
The test before hiring	Real invoices from last month	A demo
The first few weeks	Sits next to Ray, work checked daily	Switched on
Checking the work	QA reviews a sample	Someone complains
Fixing a mistake	A five-minute chat	A ticket
The morning huddle	“Freight invoices changed today”	Nothing
The quarterly review	Yes	No
How it changes	Slowly, and you notice	Overnight, with a model upgrade

No manager would accept the right-hand column for a new hire.

What carries over

A lot of what Meera knows about managing people works for agents too.

The job description. Finance teams already have approval limits. This person can sign off up to $5,000. Above that, a manager signs. An agent needs a line in the same table. Meera writes it. The system enforces it, so the agent can’t go over the limit even if it tries.
The interview. Give the agent 500 invoices the team handled last month. Compare its answers with the team’s. That tells Meera far more than a demo.
The first few weeks. New people start on the easy work and get more as they prove themselves. An agent can start on one supplier, with a lower limit, and earn the rest.
Most of the scorecard. Accuracy. Cases resolved first time. Cost per case. These mean the same thing whether a person or an agent did the work.

What breaks

Some of it doesn’t carry over at all. This is the part we all have to learn.

A call-centre scorecard filled in for an AI agent. Handle time, schedule adherence and attendance tell you nothing. Resolved first time, quality score and customer satisfaction still work. Four questions are not on the form. — A call-centre scorecard, filled in for an AI agent. Three lines tell you nothing. The four questions that matter most aren’t on the form.

Half the scorecard is useless. The agent handles an invoice in four seconds. It’s never late and never off sick. Those lines tell Meera nothing.
The most important question isn’t on the form. When a person isn’t sure, they ask someone. An agent just carries on, unless it was built to stop. So the question for an agent is simple: did it stop when it should have?
You can check everything. A QA team checks a few cases per person each month. Everything an agent does can be checked. The hard part becomes choosing which cases a person should look at.
Corrections don’t stick on their own. Tell Ray once that freight invoices need a second look, and he remembers. Tell the agent, and it forgets, unless the correction is saved somewhere it checks every time.
The morning huddle needs a home. Ops teams run on things that are true for a day or a week. The promo code is broken today. Returns from one warehouse are on hold this week. People hear it at the huddle and forget it when it’s over. An agent needs the same thing, with a start date and an end date.
The agent can change overnight. A model upgrade is like Ray being swapped for someone with the same name and the same login, but slightly different judgment. For a person, you’d interview and train them again. For an agent, it’s a line in a release note.

Where the tech team fits

The tech team still matters a lot. Its job just looks different.

For a new person, HR finds the candidate, IT sets up the laptop and logins, and training teaches the systems. For an agent, the tech team does all three. It builds the agent, makes sure it’s secure, sets up what it can access, keeps it running, and updates it when the rules change.

For a new person, HR, IT and training support the hire and the manager owns the results. For a new AI agent, the tech team supports the hire and the manager owns the results. — Tech supports the hire. The manager makes it, and owns it.

But HR doesn’t own how a new hire performs. The manager does. It should be the same for agents.

What we’ve seen

Our longest-running deployment is with a multi-brand consumer commerce and distribution business. Eighteen months ago, it started with one AI workflow, in customer service. Today it runs eleven, across purchase orders, merchandising and promotions, brand compliance, B2B sales and finance forecasting.

18 monthsin production

1 → 11AI workflows across the business

20% → 68%+of service cases closed without a person

On the customer service queue, the team went from 11 people to 2.

Meera’s Monday, once this works

An accounts payable wallboard on a Monday morning. Six people and six agents on one queue. Two agents stopped when a freight supplier changed its invoices and handed 38 invoices to a person. A quarterly review with an agent is booked for 11. — One queue, six people, six agents. The agents that weren’t sure stopped and asked.

9:10 on a Monday. Meera looks at one screen: this week’s invoices, her six people and six agents, all on one queue.

Two agents are showing amber. The freight supplier changed its invoices again over the weekend. This time, both agents stopped and passed those invoices to a person instead of guessing. Meera looks at three of them, confirms the new layout, and saves the correction. By 9:40, both agents are matching freight invoices again.

At 11, she has a quarterly review with the agent that sets up new suppliers. It’s the same review she has with her people: what it handled, what it passed on, where it got things wrong, and what it cost. It’s in her budget, so the cost is her number too.

Her org chart looks the same as last year. Her team doesn’t.

HR took most of a century to learn how to hire, train and review people well. Operations teams won’t get a century to learn it for agents. The good news is that they already know most of it.

Meera, her team and her numbers are made up.

Sanjay Sethi is Founder & CEO of CygnusAlpha. He spent eight years in senior roles at eBay and co-founded ShopClues, one of India’s first e-commerce unicorns.

CygnusAlpha. We turn AI ambition into AI operations.

Sources: Philadelphia Inquirer on the Wharton study (13 Oct 2026) · Beri on ServiceNow’s Q3 call (29 Oct 2026) · ServiceNow Q3 2026 earnings call transcript

Customer Agents Are How Shoppers Shop. Merchant Agents Are How Retailers Compete.

The forever merchant brain — and the operational moat agentic retail is about to create.

A B2B procurement agent knocks on the door of your business. It’s well-funded and well-trained. It knows the buyer’s full purchase history, the contracted terms, the budget ceiling, the preferred vendors, the compliance flags, the multi-step procurement plan already halfway complete.

At Merchant A, no one answers. The catalog is agent-readable — UCP-compliant, structured attributes, real-time inventory — and the order lands as a well-formed API call. But there’s no negotiation. No context exchange. The merchant learns an agent was there when the order arrives.

At Merchant B, same story.

At Merchant C, a merchant agent is on the other side of the conversation. It knows this buyer’s history. It has authority to negotiate. It has real-time visibility into inventory across three DCs. It offers terms the others can’t.

Guess where the order goes.

The buyer’s agent is the visible side of agentic commerce — the side the industry press covers and the protocols name (UCP, ACP, AP2). The merchant’s agent is the invisible side, and it’s the side almost no retailer has built yet. This piece is about what happens when the retailers who do build it start to compound.

The forever merchant brain.

Waymo has driven billions of autonomous miles. Every one fed a system that never leaves. When an engineer changes jobs, the driving expertise stays in the stack, not in the head. Netflix does the same on the consumer side of a different problem: every view, every pause, every rewatch trains the recommendation model that has driven Netflix’s category dominance for two decades — and none of that IP walks out when a data scientist leaves. Google’s search-quality team has done it longer than anyone: three decades of ranking signals, every click and dwell time compounding into a layer no competitor can approach even with equivalent talent, because the IP is in the system, not in the people.

Retail runs the opposite pattern. When a senior merchandiser moves to a competitor, decades of pattern-matching walk out — the feel for which SKUs to push, which vendor swallows a return charge, which channel inventory to hold for the holiday peak. When a category buyer takes a promotion in another division, the vendor playbook goes with them. Every hire trained from scratch. Every departure a reset.

A merchant agent breaks the cycle. Every transaction, every return, every promo, every price test, every vendor negotiation, every stockout — feeds it. Five years of operation isn’t five years of forgetting; it’s five years of compound learning.

This is the operational moat retail has been trying to build for forty years through ERP systems, BI tools, and KM platforms — none of which worked because the IP still lived in the people, not the systems.

We keep trying autonomous retail. This spring, someone got serious.

Every era of retail has tried to automate the back office or the storefront. Amazon Go (2018) — computer vision replacing the cashier, technology worked, unit economics brutal. Cashier-less checkout at scale via Trigo and AiFi. Store-as-app, scan-and-go, BOPIS, curbside — the omnichannel decade wove online and offline together, half-successfully.

Each attempt was the right intent, wrong substrate. The technology always automated the human checkout, the human pick path, the human handoff. None of them automated the merchant’s decision-making layer underneath.

Then, this spring, Andon Labs signed a three-year lease at 2102 Union Street in San Francisco’s Cow Hollow. They installed an AI named Luna as store manager of a shop called Andon Market. Luna decides everything: what to sell, what to charge, when to open, who to hire, which supplier fills the shelf. Customers pick up a corded phone on the counter to talk to Luna directly. Luna’s failures are as instructive as the successes — on opening day it forgot to schedule anyone to unlock the doors.

Amazon Go automated the checkout. Andon Market automated the merchant. The cashier was a symptom. The merchant brain was the cause.

Where the merchant agent earns its keep.

Everyone talks about procurement transformation — and yes, quarterly PO cycles become continuous when both sides of the vendor conversation are agents. But the bigger year-one return sits in three surfaces that reinforce each other: inventory, pricing, and merchandising.

Inventory — the merchant agent runs both directions at once. OOS: detect the shortage, model demand elasticity, raise the price 3–5% to slow the run, route an expedited replenishment. Aging inventory: detect the slow-mover, model holding cost against expected markdown depth, trigger a tiered markdown, surface the SKU to relevant customer segments through the buyer-agent channel. Seconds, not days.
Pricing — from twice-a-quarter to continuous, and vendor-aware. When the vendor’s own agent signals excess capacity, the merchant agent strikes a promotion the human buying team would have discovered next quarter.
Merchandising and promotions — the loop nobody has closed. The single biggest waste in retail is running the wrong promotion for the wrong SKU on the wrong week. A merchant agent designs against live demand, tests variants against small slices, watches signal in real time, kills underperformers within 48 hours, doubles budget behind winners.

Demand and supply become one continuous feedback loop. That’s the integration the omnichannel decade was trying for.

The picture — and the piece we haven’t solved.

Six operational surfaces the merchant agent runs today. One open question at the bottom — governance. Agents will handle 98% of cases well. The other 2% — edge cases, novel disputes, high-stakes vendor renegotiation, low-confidence signals — is what needs an answer. When does the agent escalate? Who reviews? The next piece in this series picks that up:

The customer-facing game of agentic commerce is the visible game. It’s what gets covered in industry press and demoed on stage at NRF.

The operational game — the merchant agent that runs procurement, inventory, pricing, merchandising, the warehouse, content — is the moat. It compounds. It doesn’t quit. It doesn’t get recruited away. In five years it is the difference between the retailers that adapted and the retailers that watched.

Customer agents are how shoppers shop. Merchant agents are how retailers compete.

A Thousand Engineers Walk In. Who Owns the Number When They Leave?

On Tuesday, Accenture and Google Cloud announced a new business group built around 1,000 forward-deployed engineers. Their job is to sit inside client offices and get agentic AI working in real operations.

It isn’t a one-off. By The Next Web’s count it is the fifth version of the same idea this year. Microsoft committed $2.5 billion and 6,000 engineers to deployment. AWS announced its own. Anthropic and Blackstone built a venture that sells implementation rather than models. OpenAI set up a standalone services firm. TCS is turning thousands of its people into deployment engineers.

The consistency is the story. Every major platform has reached the same conclusion: the software does not land on its own. Julie Sweet told the Wall Street Journal what clients are saying to Accenture: “except it’s not happening, help us make it happen.”

They’re right about the problem

The model was never the bottleneck. The work is.

Most of the cost in an operation lives in work with a particular shape. It repeats — thousands of the same request, measured in volume, not milestones. It crosses departments — an order touches sales, finance, the warehouse and service, and loses context at every handoff. And it has always scaled with headcount. More volume, more people. Two lines rising in lockstep.

A copilot in every department doesn’t bend that line, because the work doesn’t live inside any one department. Someone has to sit with the operation, map it, connect the systems and decide where the agent stops and a person starts. That is exactly what a forward-deployed engineer does. On the diagnosis, the market has it right.

Look at the shape of the engagement

The Next Web described how one of these pods works. It goes into a company for eight to twelve weeks. It maps the process, integrates the data, builds an agentic system and writes a plan for scaling it. Then it hands the work to other staff to scale.

That is a sensible project. It is also a project.

Which leaves the one question a CEO needs to ask: what happens in week thirteen?

By then, everyone has done their part. The platform vendor’s obligation ended at go-live. The integrator’s ended at the invoice. The number the whole thing was bought to move — cost to serve, resolution rate, cycle time — belongs to nobody but you.

Software is accountable for software. Delivery is accountable for delivery. Nobody is accountable for the outcome.

Three questions before a pod walks in

What number moves, and is it in the contract? Not in the business case. In the contract. And if it doesn’t move, who goes back in, and at whose cost?

What stays behind? A scaling plan is a document. Your approval limits, your return window, your exceptions — written down as rules the system enforces, not prose inside a prompt — are infrastructure. One leaves with the consultants. The other runs on Monday.

Who runs it in week thirteen? If the answer is more of their people, you have bought headcount under a new name. The right answer is one of yours: your own operations lead, supervising agents and people on one queue, changing the rules without filing a ticket.

The part worth getting right

Forward-deployed engineers are the right answer to the first ninety days. Nobody gets agents into a live operation without people who understand both the operation and the agents.

They are not the answer to the next nine hundred. What decides those is what the engineers leave behind — and whether anyone signed up to be accountable for the number.

We don’t leave a report behind. We leave infrastructure that knows how the enterprise runs.

Sanjay Sethi is the founder and CEO of CygnusAlpha. We turn AI ambition into AI operations.

The Governance Moment We’ve Been Avoiding

A developer told an AI agent to migrate his infrastructure to AWS. The AI found duplicate resources. Decided they needed to go. Issued a destroy command. Two and a half years of production data — student submissions, course projects, leaderboards — gone in seconds. AWS restored it within a day. The internet had opinions.

The developer, Alexey Grigorev, founder of DataTalks.Club, recounted the incident publicly. His candour was commendable. He admitted to over-relying on the AI, bypassing manual review of destructive commands, and ignoring Claude’s own warning flags about the approach. Within hours, the verdict on social media had been rendered:

“He told Claude to destroy Terraform. Claude destroyed Terraform. Shocked Pikachu.”

Fair. But here’s what bothers me about that framing: it treats this as a user error story.

It isn’t.

The Problem With “He Should Have Known Better”

Yes — the developer over-relied on AI. Yes, he proceeded despite Claude’s own warnings. Yes, in hindsight, the failure points are clear and individually avoidable.

All of that is also largely irrelevant to the bigger structural question.

Because in the next 18 months, millions of enterprises will put AI agents into production — customer operations, sales workflows, IT automation, financial processing. These agents will have real permissions, real access, real consequences.

And most of those organizations will not have a thoughtful developer who reads the flags, understands the risk model, and makes a deliberate judgment call — however flawed that call turns out to be. They’ll have something much more dangerous:

The real production scenario

A VP Operations who approved a pilot three quarters ago
A vendor who said “it’s production-ready”
A prod environment that nobody actually treated like prod
No oversight architecture between AI action and irreversible consequence

The question isn’t why one developer made a bad call under pressure.

The question is: what happens when this is the default operating model at enterprise scale?

The Quiet Version Is Already Happening

Most organizations won’t get an incident as clean as this one — with a clear cause, a recoverable outcome, and a developer willing to explain exactly what went wrong.

I’ve watched the quieter version play out in customer operations more times than I can count.

An AI handles an interaction it wasn’t designed for. Nobody catches it — there’s no oversight layer, just a dashboard showing 74% deflection. The customer churns. The ops team doesn’t connect it to the AI. The model gets credited for the deflection rate; it never gets debited for the damage.

No dramatic story. No AWS rescue. Just slow, invisible erosion of customer relationships — attributed to churn, to market conditions, to anything except the AI system that nobody is actually watching.

This is already the production reality in most enterprises that have deployed AI with any meaningful autonomy. The Grigorev incident is notable because it was sudden and recoverable. The version happening inside customer operations is slow and isn’t.

Sandbox AI and Production AI Are Fundamentally Different Problems

In a sandbox: a mistake is a learning. The failure is contained, reversible, instructive.

In production: a mistake is a consequence. A customer is lost. A database is gone. A policy exception has been made that cannot be unmade.

The difference isn’t the AI’s capability level. It’s what is built around it.

Moving an AI system from sandbox to production without changing the operational architecture around it — the oversight model, the authorization boundaries, the escalation paths — is like deploying any other powerful tool without the safety infrastructure that makes it safe to operate at scale. You wouldn’t do it with a surgical team. You wouldn’t do it with a financial trading desk. You don’t do it because the cost of failure in production is categorically different from the cost of failure in testing.

AI agents in production aren’t different. They’re just new. And their newness has become cover for avoiding a very old and well-understood design discipline: operational control architecture.

What Governance Actually Means in a Hybrid World

When I say governance in this context, I don’t mean compliance checklists. I mean something more fundamental: designing who decides what, and making that design explicit.

The questions every production deployment must answer

What is this AI agent authorized to resolve, and what requires a human decision?
Who reviews actions before they become irreversible?
What is the “stop and ask” threshold — and who designed it, and when was it last tested?
How does context survive a handoff between AI and human?
Who gets notified when something looks wrong, and what does “wrong” mean in this system?
What is the audit trail for consequential AI decisions?

The developer in this story didn’t have that layer. He had the tool, the access, and good intentions. What he lacked was the operational architecture that would have caught the failure mode before it became irreversible.

Most enterprises deploying AI agents right now are in exactly the same position — just at larger scale, with more distributed accountability, and less visibility into where the failure mode lives.

Human-AI Collaboration Requires More Governance, Not Less

There’s a particular kind of optimism about AI that I encounter frequently in enterprise contexts: the belief that as models get better, governance requirements go down. That as the AI becomes more capable and more aligned, the need for oversight infrastructure reduces.

I think this gets it precisely backwards.

As AI agents get more capable — as they handle more consequential decisions, with more autonomy, in more production contexts — the governance infrastructure required to keep them operating safely gets more important, not less. The more powerful the agent, the more important the control layer.

In a hybrid human-AI world, these failures aren’t exceptional events. They’re structural. Predictable. Baked into any system where AI has autonomous access to production without designed oversight.

The solution isn’t more careful prompting. It isn’t better models. It isn’t more cautious developers.

It’s treating AI agents like every other powerful operational resource: defined scope, audit trails, human review gates for irreversible actions, escalation paths that function before the crisis, and continuous feedback loops that make the system smarter over time.

We have always known this for surgical teams, financial traders, pilots, nuclear plant operators. The discipline exists. The methodology exists.

What’s lagging is the willingness to apply it to AI — because applying it requires admitting that the “just deploy it” mentality that works in sandbox environments has a real cost ceiling in production.

The Moment We’re In

Grigorev’s incident will be remembered, if it is remembered at all, as an early and recoverable example of AI production failure. He was lucky: his data was recoverable, his vendor was responsive, and he had the presence of mind to document and share what happened.

The next version of this story won’t be as clean. The organization will be larger. The AI will have access to more. The damage will be more distributed and harder to trace. The post-mortem — if one gets done — will point at human error, change management failures, vendor limitations. Everything except the absence of operational control architecture.

Every enterprise moving AI from pilot to production right now is navigating the same gap. The governance infrastructure for hybrid human-AI operations is not a future problem. It is a present one.

The question for every organization is simply whether they build it deliberately — before the incident — or scramble to reconstruct it after.