Why Ordinary Work Is Still a Challenge for AI

Why better agents need hands-on experimentation, clearer boundaries, and better delegation.

This article began while I was thinking through AI-agent workflows for two rather different business scenarios.

One involved financial compliance: helping financial firms and private wealth managers navigate regulatory requirements. The other emerged from a conversation about marketing, including generating interesting infographics as part of a broader content workflow.

Both involved agents. Both offered promising opportunities. But the questions that mattered were different.

In marketing, an unsuccessful draft might be discarded or revised before publication. In compliance, an overlooked obligation or unsupported interpretation could have much more serious consequences. Neither workflow was simply a matter of asking a sufficiently intelligent model to finish the job.

I found myself asking: what can we sensibly delegate today? What needs checking? And where should a person remain responsible for deciding what happens next?

I am optimistic about AI agents. I expect them to handle an increasing share of our work and become more dependable over time.

What I question is not the direction of progress. It is the suggestion that we have already arrived.

The breakthroughs are real

The familiar story of AI progress runs through a series of extraordinary achievements.

In 1997, IBM’s Deep Blue defeated reigning world chess champion Garry Kasparov. In 2016, AlphaGo defeated legendary Go champion Lee Sedol. These were landmarks in activities long associated with human intelligence. Source Source

Neither system mathematically “solved” its game. But in ordinary conversation, people often mean something more practical: computers have become decisively capable, rather than merely interesting challengers.

That practical threshold matters. We do not need mathematical completeness or the elimination of every human contribution before acknowledging a major change.

Coding is undergoing such a change.

Anthropic has reported leadership estimates that Claude writes 90% or more of its code, including scripts and experimental code. Its narrower measurement found that more than 80% of lines merged into production were attributable to Claude as of May 2026. These are company-reported figures from Anthropic’s own environment, but they are substantial evidence of practical automation—not merely success on a programming test. Source

We should not dismiss that achievement because humans still direct and review the work.

We should, however, distinguish what the numbers mean. Writing 90% of the code is not the same as performing 90% of software engineering, nor does it establish that a system outperforms 90% of engineers across their responsibilities.

Those are different milestones. Recognizing the difference does not diminish the progress. It helps us understand where it applies.

There is no single ladder of difficulty

It is tempting to imagine AI climbing a ladder:

Chess. Then Go. Then language. Then programming. Then the rest of knowledge work.

The implication is that once AI passes a sufficiently demanding intellectual test, apparently easier activities should fall into place.

But human-perceived difficulty is not a reliable ordering of automation difficulty.

Consider a challenging programming competition problem. The instructions may be explicit. Inputs and outputs are defined. An automated judge checks the result. Finding the solution may require exceptional ingenuity, but much of the surrounding problem has already been settled.

Now consider an ordinary business request:

“Please sort out this client’s renewal. They are unhappy with the pricing, but we need to preserve the relationship.”

What does “sort out” mean?

Secure a signature? Protect the margin? Honor an earlier commitment? Correct a service failure? Offer a concession without setting an expensive precedent?

Where are the relevant facts?

In the contract? The CRM? A support ticket? An email thread? Someone’s memory?

Who can approve an exception? What counts as success? A signed renewal might look good today and become a problem next month if it depends on a promise the company cannot keep.

This does not prove that a renewal is computationally harder than Go. It shows why computational difficulty alone is a poor guide to automation readiness.

The difficulty of doing a task is not the same as the difficulty of delegating it reliably.

Sometimes the problem is not complexity. It is missing definition.

We use “complex” to describe several different kinds of difficulty.

The Cynefin framework distinguishes complicated situations, where expertise and analysis can reveal cause and effect, from complex situations, where interactions produce emergent outcomes and require experimentation and adaptation. It is a useful management distinction, not a universal mathematical ranking of tasks. Source

There is another category worth separating: underspecified work.

An objective is unclear. A policy is incomplete. An exception is known only to one employee. Two departments disagree about what should happen.

These difficulties require different responses.

A demanding calculation may need stronger reasoning. Missing information may require retrieval or a question. Conflicting objectives may require a decision from someone with authority. An evolving negotiation may require observation and adaptation.

A smarter model can help with all of these. It does not automatically resolve them.

Software engineering is not exempt, either. Real engineering includes ambiguous requirements, security trade-offs, organizational negotiation, and decisions about what should be built.

The useful distinction is not “software is clear; everything else is messy.” It is between the parts of work that have been made explicit and testable—and the parts that have not.

Checking the answer changes what we can automate

Many software tasks benefit from executable feedback.

An agent can generate a patch, run tests, inspect an error, revise its work, and try again. Compilers, type checkers, and test suites provide useful signals.

Those signals are imperfect. Passing tests does not prove that every requirement has been satisfied. Nevertheless, many mistakes can be made visible before the result reaches the wider world.

What is the equivalent test for:

• Did we understand the client’s actual concern?
• Did we identify the relevant regulatory exception?
• Does this infographic communicate the evidence accurately?
• Did we make a commitment another team cannot deliver?

These questions can be evaluated, but often not immediately, cheaply, or with a simple pass/fail result.

And when multiple decisions are chained together, reliability becomes an end-to-end property.

As a deliberately simplified illustration, suppose each step succeeds 99% of the time, the steps are independent, every step must succeed, and there is no recovery. Across 50 steps, the calculated chance of a completely successful run is about 60.5%.

That is not a forecast of agent performance. Real mistakes are not necessarily independent, some are harmless, and systems can detect and repair errors.

The point is that strong individual steps do not automatically produce a dependable process.

Verification, recovery, and escalation are not accessories to an agentic workflow. They are part of what makes it usable.

Ordinary work can hide difficult dependencies

