An agent that fires a client notice without authorization is more expensive than ten agents that do nothing. So is an invoice sent to the wrong party. Or an unauthorized trade. Or a 3am apology tweet posted on behalf of a brand.
Those are the canonical "agent gone rogue" headlines, and they're a big part of why approval-gating exists in GroundPound. The rest of this post is the working-out.
The asymmetric cost of being wrong
Every action an agent takes is on a spectrum from reversible to irreversible. A dashboard post is reversible — delete it, move on. An email is irreversible — the recipient read it before you knew it was wrong. A DocuSign envelope sent to the wrong party is catastrophicallyirreversible — you now have a partially-signed contract floating in someone's inbox that you can't recall.
SMB operators feel this asymmetry intensely because they are personally on the hook. The property manager whose agent quoted the wrong rent owes the difference, personally. The dental practice whose agent sent a billing message that violated HIPAA is the practice that gets fined. The publishing house whose agent agreed to terms a senior editor would never have signed is the publisher that gets sued. The "agent did it" defense does not exist.
The right design response to this asymmetry is approval-gating: every irreversible action is paused before execution and surfaced to the operator for review. The operator approves or rejects. The agent acts only after approval.
What we approve
By default, every GroundPound agent must file a request_approval before:
- Sending an email to anyone outside the organization
- Sending an SMS
- Sending or completing a DocuSign or e-signature envelope
- Replying to a customer via any portal or inbox the platform owns
- Publishing content to a customer-facing surface (KB, blog, document library, knowledge folder)
- Moving money (Stripe charges, refunds, payouts)
- Trading orders (any execute, modify, or cancel on a market)
- Vertical-specific high-stakes actions — eviction or cure notices for property managers, security-deposit dispositions, manuscript-rejection letters for publishers, billing dispositions for dental practices, prescription-refill confirmations for vet clinics
- Hand-offs between teams (so a parent operator can see the cross-team workflow)
What we approve is not "anything risky" — it's "anything irreversible that affects external state." The list is conservative. We add to it; we don't shrink it.
What we don't approve
Some things are safe to let agents do directly because they're either reversible, internal, or trivially low-stakes:
- Reading the inbox
- Drafting a response (drafting ≠ sending)
- Adding to the internal knowledge base
- Posting to the operator dashboard
- Calling a search tool, a database lookup, an integration read
- Scheduling a meeting (the calendar accepts it; the human can decline before it matters)
- Inter-agent handoff within a team
The principle: if the worst case is "the operator notices and undoes it in 30 seconds," the agent can act. If the worst case is "the operator has to call the customer, apologize, and untangle," the operator approves first.
"Won't this slow everything down?"
This is the most common objection. Three responses.
One: most work in an SMB ops day is reading + thinking, not sending. Triage doesn't need approval. Routing doesn't need approval. Drafting doesn't need approval. The places we gate are exactly the moments when the operator wanted to be in the loop anyway. A property manager wantsto see the eviction notice before it's served. A therapist's office wants to see the recall list before it goes out. A publishing house wants to see the rights letter before it's countersigned. Removing that friction is removing the value, not adding it.
Two: the approval surface is engineered to be fast.An operator gets a one-tap approval card on mobile. Default-deny isn't "open an admin page and fill out a form" — it's "swipe to approve" with the full proposed action rendered, the prior approval history, and the agent's reasoning. We measured the median approval-to-action latency at 23 seconds across our prod data last week.
Three: when a category is genuinely safe to bulk-approve, we ship bulk-approval. Operators with a stable workflow can promote categories from "every-time approval" to "policy-with-veto" — the agent acts, the operator gets a daily digest, and any operator can roll back. The discipline is "every category starts default-deny; opt-in to less friction as trust accrues."
The hard part: getting the agent to actually file the approval
The hard part isn't the approval surface. The hard part is teaching the agent to file the approval instead of just doing the thing.
LLMs trained on the internet have absorbed a strong "be helpful, take action" prior. Left unconstrained, they will quietly send the email and report success. The agent thinks it's being responsive. The operator finds out about the email when the customer replies.
We address this with three layers:
- Tool design.The customer-facing send tool doesn't exist for the agent. The only tool is
request_approval(category='send_email', ...). The agent literally cannot send the email — only file the approval. The platform performs the send after the operator approves. This is the strongest layer: if the tool doesn't exist, the agent can't call it. - System prompt discipline.Every agent's shared policy block carries explicit instruction: "Before any irreversible action, file a
request_approval. Do not narrate the action as completed in your reply." We test that this clause stays effective via regression tests that try to trick agents into pretending they sent something. - Post-action grounding.When an agent says it did something, we check the database before believing it. If the agent's reply says "I sent the email" but no send action was queued in the past minute, we surface that mismatch to the operator immediately. This caught a class of "phantom send" hallucinations in May 2026 that nothing else would have caught.
When approval-gating is wrong
We've seen one class of customer for whom approval-gating is the wrong default: high-volume autonomous workflows where the operator explicitly wants the agent to keep going without human review. Examples: a high-frequency-trading desk (already off our roadmap), an outbound prospecting team that wants to send 500 emails a day, a customer-support team handling 10,000 routine tickets a month.
For these, approval-gating is friction the operator doesn't want. We expose policy: an operator can promote specific categories to "no approval required" with their own opt-in. We never ship that as the default. We require the operator to confirm in writing that they understand the change and the asymmetric cost.
What we believe, restated
Default-deny is the only safe default for SMB-operator agents because the cost of being wrong is paid by the operator personally and asymmetrically. Smart product design makes the approval surface fast enough that the friction is invisible 95% of the time. The remaining 5% is where the operator actually wanted to be in the loop.
We will keep shipping new approval categories before we ship a way to skip them.
If you want to see it in action, start free. Your first inbound message will produce a draft, not an action — that's the design choice this post is about.