AI Agents in Recurring Work

Executive summary

AI agents are becoming participants in ongoing business operations. Research and market developments gathered over the past three months show organizations moving beyond individual AI assistance toward agents that execute tasks within business processes. That shift brings a more demanding question into focus: what makes their work reliable, reviewable, and accountable over time?

The evidence points to a gap between agent adoption and the controls surrounding it:

• Independent action is already widespread among surveyed adopters. In EY’s survey of leaders at large US public companies, 85% of respondents whose organizations use agentic AI reported that at least some agents execute actions without real-time human involvement.
• Confidence is ahead of implemented controls. Harness found that 74% of respondents were confident their testing would catch a production-impacting failure, while only 19% reported an automatic gate to block bad releases.
• Verification remains a substantial operational burden. In a Collibra/Harris Poll survey, 51% of decision-makers reported spending significant staff hours manually reviewing and correcting autonomous agent outputs before they went live.

These studies examine different populations and cannot be combined into a single measure of enterprise readiness. Their findings nevertheless identify a consistent challenge: organizations are expanding what agents can do while still establishing how that work is checked, controlled, and managed.

Model capability alone does not establish operational reliability. An agent’s ability to perform a task must be supported by current context, appropriate permissions, clear responsibility, and a process for review and recovery. In recurring work, those conditions need to hold on every run.

This report examines the research through the lens of accountable execution. Its central argument is that teams should match autonomy to how reliably an action can be verified, how consequential an error would be, and how easily the result can be reversed. Review, approvals, and exception handling should be designed into the work, with people responsible for consequential decisions and follow-up.

Manifestly’s role is to make those responsibilities explicit within recurring workflows. Teams can assign agents defined steps, provide instructions and context, configure human review where needed, and keep workflow outputs and completion history together. These workflow arrangements operate alongside permissions and controls enforced by agent runtimes and connected systems.

As agents take on more operational work, organizations need to evaluate success at the level of the process: whether the right work happened, on time, with appropriate review, a record of the result, and someone accountable for what happens next.

What changes when an agent joins recurring work?

The move from AI assistance to agent execution changes what an organization needs to manage. When an agent takes on an ongoing assignment, the team has to establish when it acts, what information it uses, which actions it can take, and how its work reaches the next person or system.

EY’s September 2026 survey makes the shift concrete. Among senior AI executives whose organizations use agentic AI, 85% reported that at least some agents execute actions without real-time human involvement. The survey covered large US public companies, so the finding should be read within that population. It establishes that independent action is already part of enterprise AI use; it does not establish whether those actions are consistently reliable.

For recurring operations, independent execution creates responsibilities that extend beyond the agent’s immediate task. The work has to begin with current information, happen at the right point in the process, and produce a result that someone can use. Missing inputs, uncertain findings, and failed actions need a defined response.

Consider a recurring IT access review. An agent could compare account lists with employee records and flag access that appears unnecessary. That assignment could reduce the effort required to prepare the review. But completing the process involves several distinct responsibilities:

A useful list of flagged accounts completes the agent’s preparation task. The access review finishes when the findings have been resolved, approved changes have been made, and completion has been verified.

That distinction matters because task performance and process reliability answer different questions. Task performance asks whether the agent produced an acceptable result. Process reliability asks whether the right work happened across the full sequence, with appropriate timing, review, and responsibility.

Recurring work adds another requirement: the sequence must hold on the next run. Employee roles change, source data can become incomplete, and a reviewer may be unavailable. An exception discovered this month may require a change to next month’s instructions. The process needs a way to accommodate those conditions without relying on someone to remember every adjustment.

This does not require a person to approve every agent action. It requires the team to decide where independent execution is appropriate and where verification, authorization, or judgment belongs. In the access-review example, an agent might prepare findings independently while a system owner resolves exceptions and an authorized administrator handles consequential changes.

The same design question applies to financial close, maintenance checks, and recurring reporting. An agent can take on a defined part of the work, but the organization remains responsible for the process and its outcome.

As teams expand agent assignments, they need to evaluate the surrounding process as carefully as the agent’s output. The next section examines whether organizations’ confidence in their agents is supported by the controls they have actually put in place.