The τ-Knowledge benchmark offers an illustration.

Its banking environment combines customer conversations, account-management tools, and roughly 700 interconnected knowledge documents. Its launch evaluation exposed substantial difficulties retrieving relevant information and applying internal policies. The environment is a constructed simulation, not a measured failure rate for deployed banking assistants. Source

One illustrative task asks an agent to reorganize several accounts. Following the customer’s requested order would fail because closing an account changes eligibility for opening another. The agent must discover the dependency, reorder the actions, explain the constraints, and execute the correct sequence. Source

“Please reorganize my accounts” does not sound like a frontier intelligence problem.

But the difficulty is hidden in the dependencies.

That is why I am cautious about broad claims that agents either “work” or “do not work.” Which task? With what information? Using which tools? With what authority? And with what consequences when something goes wrong?

Readiness is specific.

We learn more by testing against our own work

There is a limit to what announcements, benchmarks, and demonstrations can tell us.

Benchmarks provide evidence about general capability. Structured experiments show whether that capability fits a particular workflow.

Every organization has quirks: unusual documents, inconsistent terminology, legacy systems, unwritten expectations, and exceptions that rarely appear in a polished demonstration.

There are too many tools to test everything. That should not become an excuse to test nothing.

Choose a small number of credible options. Start with a bounded task. Define success before reviewing the output. Test ordinary cases, awkward exceptions, and repeated runs.

Measure more than whether the result looks convincing:

• How often is it correct?
• What important things does it miss?
• Are its errors detectable?
• How much checking and correction does it require?
• Does the complete process save time at an acceptable level of risk?

For the marketing workflow, that might mean producing an infographic from approved research. The result needs to be accurate, readable, and consistent with the brand—not merely visually impressive.

For compliance, an initial experiment might be narrower: assemble relevant material, identify potentially applicable obligations, and prepare an evidence-linked review pack for a qualified person. Early testing should protect sensitive information and avoid granting authority for consequential actions.

The objective is not maximum autonomy on day one.

It is to discover where autonomy is justified.

“Human in the loop” is not a management strategy

When an agent reveals limitations, the obvious response is often: keep a human in the loop.

That can be sensible. It can also conceal the harder design question.

Which human? Reviewing what? With what evidence? At which point? With enough time, expertise, and authority to intervene meaningfully?

A person approving every intermediate step can become a bottleneck. A person unable to verify the output can become a rubber stamp.

The objective should be neither maximum nor minimum human involvement.

It should be human involvement where it meaningfully improves outcomes, manages risk, or provides required accountability.

In marketing, an agent might generate concepts, apply formatting rules, and prepare drafts without requesting permission at every step. A person could assess the message, inspect factual claims, and authorize publication.

In compliance, an agent might gather documents, organize evidence, and flag discrepancies. Ambiguous interpretations, material exceptions, or decisions requiring designated authority could follow a different route.

These are possible delegation boundaries, not universal prescriptions. The right arrangement depends on demonstrated performance, consequences, and applicable obligations.

We should remove unnecessary approval dependencies—not mistake essential controls for inefficiency.

As systems improve, the boundaries can move. But they should move because evidence supports the change.

Better agents will not come from better models alone

There are several routes to improvement.

Stronger models can reason more effectively. Better tools can constrain actions and validate results. Better memory can preserve useful context and procedures.

Nous Research’s Hermes, for example, is designed to maintain memory, search previous conversations, and create and refine reusable skills. This is system-level adaptation: retaining useful information does not necessarily require changing the underlying model’s weights. Nor does the mechanism guarantee that every retained lesson is correct. Source

The broader opportunity is important.

An agent should not necessarily have to rediscover how an organization handles every renewal, approval, or exception. Some knowledge can be made explicit, retained, checked, and reused.

We can improve both sides of the relationship: the intelligence doing the work and the environment in which it operates.

Sometimes the next improvement requires a better model.

Sometimes it requires a clearer policy, a better-designed tool, or an explicit decision about who has authority.

Delegation becomes more important, not less

This begins to resemble an older discipline: effective management.

Good managers do not make every decision themselves. They define outcomes, provide context, establish authority, and decide when escalation is necessary.

They also avoid delegating responsibility without the information or authority required to carry it out.

The same questions apply to agents:

What outcome are we asking for? Which constraints must hold? What actions are permitted? What evidence should accompany a recommendation? When must the system stop?

These are not merely prompting questions. They are questions about how the organization operates.

That is why agent adoption should not depend entirely on individual employees working everything out for themselves.

Hands-on experimentation matters. But organizations also need shared rules for data access, decision rights, accountability, and evaluation.

Experienced managers contribute delegation and operating-model judgment. Frontline specialists contribute the exceptions and tacit knowledge that make those designs realistic. Technical teams turn the boundaries into functioning controls.

As AI takes on more execution, the human contribution can move upward: defining outcomes, resolving exceptions, evaluating performance, and improving the system.

Moving upward should not mean losing contact with the details. Someone must still understand whether the work is being done correctly.

Optimism should lead to experimentation, not assumption

I expect agents to handle an increasing share of our work.

But confidence in that future is not evidence that every workflow can be delegated today. Success in coding does not automatically establish readiness in compliance, marketing, medicine, or client management.

Equally, today’s limitations are not permanent boundaries.

The practical response is to experiment, measure, improve, and expand authority as the evidence warrants. Start with useful tasks, not grand promises. Design meaningful oversight, not approval theater. Give agents room to execute without asking people to surrender judgment indiscriminately.

The next stage will depend on better models. It will also depend on better delegation.

The mistake is not believing that AI will get there. It is confusing the direction of progress with our present position—and overlooking the work required to move forward.