When an operator connects the agent to Cabgo's MCP, the first question that comes up is almost always framed wrong. It isn't "how autonomous should I let the agent be?", as if autonomy were a single dial you turn up or down. The right question is "what kind of action is it about to take?". An agent that cancels a phantom trip, one that changes the base fare for the entire operation, and one that confirms a call time with a customer are not the same risk at different intensities: they are different categories, and collapsing them into a single "I trust it / I don't" decision is exactly what produces both the useless agent that asks about everything and the dangerous agent that asks about nothing.
This article is for the operator who already has the agent running and wants to set the boundary with judgment, not out of fear. The thesis is simple: the line between acting and asking for confirmation is not drawn by importance, it's drawn by reversibility and blast radius. An important but reversible, small-radius action should run on its own; a seemingly trivial action that is irreversible or touches a real customer should go through you. What follows are the four categories we use to classify every agent tool, and how they translate to the daily operation of a mobility platform.
The right axis is reversibility, not importance
The natural instinct is to protect what's important and release what's trivial. It's the wrong heuristic. Changing a service's internal description matters for your catalog, but if the agent gets it wrong you undo it in thirty seconds: it's reversible. Meanwhile, sending a driver a WhatsApp confirming a training time is trivial in effort and yet, once sent, there is no undo button — the driver already read it, already arranged their day. Irreversibility does not scale with importance; quite often it runs the other way.
To the reversibility axis you add a second one: blast radius. How many people are affected if the action goes wrong? A tool that reads a passenger's trip history has a radius of one and is read-only. One that rewrites the fare table has a radius of the entire operation: every trip quoted from that moment on comes out with the new number. Cross the two axes and you get a map where each agent tool lands in a quadrant, and the quadrant — not your general level of trust — decides whether the agent acts or asks.
The four categories of agent action
Every tool the agent can invoke falls into one of four categories. Classifying them once, when you set up the operation, saves months of case-by-case decisions and removes the anxiety of reviewing every individual action.
- **Pure read (Tier-0)**: query trips, read a driver's balance, generate a report, review the agent's own history. Zero damage radius, fully reversible because nothing changes. The agent must run these without ever asking — requiring confirmation here only trains the operator to approve blindly.
- **Reversible internal write (Tier-1)**: edit a service description, adjust a draft coverage zone, cancel a phantom trip that clearly never existed. It changes state, but the state is yours and you can undo it. The agent acts and tells you what it did, it does not ask permission first.
- **High-radius write (Tier-2)**: change the base fare, turn on surge for a whole city, modify commission rules, archive a company. Reversible in theory, but every minute it's wrong touches everyone. Here the agent proposes the exact change and waits for your yes before applying it.
- **Outward or irreversible action (Tier-3)**: send a message to a customer or driver, confirm a time, charge a card, publish to the store, move money. There is no undo. These never run on their own, no matter how much you trust the agent — trust does not un-send a message that was already read.
What the agent should execute without asking
The most expensive mistake is not the agent that acts too much, it's the one that asks too much. An agent that requests confirmation to read a report, or to cancel a trip the GPS shows 400 km away from the passenger, isn't being careful: it's being useless, because it hands back exactly the manual work you came to eliminate. Worse, it conditions you to approve without reading, and the day a confirmation that actually mattered shows up, you approve it with the same automatic reflex.
- Anything read-only, no exceptions: reports, balances, history, diagnostics, catalog searches.
- Cancellations with objective evidence: trips where the driver never moved, duplicate orders in the same minute, hung sessions the system itself flags as orphaned.
- Internal draft adjustments that affect no in-progress trip and no customer: draft-state zones, descriptions, labels, internal notes.
- Actions the agent can undo itself within the same conversation if you realize it got something wrong.
What always requires your confirmation
On the other side of the map are the actions where the agent must never assume. The rule isn't "when in doubt", because a good agent rarely has doubts and would proceed anyway. The rule is structural: if the action leaves the system toward a real person, or if its radius covers the entire operation, it goes through you before running — regardless of how confident the agent is.
- Any outbound message to a customer, driver or prospect: WhatsApp, email, agent-drafted push notification.
- Clock-time commitments — confirming a call, a demo, a training slot. The agent cannot be present at 2 PM; it must not promise that on your behalf.
- Money movement: charges, refunds, commission changes, generating payment links tied to a plan.
- Total-radius changes: base fare, full-city surge, archiving or reactivating a company, publishing a build to the store.
I spent the first two weeks approving every agent action out of fear. All I achieved was doing the manual work again, now with an extra step. The shift came when I classified the tools just once: I let it run read-only actions and obvious cancellations end to end, and reserved my attention for the four or five cases a day that truly deserved it. That's when the agent started saving me hours instead of minutes.
What this looks like in a real shift
In practice, a well-configured shift feels like this: the agent closes phantom trips on its own, clears duplicate orders, hands you the morning report, and flags drivers with negative balances — all without a single confirmation, because all of that is read or reversible internal write. When it reaches something high-radius, it switches modes: instead of acting, it shows you a card with the exact change. "I'm going to raise the downtown base fare from 25 to 28; it affects all new trips from the moment you confirm. Proceed?" You read, decide, respond. That confirmation card isn't accidental friction: it's the quadrant boundary made visible.
The difference from a badly configured agent is brutal in volume. If you put everything behind confirmation, a normal shift generates forty or fifty cards, most of them obvious cancellations, and you approve them on autopilot until a real mistake slips through. If you classify by quadrant, the same shift generates four or five confirmations, all of them high-radius or outward, and because they are few you actually read them. Fewer confirmations, better read, is safer than many confirmations ignored.
The gray case: when the evidence is partial
The quadrant map resolves 90% of decisions, but the remaining 10% is where trust in the agent is won or lost. These are the cases where the category depends on evidence the agent can't fully verify. A trip flagged for cancellation where the driver did move, but only 200 meters and then stopped for half an hour: is it an obvious cancellation or a real trip that ran into trouble? By reversibility it would look like Tier-1, but the ambiguity pushes it up. The rule here is explicit: when evidence is partial, the agent moves up a category, not down. Doubt is not resolved by acting and hoping to be right; it's resolved by escalating to a confirmation you decide in five seconds.
This has a design consequence worth naming: you prefer an agent that over-escalates in the gray zone to one that over-acts in it. An unnecessary escalation costs you five seconds of reading; a wrong action in an ambiguous case costs you a customer call, an annoyed driver, or a misapplied fare for hours. The asymmetry is clear, and that's why the gray zone is the one place where erring on the side of caution does pay off — not because caution is virtuous in the abstract, but because there the cost of the error outweighs the cost of asking.
The invisible cost of over-confirming
Over-confirming carries a cost that shows up in no report: it erodes attention. Every trivial confirmation you approve lowers, a little, the threshold at which you read the next one, until confirmation stops being a decision and becomes a reflex. The operator who approves fifty cards a day isn't supervising the agent; they're signing off on what the agent already decided, with the illusion of control. Real supervision is scarce by design: few decisions, each read with full attention.
If you're going to adjust one thing this week, don't turn the agent's general "trust" up or down. Open the list of tools it has available and assign each one its category: read-only and reversible-internal go straight to execution, high-radius and outward go to confirmation. Do it once, calmly, thinking in terms of reversibility and radius, not importance. From there the agent will know exactly when to act and when to raise its hand — and you'll recover your attention for the few moments it's genuinely needed.