Confidence needs working controls

Two enterprise surveys reveal a consistent gap between leaders’ confidence in their agents and the controls they report having in place. The gap appears across three responsibilities: preventing faulty work from reaching production, stopping an agent when something goes wrong, and limiting what it can access.

Harness’s State of Agent DLC 2026 surveyed 700 technology professionals at large enterprises across five countries. Cequence Security and Enterprise Management Associates surveyed 202 IT and security leaders at organizations with at least 1,000 employees that were deploying or evaluating agentic AI. Their findings address different controls, but expose a similar distance between belief and implementation.

Each comparison raises a practical question about how the work is managed.

Prevention: what happens when a check fails?

Testing helps a team assess whether an agent is ready for an assignment. A release gate determines whether a change can proceed when required checks have not passed. Both depend on the quality of the checks themselves; an automatic gate cannot guarantee that every defect will be detected.

For recurring operations, the corresponding design question is where verification belongs and what its result changes. In an IT access review, missing employee records should have a defined consequence: pause the affected review, request the information, or escalate to the system owner. The process should establish that response before the agent encounters the problem.

Intervention: how does execution stop?

A response plan needs a working way to interrupt execution and a person authorized to use it. The team also needs to understand what stopping the agent leaves behind: queued actions, partially completed work, and changes that may already have reached another system.

For an agent preparing access-review findings, interruption may mean pausing analysis. For an agent authorized to modify accounts, it may require suspending credentials or stopping an integration. The appropriate mechanism depends on what the agent can do and where those actions occur.

Permissions: what can the agent actually reach?

Least-privilege access limits an agent to the systems, data, and actions required for its assignment. In the access-review example, preparing recommendations may require read access to account and employee records. Permission to disable accounts is a separate decision.

Step instructions can describe that boundary, but the connected systems must enforce it. The agent’s credentials and available tools should reflect the scope of its job.

These comparisons measure related but distinct conditions. A team may have alternative safeguards, and the presence of a named control does not establish that it works effectively. Our operational interpretation is that confidence should be supported by evidence of how boundaries, checks, and intervention work during execution.

Accountability becomes practical when a rule changes what can happen next. A failed check pauses the work. A permission blocks an unauthorized action. An exception reaches a person who can resolve it. Those behaviors need to hold each time the process runs.

A policy has to hold during the work

Formal AI governance is widely established among the large enterprises surveyed by EY. Applying it consistently remains a challenge. In its September 2026 study of 202 senior AI decision-makers at US public companies with at least $1 billion in annual revenue, 98% reported having formal AI governance policies. Yet 47% said their organization had previously bypassed its governance process for urgent deployments.

The finding concerns deployment decisions, rather than individual workflow steps. It nevertheless raises an important operational question: how does a policy remain effective when teams face pressure to move quickly?

A policy establishes expectations. Making those expectations hold requires defined responsibilities, enforceable boundaries, and a practical route for handling exceptions. If urgent work needs a different approval path, that path should identify who can authorize it, which checks still apply, and what must be recorded.

Visibility presents another challenge. Dataiku’s September survey, conducted by The Harris Poll among 685 CIOs across eight countries, found that 81% lacked complete oversight of agents created outside approved systems or formal channels. Separately, 84% agreed that employees were creating AI agents and applications faster than IT could govern them. These findings describe leaders’ reported oversight difficulties, rather than an audit of individual agents.

For an operations team, incomplete oversight leaves basic questions unanswered: which agent is carrying out the assignment, what systems can it reach, who approved its use, and who responds if its work fails?

Executive responsibility is only part of that answer. Collibra’s survey found that 84% of respondents reported clearly defined executive accountability when autonomous agents produce flawed or harmful outputs. That establishes a reported leadership responsibility; it does not establish how responsibility is assigned during a particular run.

In the recurring IT access review, responsibility needs to be explicit at several points. Someone maintains the review criteria and source information. A system owner resolves exceptions. An authorized person approves consequential changes. Someone confirms that the approved work was completed.

