Agentic workflows in the enterprise: where does a person approve?

An agent that drafts an email leaves a person to press send. An agent inside a purchasing workflow can raise the order itself. Once an AI step can change a record, the most important decision in designing the workflow is where it stops and waits for a person.

The organizations getting the most from AI are redesigning the work around it.

What is an agentic workflow?

An agentic workflow is a designed business process in which some steps are carried out by AI agents that can plan, call tools and act on systems. The business defines the path, the data each step may use and the points where a person decides. The agent does the work between those points.

The vocabulary is still settling. In Building effective agentsSource for “Building effective agents”, Anthropic draws the line this way: "Workflows are systems where LLMs and tools are orchestrated through predefined code paths," while agents "dynamically direct their own processes and tool usage." Singapore's Model AI Governance Framework for Agentic AISource for “Model AI Governance Framework for Agentic AI”, published by its media and digital regulator IMDA, observes that "in enterprise deployments, most agentic implementations are hybrid systems combining deterministic rules with some autonomy."

In an enterprise, the design question that matters is where the agent's autonomy ends.

Why is the approval step the hard part?

Because the approval step is where an agent's work becomes the company's decision. Most organizations already run agents of some kind, and few are ready to let them act alone. The approval step lets a workflow use an agent's speed while the company keeps the decisions it has to own.

Which agent actions need a person's approval?

IMDA's framework asks organizations to define checkpoints that require a person's approval, especially before sensitive actions run, and names the kinds of action that qualify. Mapped onto the systems an enterprise runs, they look like this.

The rest can run on its own, logged. A workflow that asks for approval at every step teaches people to approve without reading, and IMDA names the risk directly: requiring people to oversee agents continuously "can also lead to automation bias and alert fatigue."

For AI systems classed as high-risk, oversight is also law. Article 14 of the EU AI ActSource for “Article 14 of the EU AI Act” requires that the people assigned to oversee such a system can "decide, in any particular situation, not to use the high-risk AI system or to otherwise disregard, override or reverse the output" and can "interrupt the system through a 'stop' button or a similar procedure". Under the Digital Omnibus on AISource for “Digital Omnibus on AI”, Regulation (EU) 2026/1744, these obligations apply from 2 December 2027 for the high-risk uses listed in Annex III, and from 2 August 2028 for AI in products covered by Annex I.

Many agents in purchasing, finance and operations fall outside the AI Act's high-risk categories. The design pattern carries over regardless: someone with the authority can stop the agent, and can override or reverse what it did.

How much should a person be involved?

It is set action by action. IMDA describes a range of human involvement, adapted from work at the Knight First Amendment Institute at Columbia University, and one workflow can use several of these levels for different steps:

1. Agent proposes, human operates. The person reviews and approves every agent action.
2. Agent and human collaborate. The agent needs approval at significant steps, such as before writing to a database or making a payment, and the person can take over at any time.
3. Agent operates, human approves. Approval only at critical steps or failures, such as deleting a database or making a payment above a predefined amount.
4. Agent operates, human observes. No approval while the task runs. The actions can be audited afterwards.

A purchasing workflow might let the agent match invoices to orders on its own, wait for approval before it releases a payment, and stop entirely when a supplier's bank details change. When an agent should stop and hand a decision to a person, and who holds the authority to take it, is the subject of what an AI agent must understand before it acts.

How do you ask for approval so people actually read it?

Make each request short, specific and tied to its risk. IMDA's guidance is to keep approval requests "contextual and digestible" and to match the kind of response to the action. In practice:

1. Say what will change, and where. "Release a payment of 48,200 euros to this supplier in the ERP" is a decision a person can take. A page of agent logs leaves them to reconstruct it.
2. Put the evidence beside the request. The order, the invoice, the delivery note and anything unusual, each linked to its source.
3. Match the response to the stakes. Approve or reject for a routine action, editing the agent's plan for a complex one, and a written reason for the highest-risk actions.
4. Send it to the person with the authority. The approver is whoever holds that authority in the business, who may be someone other than the owner of the task.
5. Fail closed. When no approver can be reached, or the agent attempts an action no policy covers, the action waits. IMDA recommends "denying action by default when approval infrastructures fail".
6. Watch the approvals too. Track how often people override the agent and how quickly they approve. Version 1.5 of the IMDA framework added exactly this, "monitoring human override rates and response times", as a guard against automation bias.

What should the record of an approval hold?

Enough for someone a year later to understand the decision without asking anyone: what the agent proposed, what it saw, who approved or rejected it and when, and what changed in which system as a result. An approval is part of the company's records, and it belongs in the same trail as the action it allowed.

That record is also what lets a company relax a rule safely. When a year of approvals shows that one kind of action was approved every time, unchanged, the threshold can move with evidence behind it.

The approval step is where a workflow earns trust, one recorded decision at a time.

Where HIVO OS fits

In HIVO OS, the platform HIVO builds, agents propose and people approve. In Studio the business builds its own workflows, automations, routines and agents, gives every agent a job, an owner and a point where it stops, and tests a rule against past cases before it goes live. Requests reach the person who owns them, routed by department and amount.

In Chat, people ask the business questions, get answers that show their sources, and launch agents. Enterprise Control applies the same rules to every agent and keeps a trail of every action, each entry chained to the one before it. The ERP, the CRM and the systems around them stay where they are.

For the category these parts belong to, see what an enterprise AI platform is. For what an agent needs to know at the moment it changes a record, see what an AI agent needs before it can act.