09/06/2026
AI Agents Can Work for Hours Now — But Can You Trust Them?
AI agents can now handle tasks that take hours to complete. But can we actually trust them to work on their own? Explore the hidden reliability challenges of long-running AI agents, including error accumulation, memory, monitoring, permissions, cost, and human oversight.

AI Agents Can Work for Hours Now — But Can You Trust Them?

For most of the generative AI era, using AI meant asking a question and waiting a few seconds for an answer. That pattern is changing quickly.

AI agents can now browse the web, work across files, call external tools, write and run code, and continue working while the user does something else. OpenAI reported in June 2026 that 70.2% of sampled individual Codex users had assigned at least one task estimated to take a human more than an hour, while 25.6% had assigned work estimated to take more than eight hours. Among OpenAI’s heaviest internal users, multiple agents were generating more than 60 hours of agent work in a single day by running in parallel. (OpenAI)

That is a very different kind of AI.

The important question is no longer simply whether an agent can keep working for hours. It is whether it can keep working predictably.

A chatbot that makes one bad statement gives you one bad statement. An agent that makes a bad decision early in a long workflow may spend the next two hours building on it, update files along the way, call other systems, and still return something that looks perfectly polished.

That gap between autonomy and reliability may become one of the defining problems of the next phase of AI.

A Small Error Can Become a Long Chain of Errors

Consider a simple example.

You ask an agent to research 50 competitors, compare their pricing, update a spreadsheet, identify the biggest changes, and prepare a report for your team.

The agent has to make dozens of smaller decisions before it can produce the final document. It has to identify the right companies, choose sources, interpret pricing pages, normalize different pricing models, decide what belongs in each spreadsheet field, and summarize the results.

If it makes a mistake on the first company, the damage may be limited.

If it misunderstands the task itself, the entire workflow can drift.

This is one of the most important differences between a chatbot and a long-running agent. With a chatbot, the unit of failure is usually an answer. With an agent, the unit of failure can be a process.

Google highlighted exactly this problem when explaining why it rebuilt parts of its Agent Development Kit in 2026. Production agents, Google noted, can become trapped in loops, bypass required business logic, or fail without producing a clean error. Its conclusion was that prompting and model-level guardrails alone are not enough for reliable production systems. (Google Developers Blog)

The longer an agent works, the more important the path becomes, not just the final output.

Reliability Is Becoming a Systems Problem

There is a common assumption that stronger models will eventually solve most agent failures.

Better reasoning certainly helps. But long-running work introduces problems that intelligence alone does not fix.

Imagine an expense-processing agent. It may be excellent at reading receipts, understanding unusual explanations, detecting duplicate claims, and comparing expenses with company policy.

But should the model itself decide whether a $20,000 reimbursement can be approved?

Probably not.

A company may want a simple rule: any payment above $5,000 must stop and wait for a human.

There is no benefit in asking a language model to creatively reinterpret that rule every time.

This is where agent architecture starts to matter as much as model quality. Google argues that tasks such as routing, scheduling, retries, and error handling are often better handled with deterministic workflows rather than letting an LLM decide every next step. Traditional code is less flexible, but it is also predictable. (Google Developers Blog)

The strongest agent systems will therefore probably not be completely autonomous.

They will combine probabilistic AI where judgment is useful with deterministic software where consistency matters.

That is a subtle but important shift. The future of agents may depend less on removing conventional software and more on deciding exactly where AI should be allowed to make decisions.

“It Worked Once” Is Not the Same as “It Is Reliable”

This may be the most overlooked problem in agent evaluation.

Suppose an agent successfully completes a complicated workflow.

That sounds impressive. But what happens when you give it the same type of task tomorrow? And the day after that?

Microsoft’s STATE-Bench, released in May 2026, makes this distinction explicit. Rather than measuring only whether an agent succeeds once, it also measures pass^5: whether the same task succeeds across five separate runs. (Microsoft Open Source)

The difference can be significant.

In Microsoft’s baseline tests, strong task performance did not automatically translate into consistent performance across repeated attempts. In one travel-related evaluation, only about 30% of tasks succeeded on all five runs. (Microsoft Open Source)

This matters because businesses do not need an agent that can sometimes complete a workflow.

They need one that can complete the same type of workflow correctly again and again.

An agent that succeeds 90% of the time may sound excellent. But if the remaining 10% includes sending a refund to the wrong account, skipping a required approval, or updating the wrong customer record, that headline success rate suddenly looks much less reassuring.

For business use, consistency may eventually become more important than peak capability.

The question will not be:“Can this agent do the task?”

It will be:“Can we predict how it will behave every time we give it this task?”

Long-Running Agents Need More Than Memory

Another challenge appears when work lasts for hours, days, or even weeks.

The agent has to remember what already happened.

That sounds simple, but long-running work involves more than recalling facts from an old conversation. The system may need to preserve which steps were completed, which tools were used, what decisions were made, what failed, what still needs approval, and what has changed in the outside world since the workflow paused.

OpenAI describes long-running agent work as moving knowledge work away from single interactions toward delegated tasks that can continue for minutes or hours. (OpenAI) The practical challenge is maintaining enough state for that work to remain coherent from beginning to end.

Microsoft’s STATE-Bench was created partly because simple memory retrieval tests do not capture this problem. Remembering a name from 50 messages ago does not prove that an agent can maintain the state of a real workflow. (Microsoft Open Source)

That distinction becomes especially important when an agent pauses.

A purchasing workflow may wait overnight for a manager to approve an order. A customer-service case may wait two days for another department. A software-development agent may continue a project across multiple sessions.

When the agent returns, it cannot merely remember the conversation. It needs to understand the state of the work.

For long-running agents, memory is therefore moving closer to workflow state than ordinary chat history.