Those responsibilities become especially important when the normal sequence cannot proceed. An employee record may be missing, two systems may disagree, or the designated reviewer may be unavailable. The process should identify who receives the issue, what pauses, and how work resumes. Otherwise, the team has to reconstruct the decision path while the work is already waiting.

Our interpretation of the research is that governance needs a connection to execution. Organization-wide policy sets the expectations; permissions, workflow responsibilities, reviews, and exception paths put those expectations into practice.

This is also a design question, rather than simply a demand for greater individual discipline. When applying a rule requires people to find the right document, identify an approver, and coordinate a response from scratch, the process places a substantial burden on memory and judgment.

Accountability should be clear before something goes wrong. In recurring work, that means people can identify who may act, who must decide, and who owns the follow-up during each run.

Someone still has to check the output

Agent execution changes where people spend their time. A task may take less effort to prepare while still requiring substantial work to verify, correct, and approve.

Collibra’s 2026 Hallucination Tax Report, based on a Harris Poll survey of 306 US data, privacy, and AI decision-makers, found that 51% spent significant staff hours manually reviewing and correcting autonomous agent outputs before they went live. The same study reported that 76% had encountered critical roadblocks moving from pilot programs into full production over the preceding 12 months.

These findings establish reported operational burdens. They do not measure the net productivity of each deployment or show that review caused the production roadblocks. They do, however, make verification effort an important part of evaluating an agent’s contribution.

For recurring work, the practical question is how much effort it takes to establish that an output is ready to use. A reviewer needs the relevant sources, the criteria used, unresolved questions, and enough evidence to assess the result. When those elements are missing, checking can require reconstructing much of the original task.

In an IT access review, a list of accounts recommended for removal may look complete. But the system owner still needs to understand why each account was flagged. Was the employee marked as having left the organization? Did their role change? Is the account shared, or does it support an automated service?

An assignment that requires the agent to include its source records, reasons for flagging, and uncertainties gives the reviewer a more useful starting point. The person can assess the proposed changes and investigate exceptions with the relevant information in view.

Our operational interpretation is that verification should be designed into the assignment and its handoff. Four decisions help make that work explicit:

These arrangements support human judgment. They also make review effort visible. A recurring process can track how often outputs require correction, what information reviewers repeatedly need, and where work waits for a decision.

That record matters when evaluating value. If an agent produces findings quickly but every run requires extensive reconstruction, the team needs to examine the assignment, source data, or capability before expanding its use. If reviewers can resolve the findings with less effort and appropriate confidence, the agent is contributing to the process.

Review is part of the work. Its time, evidence requirements, and follow-up should be included when assessing an agent’s performance. Faster preparation becomes operationally useful when it helps the team reach verified completion.

Decide what the agent can do on its own

Autonomy is a decision about a specific assignment. The team needs to establish which actions an agent may take independently, which require approval, and which remain a person’s responsibility.

Akamai’s September 2026 State of the Internet security report offers a practical principle: grant autonomy according to how easily an action can be verified and how reversible a potential failure is, while retaining human involvement for high-stakes actions.

For recurring operations, we apply that principle through four questions:

These questions should be answered for the actual action and its context. Preparing a recommendation, sending it to a customer, and applying it to a production system carry different consequences, even when they begin with the same analysis.

Verification needs a dependable basis

An output can be easy to read and difficult to verify. A reviewer may understand an agent’s access recommendation but still lack the records needed to determine whether it is correct.

Verification therefore requires more than a clear explanation. The team needs appropriate source information and criteria against which to check the result. Where dependable automated checks are available, they can support independent execution. Where the decision depends on context those checks cannot establish, a person needs to evaluate it.

Reversibility includes the effects of the action

An account can sometimes be re-enabled after an incorrect access change. That does not undo the interruption to someone’s work. A financial entry may be corrected while still requiring additional review or affecting a report already distributed.

The autonomy decision should account for those consequences. Technical rollback is one part of recovery; it does not establish that an error is inexpensive or harmless.

Repetition needs its own checks

Recurring execution adds exposure over time. An outdated employee record could influence several reviews. A flawed rule could produce the same incorrect recommendation each month.

