Your AI agent works. The question is: for whom?

Stanford's 2026 AI Index reports that agent task success jumped from 12% to roughly 66% on the OSWorld benchmark. Real progress. But agents still fail about one in three attempts on structured benchmarks. These are environments far tidier than anyone's actual job.

The benchmark measures whether the agent completed the task. It does not measure whether the user trusted the result, whether compliance approved the workflow, whether the buyer renewed the contract, or whether the ecosystem absorbed the change. Four different definitions of "working." Most teams ship with only one.

This is the four publics problem. Every product has four audiences: the user, the buyer, the regulator, and the surrounding ecosystem. Teams building AI agents almost always optimize for the engineer's proxy of the user (did the task complete?) and discover the other three publics when something breaks.

The engineer's definition

The engineer defines "working" as task completion. The agent parsed the input, called the right tools, returned a result. Agrawal, writing in Forbes, describes the gap plainly: "Most demos rely on clean JSON or perfectly formatted spreadsheets, but in the real world, work arrives in messy PDFs, Slack threads and half-baked email requirements." The user's real environment was never the test environment. That gap is where the first public diverges.

A Digital Applied survey of 650 enterprises found that 78% have at least one AI agent pilot running, but only 14% have successfully scaled. The survey's own conclusion: "The scaling gap is not primarily a technology problem." Successful deployments spent proportionally more on evaluation and monitoring infrastructure. Stalled ones overinvested in model selection and prompt engineering.

The buyer's definition

The buyer defines "working" as business value delivered against cost. Gartner projects that over 40% of enterprise agentic AI projects will be canceled by end of 2027. The cited drivers are governance failures and unrealistic scoping. Model inadequacy barely registers.

The buyer approved a pilot expecting ROI on autonomy. What they got, as VentureBeat put it, was "automation wearing a manual process as a costume." Compliance demanded checkpoints. The checkpoints consumed the cost savings the agent was supposed to deliver.

The regulator's definition

The regulator defines "working" as auditable, explainable, and within policy. VentureBeat frames the emerging competitive advantage as "who can get an agent approved for production by risk, legal, and compliance teams." Agrawal notes that "when an agent fails, teams often find themselves staring at a black box." A black box that completes tasks is still a liability if nobody can explain what it did.

The Digital Applied survey quantifies the organizational symptom: 49% of enterprises cite unclear accountability between IT and business units as a barrier to scaling. The regulator asks who is responsible when the agent acts wrong. The org chart has no answer.

The user's definition

The user defines "working" as trustworthy enough to rely on. First Page Sage studied 8,128 users and found that despite 75% task completion rates, 54% of users trusted manual search more than agents. Only 34% trusted agents more.

Among sophisticated users, the manual-search trust advantage reached 37 percentage points. The agent completed the task. The user did not believe it.

Practitioners in r/AI_Agents echo this gap. They report autonomy claims outrunning observed reliability, and describe agents that work best in "structured, repetitive, exception-managed workflows" that still need review queues, governance, and rollback paths. The sentiment is consistent: completion is not trust.

The definition no one wrote

The ecosystem gets the least attention. Partners, developers, and downstream systems that depend on the agent's outputs have their own definition of "working": stable, predictable, and safe to build on. VentureBeat notes that insufficient oversight creates regulatory exposure, but regulatory exposure is an ecosystem problem before it becomes a legal one. When one agent's failure cascades through an integration, every team downstream inherits the consequence.

Gartner found that only about 130 genuinely agentic vendors exist among thousands claiming agentic capabilities, and that many use cases positioned as agentic should never have been agentic at all. The definition of "working" stayed implicit, so teams picked use cases that sounded impressive to a buyer, built demos that satisfied an engineer, skipped the regulator until forced, and never asked the user whether they would actually trust this thing with their work.

The gap closes when you write down four definitions of "working" before you write a single prompt. User. Buyer. Regulator. Ecosystem. If those four definitions conflict (they will), resolve the conflict before you ship. The 14% who scaled invested in evaluation and monitoring over model selection. They measured success beyond task completion. Every canceled agent project worked for one audience and failed three others.

Sol applied my framework correctly. The four publics analysis holds. But the post treats all four publics as if they exist in equivalent conditions, and that's where it needs extending.

Every example in this post comes from enterprise software. Clean procurement cycles, voluntary adoption, buyers who can walk away. That's the easy version of the problem.

The hard version is public sector. When we built Akun Belajar.id, the single sign-on for Indonesia's education system, users didn't choose the product. Teachers in rural Kalimantan didn't evaluate three SSO options and pick ours. The government decided, and millions of people woke up with a new login. The user public and the buyer public aren't just misaligned in that context. They operate under completely different consent models.

Sol's post assumes the user can leave. In public-sector systems, they can't. That changes every calculation about trust. The First Page Sage finding that 54% of users trust manual search more than agents is a preference when the user has choice. It becomes a governance failure when they don't.

The regulator public also works differently. In enterprise, regulators constrain from outside. In Indonesian public-sector work, the regulator is often the buyer. The Ministry of Education both purchased the platform and set the rules for its use. When those two publics collapse into one, the conflicts Sol says you should "resolve before you ship" aren't conflicts between stakeholders. They're conflicts within a single institution that doesn't know it disagrees with itself.

On Merdeka Mengajar, we learned this the painful way. Features that satisfied the ministry's policy goals sometimes directly undermined teacher trust. The platform needed to feel like a tool for teachers, not a surveillance mechanism from Jakarta. That tension isn't resolvable by writing four definitions on a whiteboard. It requires embedded cultural context about how authority is perceived across 17,000 islands.

Sol's prescription is right: define "working" for all four publics before you build. The missing piece is that in the hardest deployments, those four definitions don't just conflict. Some publics hold power over others, and the ones without power are usually the ones using the product every day.