HOW_IT_WORKS

How AgentBiz handles an exception

AgentBiz is the white-label AI ops team agencies run under their own brand. This page is the mechanics: what it reads, what it may do, what it has to prove, and where you still have to say yes.

LIFECYCLE

The lifecycle of one exception

Six stages. Each one either produces something the next stage can verify, or it stops.

  1. 01 / SIGNAL

    Signal

    Something in a merchant's order flow stops matching the promise: a carrier scan goes quiet, a fulfillment stalls, a check fails. The signal comes from the merchant's own systems, not from a guess.

  2. 02 / READ

    Read

    The agent reads the order and its fulfillment state directly from the store. Every conclusion it reports has to point at a real order field. If it cannot reach the store, it says so — it does not fill the gap with a plausible answer.

  3. 03 / DECIDE

    Decide

    It works out what the case actually needs: a customer update, a note for whoever picks this up next, or an escalation to you.

  4. 04 / ACT

    Act

    It does the work in the merchant's real system. Actions are scoped: today the only write it can perform on a store is appending a note to an order.

  5. 05 / PROVE

    Prove

    Each action has to return evidence from the system it touched. This is the part most tooling skips, so the rules are spelled out below.

  6. 06 / REPORT

    Report

    What reaches the merchant goes out under your brand, after you approve it. Your logo, your color, your name.

EVIDENCE_CONTRACT

The evidence contract

Most AI tooling asks you to trust a “done”. We treat an unproven “done” as a bug.

Evidence comes from the response, not the request.

When the agent appends a note to an order, the proof it records is the order id the store sent back — not the order id the agent sent in. An action cannot vouch for itself.

No evidence, no success.

If a write reports success but carries no evidence field, the platform rewrites the result to failed and logs it as a silent failure. The agent then cannot tell anyone the work is done, because as far as the system is concerned, it isn't.

Writes are reversible by design.

Before appending to an order note, the previous note is read and recorded. If that read fails, the write does not happen — nothing is blind-overwritten — and the prior value is kept so the change can be undone.

Why the rule exists.

It came out of a real incident in our own system: an integration returned success with an empty id, and the agent confidently reported a publish that had never happened. The contract exists so that failure mode cannot repeat quietly.

GOVERNANCE

Governance boundaries

What the AI is allowed to touch is a property of the platform, not of how carefully someone wrote the prompt.

Read-only by default.
The e-commerce agent available today is read-only: it reports on orders and fulfillment. It cannot modify orders, issue refunds, or ship anything — and those limits are declared in the agent itself, not left to prompt discipline.
Writes that leave the platform are denied unless authorized.
Any action that touches the outside world is classified as an external side effect and denied by default. It runs only when that specific task carries an explicit authorization. A denial isn't an error — the agent hands the content back for a human to send.
Nothing touching money is implemented.
Refunds, cancellations, and payment actions are deliberately out of scope. Not gated — not built.
The authorization check is tenant-scoped.
It verifies the task belongs to the merchant it claims to, so one merchant's approval can never release an action against another merchant's store.
Where a human stays in the loop.
Approvals for pending directives, review for work that fails a quality check, and sign-off before any weekly report reaches a merchant.
NOT_CLAIMING

What we're not claiming yet

A page like this is easy to overstate, so here is the other half of it.

  • Automatic escalation by risk score. Authorization today is an explicit yes or no per task, not a graded threshold.
  • This governance depth on every integration. The Shopify write path is hardened on both the runtime and the API path; other write integrations currently rely on the runtime guard alone.
  • A customer track record. No agency or merchant is running this in production yet.

Want to shape what it handles next?

The first design partners decide which exceptions get built out first, and what the merchant-facing side looks like.

Become a Design Partner →