Our extension of Akamai’s principle is that recurring assignments need checks for changes in inputs, instructions, and results. Review frequency should reflect the consequences and volume of the work, with a defined response when performance falls outside acceptable limits.

Applied to an IT access review, the design might look like this:

These are illustrative choices. Each organization needs to assess its systems, policies, and consequences before setting the boundaries.

Human approval also needs enough information to support a decision. A checkpoint should identify the proposed action, relevant evidence, unresolved uncertainty, and what approval permits. Otherwise, the process asks someone to accept responsibility without giving them a sound basis for doing so.

Useful autonomy has explicit limits. Once those limits are defined, the workflow can establish when the agent proceeds, when it pauses, and who owns the decision that follows.

Make review and exceptions part of every run

Once a team has decided what an agent may do independently, those decisions need to shape how the work runs. The assignment needs current inputs, a clear completion standard, and a defined handoff. Checks must occur before the actions they govern. When something fails, the process needs to identify what pauses and who responds.

Anthropic’s internal monitoring provides one example of oversight built into execution. In its most-used internal research and engineering platform, Anthropic reported that 100% of agent actions passed through an automated online monitor before execution. Across more than a billion decisions in August 2026, the monitor blocked 0.002%; humans reviewed blocked actions within one week. Offline monitors also examined activity after execution and escalated selected findings. These are self-reported measurements covering that platform, rather than all Anthropic agent activity.

The low blocking rate does not establish that every harmful action was detected. The relevant design choice is that oversight had defined coverage, timing, and escalation. Automated execution operated within a system that could intervene and route issues to people.

For recurring business operations, our interpretation is that the same discipline should apply to assignments, reviews, and exceptions.

Define completion before execution begins

A task description should establish what the agent receives, what it must produce, and what conditions prevent it from completing the assignment.

For an IT access review, that might mean comparing specified account and employee records, providing a reason and source for each flagged account, and identifying missing information. The agent should be able to report an incomplete review when the available evidence cannot support a conclusion.

A completion standard gives both the agent and reviewer a basis for assessing the work. It also distinguishes a finished analysis from a partially executed attempt.

Place checks before the actions they govern

An approval should apply to a specific proposed action. If a system owner approves removing access from three accounts, subsequent execution should remain within that scope. Material changes to the proposal need another decision.

Workflow sequencing coordinates that handoff. Permissions and execution controls in connected systems enforce which actions can actually occur. Both need to support the intended boundary.

Give exceptions an owner and a next step

Recurring processes encounter missing inputs, conflicting records, unavailable reviewers, and failed actions. Each condition needs a response that people can follow without reconstructing the process.

Recovery also needs to account for partial execution. Before retrying a failed action, the team should establish whether it already took effect. Otherwise, a retry can duplicate work or introduce another error.

Keep the evidence with the work

The record should let a reviewer establish what was assigned, which output was reviewed, what was approved, and how completion was confirmed. Where actions occur in external systems, relevant logs or confirmation evidence may need to be linked or captured separately.

That record also supports improvement across runs. Repeated requests for the same missing information may reveal an input problem. Frequent rejection may indicate unclear instructions or a task beyond the agent’s capability. Recurring exceptions may require a change to the process itself.

A reliable workflow defines what happens when work cannot proceed. Agents can then carry out their assignments within known boundaries, while people can see where a decision, correction, or recovery is needed.

Two recurring workflows, step by step

The principles become concrete when applied to a full sequence of work. The following examples illustrate how teams might divide responsibilities between agents and people in an IT access review and a monthly financial close. They are proposed workflow designs, rather than measured deployments or claims about particular integrations.

In both examples, agents receive defined preparation tasks. People evaluate exceptions and authorize consequential actions. Completion requires evidence appropriate to the work.

IT access review

An access review needs to establish whether access remains appropriate, resolve exceptions, and confirm that approved changes happened. An agent can help prepare findings when it has authorized access to sufficiently complete records.

If an employee’s status is unclear, the affected decision pauses until the responsible person resolves it. If a change fails, the workflow assigns recovery and keeps the review open for that item. Before a retry, the administrator checks whether the original action took effect.

