AI SDR Human in the Loop: An Approval Queue People Actually Read
What the approval card should show, what happens when nobody answers it, and how to find out whether your approver is still reading.
Every AI SDR approval queue works beautifully for the first few weeks.
After that, the person approving starts pressing the button the way you press accept on a cookie banner, the queue keeps moving, and the log keeps saying a human approved every send. Technically true.
The pages that rank for human-in-the-loop AI SDRs cover the setup well. Start with drafts that need approval and hand over more autonomy as the agent earns it. Gate the risky sends instead of every message, so the queue stays small. Let the approver edit or reject from a phone, and keep a record of who approved what. We agree with every word of that, and you will find it below.
What they skip is the human. One of them gives a single sentence to what happens when nobody answers an approval, and none of them deal with what happens when somebody answers without reading. That second case is worse than having no approver at all, because everyone downstream now believes the draft was checked. This page sits on top of our MCP tool permission matrix for outbound agents, which decides which tools get an "ask" setting in the first place, and our guide to AI SDR reply handling, which decides which replies become drafts.
What waits for a click
Less than most teams think. Our rule: if the action puts words in front of a prospect, a person approves it. If the action makes the agent do less (pausing a sequence after a reply, suppressing an address that asked to be removed, skipping a send because the CRM lookup failed), it runs immediately and reports in Slack afterwards.
Cold first touches and replies to interested prospects make up most of the cards. Sequence enrollment is the sneaky one, because a single approval can schedule five to eight touches across email and LinkedIn, and the card for it usually looks smaller than the card for one reply.
What the approval card has to show
Rubber-stamping usually starts with a card that makes reading expensive. If the approver has to open the CRM to understand why this person is getting this email, they will not open the CRM. They will press approve.
The prospect's words, first
Replies onlyIf the draft answers someone, their message sits above it, untrimmed. Approving a reply without seeing what it replies to is guessing.
The draft, exactly as it will send
AlwaysSubject line, body, signature, and the calendar link resolved to the real Calendly or Google Calendar URL. A summary of the draft gets approved much faster than the draft itself, which is the problem.
The research claim, with its source
AlwaysMost cold emails lean on one fact: the funding round, the job posting, the new VP. Show that fact and a link to where the agent found it. This is the line most likely to be made up, and checking it takes a few seconds.
What approve actually does
AlwaysWhich mailbox, which sequence, which step. Approve on a reply sends one email. Approve on an enrollment schedules a whole campaign. The card should say which in plain words.
When it expires
AlwaysA clock time, in the approver’s timezone. More on this below.
Fight for the source line. It is the one teams cut first when someone complains the cards are too long, and it is the only line on the card that catches an agent inventing a fact about a stranger's company.
Silence means no
An approval nobody answers has to expire, and an expired approval must never turn into a send.
Obvious, until the queue backs up during a conference week and somebody proposes auto-approving anything older than a day. Do that and your human in the loop becomes a delay timer with extra steps.
The rules we would write look like this. A cold first touch expires at the end of the business day it was drafted, then goes back into the pool to be redrafted later with fresh research, since a draft that sat for three days is usually about stale news anyway. A reply to an interested prospect expires faster and escalates instead of dying: after a couple of hours it pings the account owner by name, and if that gets nothing it lands in their Gmail as a draft. It never sends itself. The prospect might wait an afternoon longer for an answer, and we are fine with that.
It is the same fail-closed logic as the send-time check in our AI SDR exclusion list guide. When the system cannot get a clear yes, the answer is no.
The approver who stopped reading
Nobody decides to rubber-stamp. It just happens after a long run of cards that were all fine.
You can see it in the log, if you kept one with timestamps. Two numbers are worth a weekly look per approver. The first is time from card posted to approval: when a draft with a research claim, a source link and a four-paragraph body gets approved two seconds after it appears, nobody opened the link. The second is edit rate, the share of drafts someone changed before approving. A falling edit rate means nothing on its own. It can mean the agent got better at writing, or that the approver got tired of editing, and the log cannot tell you which one you are looking at.
Batches give it away too. Forty approvals inside one minute at 7:58 on a Monday is somebody clearing a queue before standup.
Plant a bad draft
None of the ranking guides suggest this, and it is the only test we trust.
Once a week, the system slips a draft into the queue with a defect a careful reader would catch. The prospect's first name is wrong. Or the email congratulates them on a funding round the source link never mentions. Or it quotes a price, which for us is the worst version, because pricing is agreed with each client after the free pilot and the agent has no business stating a number to anyone. The planted card looks exactly like every other card.
The planted draft is flagged inside the system so the send tool refuses it no matter what the approver clicks. Put that refusal in the tool layer, outside the prompt, because a test that can accidentally email a real person with the wrong name is a bigger problem than the one it measures.
If the approver rejects it, good. If they approve it, nothing goes out, and you have learned something about every other approval they made that week. Tell them kindly. They are rarely the problem. Usually the queue is too long, or it landed on someone with a real job besides approving drafts.
Fewer cards, read properly
The fix for fatigue is almost always volume. Every guide says to gate selectively, and they are right, but the useful version of that advice is a budget: decide how many cards one person can genuinely read in a day, then write the gating rules backwards from that number.
One more rule. Approvals go to a single Slack channel, but each card names a single person, because a card addressed to a channel full of reps is a card everyone assumes someone else read.
Second-model review
Having another model check each draft before a person sees it is worth doing, and it will make your approvers trust the queue even more, which is the exact problem this page is about.
When to loosen the gate
Let the planted drafts make this call, since the edit rate alone cannot. When an approver has caught every planted draft for a couple of months and the real drafts in one narrow category (replies that only need a calendar link, say) go out untouched, that category can move from ask to send-and-report. Cold first touches stay gated longer than feels necessary. The permission matrix says the same thing, for the same reason.
Why we care
After the free pilot we get paid per qualified meeting, and a qualified meeting is one where the prospect shows up. A draft approved by someone who did not read it can still book a call. But a prospect who said yes because of an invented detail about their own company is not someone we expect to show up happy, and an empty calendar slot pays nobody, us included.
Mira runs on OpenClaw from a Mac mini in San Francisco, so rules like these live in config files somebody maintains. The OpenClaw MCP Integration Kit ships twelve annotated MCP skill configs with a tool permission matrix attached, which is a sensible place to write your approval rules down too. The rest of the setup lives in our outbound automation playbook. If you would rather someone else ran the agent and watched the queue, here is how Mira works.