The Approval Layer Nobody Wanted to Build Until Agents Started Touching Production
Cross-border sellers are quietly becoming AI-agent operators. Not in the abstract “we use ChatGPT for copy” sense, but in the concrete sense that a growing share of refunds, listing edits, ad-budget shifts, supplier emails, and inventory adjustments are now executed by autonomous or semi-autonomous agents wired into Shopify, Amazon Seller Central, and Stripe. That shift creates a problem no marketplace dashboard was designed to solve: who signs off when the agent decides to issue a $25 refund, kill a PPC campaign, or reprice a SKU at 3 a.m. in a timezone where nobody on your team is awake? withHuman, launched this week by Chris Battarbee and Ece, is an attempt to answer that question with an approval layer that sits between your agents and their tools. For anyone running multi-channel commerce with automation, this is worth understanding — even if you never install it.
What Problem withHuman Actually Solves
The founder’s origin story is the tell. Before withHuman, Battarbee and Ece built an AI agent that investigated production issues and often found the right fix. The bottleneck wasn’t intelligence — it was trust. As he puts it, “nobody wants to hand an agent admin access to production and hope for the best.” They added an approval step, but every team had different rules about who could approve what, wanted finer control over agent capabilities, and was already juggling multiple agents with separate approval setups.
Strip away the developer-infrastructure framing and the cross-border parallel is obvious. Your refund agent, your listing-optimization agent, and your ad-bidding agent are three different systems with three different risk profiles. A blanket “human approves everything” rule collapses under volume — approval fatigue is, in the founder’s own words, “probably the biggest problem we’re tackling.” A blanket “let it run” rule is how you wake up to a mispriced catalog and a four-figure ad spend on a dead SKU.
withHuman’s answer is architectural: it intercepts each tool call before it executes, applies your rules to auto-approve or deny the routine ones, and routes the risky ones to the right human. The agent doesn’t need to change, and — critically — “they can’t skip it.” That last clause is the whole product. An approval step the agent can bypass is theater.
The Stripe refund example is the whole thesis in one line
The founder’s own illustration: if (tool = 'stripe.refund' and amount < $5) { approve }. Everything above $5 goes to a person. That’s a rule a cross-border operator can write in thirty seconds and it captures the actual shape of the risk — high-frequency, low-stakes actions automated; low-frequency, high-stakes actions gated. If you’ve ever had a VA accidentally process a duplicate refund on a $400 order, you already understand why this pattern matters more than any dashboard.
How It Differs From What You’re Probably Using Today
Most sellers I talk to handle agent risk in one of three ways, none of which is really an approval layer.
The first is platform-native permissions. Shopify staff accounts, Amazon Seller Central user permissions, Stripe restricted API keys. These are coarse-grained and static — they control what a human or integration can do, not what a specific agent action should do right now. They can’t express “refunds under $5 auto-approve, refunds over $20 page the ops lead.”
The second is workflow automation tools like Zapier or Make. These are excellent at triggering actions but terrible at gating them — they’re built to move data, not to pause and ask a human whether a specific tool call should proceed. You can hack an approval step in, but you’re building the security boundary yourself, badly.
The third is agent frameworks with built-in human-in-the-loop, which mostly means you’re writing custom approval code for each agent. That’s the exact pain the founders describe: “each team had different rules… they were already using other agents, each with its own approval setup.”
What makes withHuman structurally different is that it ships an open spec — the Agent Approval Protocol (AAP) — rather than just a product. Prebuilt hooks exist for Claude Code and Codex, with SDKs for Python and TypeScript. The founder’s stated reasoning is that “the only way a solution gets adopted here is via an open spec” — hoping others write integrations and alternative providers. That’s the right instinct. A proprietary approval layer is a single point of failure; a protocol can become infrastructure.
Why Amazon sellers should care more than Shopify ones
Shopify merchants tend to run leaner stacks with fewer automated actors touching money. Amazon FBA brand owners, by contrast, are already drowning in automation: repricing tools, PPC bid managers, inventory syncs, review-request sequences, and increasingly LLM-driven listing and customer-service agents. Each one is a potential source of unapproved high-stakes actions. The approval-layer problem is more acute on Amazon simply because there are more agents in the room — and because a bad action on Amazon (a hijacked listing, a runaway ad spend) can be harder to reverse than on your own DTC store.
What Cross-Border Sellers Can Borrow From This
Even if you never touch withHuman, the design pattern is worth stealing for your own operations.
Rule-based tiering beats blanket policies. The amount < $5 example generalizes. Write explicit thresholds for every agent-adjacent action: refunds, discounts, price changes, ad-budget shifts, supplier POs, customer credits. The rule doesn’t have to be code — a spreadsheet with tiers is fine to start. What matters is that the threshold is written down and enforced, not vibes.
Route approvals to where the person actually is. The founder emphasizes routing “to the right person, wherever suits them.” For a cross-border team spread across Shenzhen, Manila, and Berlin, that’s not a nice-to-have. An approval that lands in a tool nobody checks at 2 a.m. is not an approval — it’s a delay with extra steps.
Make the agent’s context human-readable. This is the most underrated lesson. The founder’s own example: an approval request showing userId: faeebde0-082e-45ce-b23e-567f8291e0da is useless; userId: faeebde0-082e-45ce-b23e-567f8291e0da (Bob from Accounting) is actionable. For sellers, the equivalent is ensuring your approval requests show the order number, the customer name, the SKU, and the dollar amount — not an internal transaction ID. If your reviewer can’t decide in five seconds, you’ve built approval fatigue into the system.
Treat the approval layer as a security boundary, not a convenience. The founder’s answer to a sharp question from Lev Perlman about what happens when withHuman is unreachable is instructive: “currently the tool call will fail.” They chose fail-closed because “if a user sets up a rule which is refunds > $20 go to a human, we felt like we shouldn’t let a $25 refund go through because withHuman is down.” That’s the correct default for money-touching actions, even though it means your agent stops working during an outage. Most sellers building their own gating logic default to fail-open — the agent keeps running and the rule silently doesn’t apply. That’s backwards.
Where the math breaks
Fail-closed is right for refunds and ad spend. It’s wrong for everything else. If your agent’s job is to sync inventory levels or refresh listing copy, an outage that halts all agent activity costs you more than a slightly stale sync. The founder acknowledges this tension — “withHuman has to be extremely reliable” — and mentions exploring “caching rules at an intermediary layer which would survive a brief upstream outage.” Until that ships, the practical takeaway is: classify your agent actions by blast radius before you decide fail-open or fail-closed. Money actions fail-closed. Cosmetic actions fail-open. Don’t apply one policy to both.
Where My Judgment Says It Falls Short
Three honest concerns.
First, the context problem is unsolved, and the founders say so. In response to Mia Qiao, Battarbee admits they’re “working on getting more in here” — embedded identifier links and the ability to review full agent history. In response to Oleksii Sekundant, he concedes that raw tool-call arguments are often unreadable. This is the single biggest gap. An approval layer that routes decisions to humans but doesn’t give those humans enough context to decide is just a bottleneck generator. To their credit, they’re unusually candid about it — David Turner specifically praised “the honesty about what you haven’t solved yet.”
Second, the MCP-shaped hole. The founder notes they’re still figuring out “gating calls that don’t go through MCP.” For cross-border sellers, that’s a meaningful limitation. A lot of the tooling you’d actually want to gate — direct API calls to Klaviyo, Helium 10, or a custom ERP integration — doesn’t necessarily route through MCP. If withHuman only sees MCP-mediated calls, it’s a security boundary with a gap in the fence.
Third, the adoption question is real. An open spec is the right strategy, but specs live or die on ecosystem adoption. Right now the prebuilt hooks are for Claude Code and Codex — developer tools. There’s no Shopify app, no Amazon integration, no obvious path for a seller running TikTok Shop or Temu automation to plug in without engineering resources. The founder hopes “others will write integrations and alternative providers.” That’s a hope, not a roadmap. Sellers who aren’t running technical teams should watch this space rather than adopt it today.
The honest verdict
withHuman is infrastructure for a problem that’s about to get much bigger. The approval-layer gap between “AI agents can do things” and “we trust AI agents to do things” is real, and it’s widening as agents get more capable. But this is a developer-first product at launch, and cross-border sellers are mostly not developers. The right move for most operators is to borrow the pattern now and adopt the tool when the integration surface widens.
What I’d Watch / Test Next
This week, before you touch any new tooling, do three things.
Audit your agents. List every automated actor in your stack that can touch money, inventory, or customer-facing content. For each one, write down the single worst action it could take unsupervised. That list is your risk map.
Write your thresholds. Using the refund < $5 pattern as a template, define explicit dollar and impact thresholds for each agent. You don’t need withHuman to enforce them — a shared doc and a Slack channel is a start — but writing them down forces the conversation your team has been avoiding.
Pick one action to gate manually this week. Choose the highest-blast-radius action on your list and route it to a human for seven days. Measure how many approvals you get and how long each takes. That number tells you whether an approval layer like withHuman would pay for itself — and it tells you whether your current process would survive fail-closed behavior during an outage. The Quickstart is worth reading even if you never install anything, because the founder’s framing of the problem is clearer than most of what’s circulating in the agent-tooling space right now.