The agent’s findings support the review. The completion record establishes which decisions were made and which changes were verified.

Monthly financial close

A financial close brings together source information, reconciliations, adjustments, review, and final approval. A defined agent assignment might consolidate missing items, organize unresolved questions, or draft commentary from reconciliations and explanations supplied by the finance team.

The agent should flag a missing explanation for a variance rather than invent one. If a figure changes after commentary has been reviewed, the affected output returns for revision and review. If a required reconciliation remains incomplete, the close follows the team’s defined exception and authorization process.

This design gives the agent a useful role without assuming it can independently make accounting judgments or operate the financial system.

What these designs establish

Each assignment has a completion standard, and each handoff identifies who acts next. Approval applies to a defined proposal or output. Failed actions and unresolved questions have owners. The record distinguishes preparation, authorization, execution, and verification.

Those distinctions also help teams measure the agent’s contribution. They can examine whether preparation takes less time, whether reviewers receive sufficient evidence, how often correction is needed, and whether the full process reaches completion on schedule.

As teams gain experience across runs, they can revise the assignment or expand its scope. That decision should reflect demonstrated performance, effective checks, and the consequences of the additional actions.

An agent becomes useful in recurring operations when its work fits into a sequence the team can run, review, and complete with clear responsibility.

Recommended practices for running work with clear responsibility

The research reviewed in this report points to a practical priority: as teams expand agent assignments, they need to make responsibility, verification, and exception handling explicit within the work.

The following recommendations apply those findings to recurring operations. They are design principles informed by the research, rather than a workflow model directly tested by the studies.

Start with a defined assignment

Choose a recurring process the team understands and a task with available inputs and a clear completion standard. Preparing a missing-item summary or organizing access-review findings can provide a useful starting point when the required information is accessible.

Before execution begins, establish what the agent receives, what it must produce, which actions it may take, and which conditions require it to pause. Name the person responsible for reviewing the result and resolving exceptions.

Make review part of the handoff

Give reviewers the information needed to assess the work: relevant sources, acceptance criteria, proposed actions, and unresolved uncertainty. Place approvals before the action it governs, and make its scope clear.

Review effort belongs in the assessment of the assignment’s value. Faster preparation helps when the resulting output can be checked and used with an appropriate level of effort.

Define what happens when work cannot proceed

Missing information, conflicting records, rejected outputs, and partial execution need defined responses. Identify what pauses, who receives the issue, and what permits work to resume.

Before retrying a failed action, establish whether it already took effect. Recovery should account for the actual state of the work.

Keep evidence of decisions and completion

Retain enough information to establish what was assigned, what was reviewed, what was authorized, and how completion was verified. Where actions occur in external systems, include relevant confirmation or references to supporting logs.

A completion status should have an appropriate basis in evidence. That basis will differ between preparing a draft, changing access, and closing a financial period.

Evaluate performance across repeated runs

A single successful output demonstrates performance under one set of conditions. Several runs reveal how the assignment handles changing inputs, exceptions, and review requirements.

Use those results to adjust the assignment before expanding autonomy. Repeated corrections may require better source information, clearer criteria, or a narrower task. Consistent performance can support broader delegation when permissions, checks, and recovery arrangements remain appropriate.

These practices align with how teams can use Manifestly: assigning people and agents defined workflow steps, configuring review and approvals where needed, and keeping outputs and completion history with each run. Their implementation also depends on the agent runtime, connected systems, and the people responsible for the process.

The next agent assignment should come with a clear answer to what happens afterward: who checks the result, who resolves the exception, and how the team knows the work is complete.

As agents do more, accountability needs to be built into the work

As agents take on more recurring work, organizations need to evaluate their performance within the processes they serve. A useful output matters. So does the effort required to verify it, resolve exceptions, and carry the work through to completion.

The research reviewed here shows gaps between confidence and implemented controls, between formal policy and consistent application, and between agent execution and the work required to check it. Those findings make accountability a practical design requirement.

