AI workflow automation starts at the handoffs

AI workflow automation works best when you start by looking at where work changes hands. Before choosing an agent or connecting an app, follow a piece of work through your team. Find the points where someone receives information, checks it, makes a decision or passes the result to another person. Those transitions are often where an AI agent can save time. They are also where a person may need to check what happens next.

Consider a weekly report. Writing it might take ten minutes, but collecting figures, checking spreadsheets, chasing missing information and getting permission to share the result can take much longer. Automating the writing alone leaves most of the delay untouched. A better design starts with the entire route that information takes through the team.

Map the actual movement of work

Choose one recurring process and trace it from the first request to the completed result. A customer support request is a useful example. It arrives by email, gets assigned to a colleague, requires information from an order record and may need a refund decision before anyone can reply.

Record what happens each time the work changes hands. Who receives it? What information do they need? Where does that information come from? What makes them pass the task to somebody else? Include the small checks and follow-up messages that rarely appear in an official process document.

Job titles alone do not explain a handoff. Saying that support handles a ticket and finance handles the refund tells you little about the information that moves between them. In this example, support might need to provide the order number, the customer's explanation, delivery status and requested refund amount. If the order number is missing, finance has to stop and ask for it.

A useful map needs only four things: the starting request, the information passed between people or systems, the decisions made along the way and the final result. A page of notes is enough. The aim is to describe what people actually do, not reproduce an idealised process that nobody follows.

Separate preparation from business decisions

Once the handoffs are visible, examine the work at each transition. Some stages involve finding and organising information. Others require someone to decide what the business should do. An agent can often handle the preparation without taking responsibility for the decision.

For example, an agent can collect order details, compare them with a supplied refund policy and prepare a recommendation. A person can review the evidence and decide whether to issue the refund. The same division works in sales: an agent can research a company and draft an introductory email, while a person checks the recipient and approves the first contact.

This distinction prevents a common design error: giving an agent permission to perform an action simply because it can prepare everything needed for that action. Preparing a refund request does not require permission to move money. Drafting a customer reply does not require permission to send it. The workflow should treat those as separate steps.

Place checkpoints where mistakes have consequences

Not every transition needs approval. If an agent is organising documents into a specified folder structure, stopping after every file would create unnecessary interruptions. The person has already defined the task and can inspect the finished result.

The situation changes when an action affects something outside the workspace. Sending a message, paying an invoice, issuing a refund, publishing a page or changing an existing business record can have consequences that are difficult to reverse. Put a checkpoint immediately before that action.

A useful approval request must show the reviewer what will actually happen. A notification saying that an agent wants permission to continue is insufficient. The person needs to see the intended action, the relevant information and any cost involved.

Take an outreach workflow. An agent researches a company, identifies a possible contact and drafts a message using an internal sales brief. Before the message goes out, the reviewer should see the exact recipient and complete text. Approval of a vague instruction to contact prospective customers would leave too much room for an error.

Some actions should always require a person's approval, regardless of how routine they appear. These include first contact with anyone outside the workspace, moving money or issuing refunds, deleting or overwriting records the agent did not create, changing roles or its own policy, connecting integrations or widening permissions, accepting terms or signing, publishing publicly and acting in another workspace.

Build these restrictions into the workflow itself. A written instruction to be careful is not a substitute for a system that stops before an action requiring approval.

Account for corrections and return paths

Work does not always move in one direction. A reviewer may reject a draft, a missing detail may send a task back to its source, or two records may disagree. If the workflow only describes the forward route, these situations leave the agent without a clear next step.

Decide what the agent should do when something goes wrong. Can it ask a specific question about a missing order number? Should it stop when two sources contain different figures? Can it revise a message after a reviewer requests a shorter version?

The distinction between correction and permission matters. A reviewer who asks for a shorter customer reply has authorised a revision, not the act of sending it. The revised message must still pass through the appropriate approval point.

Set a hard budget for each delegation before work starts. Keep an append-only activity log of tool calls, approvals and policy changes. If the agent reaches its budget limit or encounters a situation outside its instructions, it should stop and ask rather than quietly expand the task.

At Delagents, we organise delegated work around a brief, a budget and a result. An agent carries out the assigned work and stops at checkpoints where a person must sign off. Actions with effects outside the workspace wait in an approvals inbox. Each card shows the exact action, the cost so far and a deadline. The reviewer can approve, change or reject it. This gives the team a defined place to handle consequential decisions without requiring someone to supervise every internal step. See how delegations work.

Test one handoff before expanding

A complete workflow map can make a complicated process look ready for automation. Start smaller. Choose one handoff where the inputs are reasonably consistent, the expected result is easy to inspect and an error will not cause an irreversible change.

A weekly sales report is a reasonable first test. Give an agent a reporting brief and access to approved information sources. Ask it to collect the figures, identify missing entries and prepare a draft with references to the underlying records. A person checks the figures and decides whether the report is ready to share. Sending or publishing it remains a separate approved action.

For the first few runs, compare the agent's work with the process your team already follows. Check the figures, assumptions and sources. Pay particular attention to exceptions, such as an unfamiliar spreadsheet, a missing reporting period or conflicting numbers. These cases show where the instructions need more detail and where the agent should stop.

Define what a successful handoff looks like before the test begins. The receiving colleague should get the information in a usable format, understand what has already been checked and see which questions remain open. If they still have to reconstruct the work from several messages and files, the automation has simply moved the delay to another desk.

Once the first handoff works reliably, consider the next one. Keep its permissions separate and retain the approval point attached to the action that needs it. A successful test is not a reason to give an agent broader access to every connected system.

Choose your first workflow

Start with a recurring process that crosses at least two people or systems. A supplier invoice, a new customer enquiry or a weekly report will give you enough material to examine. Ask the people who handle it to walk through one recent example, including the messages and checks that happened between the official steps.

Mark each handoff where an agent could gather information or prepare a result. Separately mark the actions that require a person's approval, particularly anything that sends, pays, publishes or changes an existing record.

Then select one handoff and write a short test brief. Specify the information the agent may use, the result it must return, its budget and the conditions that require it to stop. Run that task alongside the existing process and ask the receiving colleague whether the result is ready to use. That single test will tell you more about the right design for your AI workflow automation than choosing a tool first.