How a crew is built and put on shift.
Every BPO owner has been shown an “AI” that turned out to be a chatbot with a script. This is the answer: eight stations between an operator’s rulebook and a crew allowed to touch live traffic, and the evidence required to pass each one.
Rules in code. Local knowledge in an index. Judgement in a person.
The crew does not run on a model's general sense of how taxis work. It runs on three separate layers, and the split is the entire architecture.
Rules — adjustment ceilings, what may never be touched, escalation triggers, response windows — live in code, in the action handler. A model cannot be talked past them because it is not the thing enforcing them. A rider insisting, at length and persuasively, that a $60 refund is owed does not move a $25 ceiling.
Local knowledge — the operator's fare structure, city geography, airport access rules, driver policy, historical tickets, precedent decisions — lives in a retrieval index scoped to your desk alone. The crew answers from that operator's own indexed material, not from anything the model happens to recall about ride-hailing in general.
Judgement — anything ambiguous, novel, or touching safety, money above a ceiling, or a person's account — goes to your supervisor. By design, not as a fallback.
From rulebook to live traffic in eighteen days.
Rulebook capture
The operator's rules are written into a machine-readable spec: fare structure and surge policy, cancellation and no-show rules, adjustment ceilings, driver document requirements, incident classification, escalation matrix, tone and channel policy. Every rule traced to a client document or a signed-off decision. Anything the operator cannot answer is logged as an open item rather than guessed — and on mobility runs there are always some, usually around who may authorise what.
Local knowledge build
City geography, zone and airport access rules, fare tables, driver register, vehicle categories, historical ticket transcripts, the macro library and precedent decisions are indexed to your desk. This is what lets an agent know on day one that a particular airport terminal has a designated pickup bay two hundred metres from where riders usually wait — because it has read every ticket that ever mentioned it.
Role definition
Each agent is written a job role, not a prompt: what it owns, what it may decide alone, what it must escalate, who it reports to, and what it is measured on. Those roles are published on the crew page in the same form your supervisor reads them. An agent with a vague role is an agent that improvises, and improvisation is what you are trying to eliminate.
Tool binding and guardrails
Each agent is bound to a specific set of board actions and operator API calls, and to nothing else. An agent physically cannot call a tool it was never bound to — Safety AI has no reply tool at all, which is why it cannot answer an incident even if it wanted to. Ceilings, refusals and escalation triggers are added here, in code, in the action handler.
Bench testing
Every agent runs against replayed historical tickets with known correct outcomes, drawn from the operator it will actually serve. Accuracy is measured per ticket type — booking, driver, fare, lost property, onboarding — not as one headline number, because a crew that is 96% right overall can still be 60% right on fare disputes. No agent leaves the bench until it clears its own threshold, and every failure is traced to a missing knowledge item or a badly stated rule and fixed at source rather than patched.
Shadow shift
The crew runs on live traffic and sends nothing. Every output queues for review. Your supervisor compares what each agent produced against what they would have said, and every disagreement goes back into the rules or the index. This is where your team learns the crew's behaviour and the crew learns the operator's voice — at zero risk to a rider or a driver. Safety AI is tested here too, on real flags, with your supervisor confirming every handover.
Staged release
Autonomy is released one ticket type at a time, lowest risk first: ETA queries, booking confirmations, document chasing. Draft-only never comes off anything a rider or driver receives directly, and Safety AI never receives any autonomy at all. Each release is a decision with a name against it, recorded on the board. Volume is throttled for the first week, then opened.
Continuous retraining
QC re-checks 200 random decisions every week, weighted towards fare and safety classification. Every human overrule is logged with a reason and reviewed for pattern. When the operator changes a fare rule, a policy or a city boundary, it is a versioned update to the spec, pushed to the crew and re-benched before it takes effect. Every decision and its inputs are retained 24 months.
Three classes, and the lines never move.
Supervised
Dispatch AI, Watch AI, Onboarding AI, Fleet AI, Quality AI. These act inside encoded limits and record every decision with its inputs. Nothing they do is irreversible, and everything is visible on the board as it happens.
Draft only
Rider Support AI, Driver Support AI, Fare AI, Payments AI. These produce a proposed reply or adjustment and stop. Nothing reaches a rider or driver until a named person releases it. This class does not graduate, however good the accuracy gets.
Escalate only
Safety AI, alone. It classifies, collates context and hands to a human. It has no reply tool, no closure tool and no autonomy of any kind. It cannot be promoted, and no configuration exists that would allow it.
What no configuration can change
- Never resolve, close or reply to a safety, SOS or incident report
- Never contact emergency services, and never advise a rider or driver not to
- Never deactivate or reinstate a driver account
- Never approve an adjustment or goodwill credit above $25 without a named human approval
- Never share a rider's contact details with a driver, or a driver's with a rider
- Never accept, deny or comment on an insurance or injury claim
- Never send a message referencing legal action or law enforcement
- Never delete or overwrite a decision log — the log is append-only
What the crew does badly.
Any vendor who will not answer this is selling you something.
- Accented or noisy phone audio. Transcription errors produce confidently wrong addresses, and there will be some every week.
- Novel situations with no precedent in the operator's history. It flags rather than invents — but it flags a lot in the first month.
- Judgement calls where the operator's own policy is silent or self-contradictory.
- An upset rider or driver who needs a person and a phone call. Escalation is a design feature, not a failure.
- Safety classification is deliberately over-sensitive. You will get false positives, and you will get woken for some of them. The alternative is a false negative, and there is no acceptable rate of those.
Read the job roles next.
Each of the ten agents is published as a role — what it owns, what it decides alone, what it must escalate and what it is measured on.