For teams expanding agent use, the next step is to define responsibility alongside the assignment: what the agent may do, what requires review, who handles uncertainty, and what evidence establishes completion. Evaluate those arrangements across repeated runs before extending autonomy.

The more work a team delegates, the more clearly its process needs to answer one question: Did the right work happen, on time, with someone accountable for the result?

Put accountable execution into practice

Start with one step in a recurring workflow your team already runs. Define the agent’s task, assign a person to review the result where needed, and decide what happens when the work cannot proceed.

Manifestly brings those assignments, handoffs, reviews, and completion records into the same workflow.

Start a free trial of Manifestly and give AI a step in the work while keeping a person accountable.

---

Methodology and sources

This report synthesizes published enterprise surveys and security research gathered during the three months leading up to October 2026. Manifestly did not conduct an original survey for this report.

Statistics are presented as reported by their publishers. The studies cover different populations, regions, and questions; their findings are not pooled into a single estimate of enterprise AI adoption or readiness. Comparisons between confidence and implemented controls describe related measures, rather than equivalent questions.

Several sources were commissioned or published by companies that sell AI governance, security, or delivery products. Survey responses reflect participants’ reported experiences and practices, rather than independent audits of their organizations.

The workflow recommendations are Manifestly’s interpretation of the research. The IT access review and monthly financial close examples are illustrative designs, not measured deployments or claims about specific integrations.

Sources cited

Harness — State of Agent DLC 2026

Survey of 700 technology professionals at large enterprises in the US, UK, France, Germany, and India; conducted by Sapio Research in July 2026. Release published September 10, 2026. 74% expressed confidence that testing would catch a production-impacting failure; 19% reported an automatic gate to block bad releases. 76% believed they could disable a misbehaving agent within 15 minutes; 33% had an instant kill switch.

Cequence Security / Enterprise Management Associates — Agents Without Guardrails

Survey of 202 IT and security leaders at organizations with at least 1,000 employees that were deploying or evaluating agentic AI. 94% were confident agents had no more access than needed; 33% provisioned agents with least-privilege access.

EY — AI Risk and Governance Survey

Survey of 202 senior AI decision-makers at US public companies with at least $1 billion in annual revenue; fielded May 28–June 15, 2026. Published September 15, 2026. Among respondents whose organizations used agentic AI, 85% reported some agents acting without real-time human involvement. Across the survey, 98% reported formal governance policies and 47% reported previously bypassing governance for urgent deployments.

Collibra / The Harris Poll — 2026 Hallucination Tax Report

Online survey of 306 US data, privacy, and AI decision-makers at director level or above; fielded August 5–11, 2026. 51% reported significant staff hours reviewing and correcting agent outputs; 76% reported roadblocks moving from pilot to production; 84% reported defined executive accountability for flawed or harmful outputs.

Dataiku / The Harris Poll — Global AI Confessions Report: CIO Edition, 2026

Online survey of 685 CIOs across eight countries; fielded July 9–29, 2026. Published September 24, 2026. 81% lacked complete oversight of agents created outside approved systems or formal channels; 84% agreed employees were creating agents and applications faster than IT could govern them.

Akamai — Speed, Scale, and Nonhuman Identity: The Agentic Threat Landscape

State of the Internet security research report; announcement published September 22, 2026. Recommendation to match autonomy to verifiability and reversibility, with human involvement for high-stakes actions.

Anthropic — Measurements for Understanding the Pace of AI Development Inside Frontier Labs

Self-reported internal measurements covering August 2026, including its most-used research and engineering agent platform. On the measured platform, 100% of agent actions passed through an online monitor before execution; 0.002% of more than a billion decisions were blocked. Humans reviewed blocked actions within one week.

Interpretation limits

The presence of a control does not establish its effectiveness, and the absence of a named control does not establish the absence of all safeguards. Reported confidence, review burdens, and production difficulties do not demonstrate causal relationships between particular workflow designs and outcomes.

Anthropic’s monitoring figures cover one internal platform and are self-reported. The blocking rate is not a measure of all harmful activity or monitoring accuracy. Akamai’s guidance is a security recommendation, rather than a controlled evaluation of the workflows illustrated here.