Designing a human in the loop AI agent that knows when to wait

Which actions should wait for a person

A simple test works for most teams. Ask three questions about each step. Can it be undone easily? Does anyone outside the team see the result? Does it change a record that other people rely on? If any answer points to risk, that step is a candidate for an approval gate.

In Crons the defaults follow the same logic. Emailing customers, writing to a CRM and posting to public channels sit behind approval gates, and payments are never executed by a cron at all. You can tighten these defaults, and the approval gates page describes the options.

Placing approval gates in the workflow

Put the gate directly in front of the risky step, not at the start of the run. The agent should do all the safe preparation first, so the approver sees a finished draft rather than a plan. For a weekly renewal reminder cron, that means fetching the account list, drafting each email and grouping them before asking anyone to look.

1. 1Run the safe steps automatically: fetch, read, analyze and draft.
2. 2Bundle the proposed actions into one approval request with a clear summary.
3. 3Show the exact output, such as the full email text and the list of recipients.
4. 4Let the approver approve all, approve some, edit or reject.
5. 5Continue with only the approved items and record the decision.

Batching matters. Twenty separate approval pings get rubber stamped. One request that says "20 renewal emails ready, 2 flagged because the account has an open support ticket" gets read. Ask the AI step to highlight anything unusual so the reviewer knows where to look.

Who approves and how roles work

The right approver is the person who would be accountable if the action went wrong. For customer emails that is usually the account owner or the customer success lead. For CRM bulk updates it is the sales operations owner. For public posts it is whoever owns the brand voice.

• Name a primary and a backup. Vacations and sick days should not stop a weekly cron.
• Separate the builder from the approver for high risk actions, so one person is not checking their own work.
• Keep viewers out of the loop. On Pro, roles are owner, editor and viewer, and viewers can read run logs without approving actions.
• Use team rules for larger groups. On Teams, approval rules can be set per team, so finance approvals go to finance and marketing approvals go to marketing.

Send approval requests where the approver already works. A Slack message with the draft and approve or reject buttons gets a faster answer than a link to another dashboard. Email works well for approvers who are rarely in Slack.

Timeouts and what happens when nobody answers

Every approval needs a timeout and a default outcome. Without one, a pending request either blocks the next run or lingers until the drafted content is stale. Decide in advance what silence means.

The safe default for anything external is to cancel, never to proceed. An agent that sends an email because nobody objected is not a human in the loop design. Send a reminder at the halfway point and an alert when a request expires, so the owner knows work was dropped.

Building an audit trail you can rely on

Approvals only protect you if you can reconstruct what happened later. Every run in Crons keeps a full log of each step with its input, output, retries and timing, and approval decisions are part of that log.

• What the agent proposed, exactly as the approver saw it.
• Who approved, edited or rejected it, and when.
• Any edits the approver made before approving.
• What was actually sent or written after the decision.
• Timeouts and the default action that followed.

Retention depends on the plan. Starter keeps run logs for 30 days, Pro for 90 days with CSV export, and Teams for one year with a separate audit log of account activity. If your compliance team needs a longer history, export the logs on a schedule into your own storage. The security overview explains how logs and credentials are handled.

Testing with dry runs before going live

A dry run executes the whole workflow but stops before any step that would send, post or write. You see exactly what the agent would have done, step by step, without anyone outside your team noticing.

1. 1Run the cron in dry run mode on real data for one or two cycles.
2. 2Read every proposed action, not just the summary.
3. 3Adjust instructions where the drafts are off in tone or content.
4. 4Turn on live mode with approval gates still in place.
5. 5Relax a gate only after several weeks of approvals with no edits.

That last step is how trust is earned. If the account owner approved forty weekly digests without changing a word, moving that step to automatic is reasonable. If they edit half the drafts, the gate is doing real work and should stay.

A worked example for customer success

Picture a 40 person SaaS company that wants to email customers whose product usage dropped sharply. The description in Crons reads: "Every Tuesday at 9 AM, pull accounts from HubSpot whose weekly active users fell by more than 30 percent, draft a short check-in email from the account owner, and send the batch to the customer success lead in Slack for approval before sending."

The cron fetches usage data, compares it with last week from memory, drafts emails and posts one approval request. The lead approves twelve, edits two and rejects one account that is already in a renewal conversation. Only the approved emails go out through Gmail, and a note is added to each HubSpot record after sending. The same pattern appears in the customer health digest template, and you can explore more customer success automation ideas.

The person spends ten minutes a week on review. The agent does the hours of data pulling and drafting. That is the trade a good human in the loop AI agent should make.