Trust Requires an Audit Trail, Not Just a Chat History

There is another requirement that becomes much more important once agents work independently: visibility.

If an AI agent spends two hours producing a report, the user should probably be able to see more than the final PDF.

Which websites did it use?

Which files did it modify?

What tools did it call?

Where did something fail?

Did it retry?

Did it change its original plan?

Which actions affected an external system?

These questions matter because trust depends not only on the final result but also on being able to inspect how the result was produced.

This is where the conventional chat interface starts to become inadequate.

A chat transcript records conversation. A long-running agent needs something closer to an audit trail.

That might include tool-call logs, timestamps, checkpoints, source records, approval history, changes to external systems, and explanations for important decisions.

Google’s recent agent tooling reflects this shift toward explicit workflow control, including branching, retries, human approval and other forms of orchestration that become necessary in production applications. (Google Developers Blog)

For enterprises, observability may become one of the most important parts of agent infrastructure.

You cannot reliably govern a system if you cannot reconstruct what it did.

The Most Important Skill May Be Knowing When to Stop

Autonomy is often presented as a simple spectrum.

The less human involvement, the more advanced the agent.

That is probably the wrong way to measure it.

A useful agent does not necessarily complete every step by itself. It completes the steps it can handle safely and recognizes when the next action carries enough risk to require a person.

Consider three actions:

Research a vendor.

Draft a purchase request.

Transfer $100,000 to the vendor.

Technically, an agent may eventually be capable of doing all three. But capability does not mean it should receive identical authority for all three.

This is why human approval should not necessarily be viewed as a failure of automation. In many environments, it may be what makes broader automation possible.

The agent can handle the repetitive 95% of a workflow and stop for the consequential 5%.

Google’s current agent framework explicitly includes human-in-the-loop steps as part of production workflows rather than treating them as an exception. (Google Developers Blog)

In practice, trustworthy autonomy may therefore look more like graduated permission.

An agent can read the database but not delete records.

It can draft an email but needs approval before sending it externally.

It can prepare a payment but cannot authorize it.

It can deploy to a test environment but not production.

This is not very different from how organizations already manage employees.

The important question is not whether someone can technically perform an action. It is whether they have permission to do it without review.

More Autonomy Can Actually Increase the Need for Control

There is a paradox at the center of agent adoption.

As agents become better, people naturally begin supervising them less.

Anthropic’s analysis of millions of real-world agent interactions found that the longest-running Claude Code sessions had nearly doubled in autonomous duration within just three months, from under 25 minutes to more than 45 minutes. (Anthropic)

That is exactly what successful automation should produce: less human attention.

But less attention also means an error may travel farther before anyone notices.

This becomes especially important once agents move beyond generating information and start changing real systems.

There is a major difference between:

“Here is the email I recommend sending.”

and:

“I sent the email.”

The same applies to modifying a customer account, updating production code, booking travel, cancelling a subscription, issuing a refund, or approving an expense.

Once the agent can change state outside the conversation, mistakes stop being purely informational.

They become operational.

The safer approach is therefore not necessarily less autonomy. It is autonomy with carefully defined boundaries.

Long Tasks Also Create a Cost Problem

Reliability is not only about avoiding errors.

A long-running agent can also become inefficient.

An agent may repeat searches, call the same tool unnecessarily, revisit already completed steps, or enter a loop that consumes large amounts of tokens and compute without making meaningful progress.

This is another reason “task completed” is an incomplete metric.

Microsoft’s STATE-Bench also measures agent efficiency, including unnecessary tool calls, conversation turns, and token usage. (Microsoft Open Source)

That is likely to become increasingly important as companies deploy multiple agents at the same time.

A single inefficient task may not matter much. Hundreds or thousands of unnecessarily long workflows can become a meaningful infrastructure cost.

The economics of agents therefore add another dimension to reliability.

A production agent should not only finish correctly.

It should finish correctly without using wildly unpredictable amounts of time and compute.

That makes reliability partly a financial issue as well.

Predictable Autonomy May Matter More Than Maximum Autonomy

For the last few years, demonstrations of AI agents have often focused on how much they can do without assistance.

That made sense while the technology was new.

But as agents become part of everyday work, the standard will probably change.

The most valuable system may not be the one that runs independently for the longest time.

It may be the one whose behavior is easiest to predict.

That means a production-ready agent needs more than a capable model. It needs reliable state, clear permission boundaries, deterministic rules for critical steps, logs that show what happened, ways to recover from failure, cost controls, and carefully chosen points for human review.

OpenAI’s own data shows that users are already moving from short AI interactions toward longer delegated work. (OpenAI) The infrastructure surrounding those agents therefore becomes more important as the length and consequence of their work increase.

This changes the competitive question.

A few years ago, the obvious question was:

Which model gives the smartest answer?

For agents, a more useful question is emerging:

Which system can repeatedly complete meaningful work without creating unacceptable risk?

So, Can You Trust an AI Agent to Work for Hours?

In some cases, yes.

But duration itself is not evidence of trustworthiness.

An agent that can keep working for eight hours is impressive. An agent that can work for eight hours while preserving the correct state, following company rules, recovering from failures, using resources efficiently, recording what it did, and stopping before a risky action is much more valuable.

That distinction matters because the hardest agent problems are moving beyond the model itself. The model provides reasoning and flexibility. The surrounding system provides memory, permissions, monitoring, deterministic controls, recovery and accountability.

Together, those determine whether autonomy is actually useful. The next major breakthrough in AI agents may therefore not be longer autonomy.

It may be predictable autonomy. The real milestone will not be the moment an agent can work all day without us.

It will be the moment we are comfortable letting it do so because we know what it is allowed to do, how we can verify what it did, and when it will stop and ask us to step in.

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다