AI Agents for Public Transport: Alerts and Complaint Triage

AI agents for public transport can draft rider service alerts from approved operational data, sort complaints by topic and urgency, and pass anything involving safety, refunds or legal claims to a named staff member. A useful first version is deliberately narrow: it reads from timetables, disruption feeds and a complaint queue, writes replies within approved wording, and logs every handoff. A more capable agent could later remember recurring faults across weeks and channels, but only if the operator can see, correct and limit that memory.

Key takeaways

• Start with service alerts and complaint triage, not with autonomous decisions about service changes.
• Every alert should trace back to an approved operational source, with a named owner who can correct it.
• Complaints need fixed categories and escalation rules, with safety, accessibility, refunds and legal threats always routed to people.
• Judge the agent by accurate alerts and correct handoffs, not by how many messages it sends.
• A stronger agent adds value through pattern memory and better drafts, and only under regular permission review.

Where rider communication usually breaks down

Most transport operators do not lack information. They lack one consistent version of it. A disruption is known to the control room within minutes, but the rider app may update later, the platform sign may show an old message, and the social media account may describe the problem differently again. Riders notice the gap, and the call centre or front-line staff absorb the questions that follow.

The same pattern appears in complaints. A rider writes about a missed connection, a crowded vehicle, a damaged ticket machine or a driver's manner. The message lands in a shared inbox, waits for a person to read it, and is answered from memory or from a template that may not fit. Nothing is wrong with the people involved. The process has no reliable way to classify, prioritize and record what arrives.

An AI agent is useful in this gap for two reasons. It can produce the same factual wording across channels from one approved source, and it can read incoming complaints at the moment they arrive, assign them to a category and attach the relevant trip or stop context. It does not decide what the operator should do about the underlying problem. That decision stays with the people responsible for service.

What an agent should send, and what it should never send

The first question is not which tool to connect. It is which messages the operator is willing to let a machine draft and which ones it is not. A simple decision guide helps the operations team agree on this before any build starts.

• Routine service notices from an approved disruption feed, such as a scheduled engineering closure with a known end time: the agent may draft and publish after an automated check against the source.
• Live disruption updates: the agent may draft, but a controller approves each publication, because the facts change quickly and a wrong update is hard to retract.
• Estimated restoration times: the agent may show the time supplied by operations, never an estimate it calculated itself.
• Safety incidents, injuries or anything involving emergency services: the agent does not write public messages. It notifies the on-duty supervisor and opens a record.
• Refunds, fare disputes and compensation: the agent may collect details and classify the request, but a staff member decides the outcome.
• Replies to legal threats or media contact: the agent routes these immediately and sends nothing.

Written this way, the boundary is easy to audit. If a rider or a manager asks why a message went out, the record shows the source, the approver and the wording that was used.

A triage model for rider complaints

Complaint triage works best with a small set of categories that the operator already uses in its own reporting. Inventing new categories for the agent creates a second taxonomy that nobody maintains. A workable starting set includes punctuality, crowding, cleanliness, staff conduct, accessibility, ticketing and payment, lost property, safety and other.

For each category, the agent should follow the same steps:

• Read the message and identify the trip, route, stop or ticket reference if the rider provided one.
• Check whether the message contains a safety, accessibility or legal signal, and if so, escalate at once to the duty supervisor.
• Assign one category and a priority level using the operator's written rules, and record the confidence of that assignment.
• Attach the matching service context from the operational record, such as whether a disruption was active on that route at that time.
• Draft a reply from approved templates, marking any sentence that makes a factual claim so a reviewer can check it.
• Place the case in the correct queue with a summary that a human can read in under a minute.

Illustrative scenario: a rider writes that a train was late and that a staff member was rude at the platform gate. The agent separates the two issues into two cases. The lateness case is linked to the disruption log for that line and time window, and it receives the standard explanation already approved for that event. The staff conduct case is routed to the station supervisor with the rider's wording unchanged, and the agent sends the rider only an acknowledgement that the report has been passed on. The agent does not judge who was right.

The summary matters more than it looks. Supervisors who read a clear one-paragraph case with the context attached can act within minutes, while those who receive a raw message often have to rebuild the story from scratch.

Designing approval boundaries and permissions

The approval design is where most of the real work sits. An agent that can read the complaint queue should not automatically be able to publish service alerts, change a refund status or edit a timetable. Each capability needs its own permission, granted to the agent's identity and no more. The OWASP authorization guidance describes the general principle: access should be checked at every action and limited to what the role requires. For an agent, that means separate credentials for reading disruption feeds, writing drafts, publishing approved notices and updating case records.

Rider messages also need to be treated as untrusted input. A complaint may contain text that tries to instruct the agent, for example by asking it to ignore its rules or to promise a refund. The agent should treat such text as content to classify, never as a command. Human approval is the last barrier, and it should be designed to catch anything that changes a rider-facing commitment.

The NIST AI Risk Management Framework is useful for structuring these decisions because it asks organizations to define the context, identify risks, measure them and manage them with clear responsibilities. Anthropic's guidance on building effective agents makes a similar point from the engineering side: simple, well-bounded patterns with explicit checkpoints tend to be easier to operate than broad autonomy. For a transport operator, the practical translation is a short written policy that names who approves what, and a log that shows the policy was followed.

Be Human's managed approach handles this by defining the first agent around one role, such as alert drafting for a single line or triage for one complaint channel. The engagement records the memory and tools that role needs, the approval gates, and the success criterion, such as the share of complaints routed correctly on review. Managed operations then cover monitoring, permission review after each integration change, incident response when a feed fails, and controlled updates to templates and categories.

What a stronger agent could add

A more capable agent, the kind people often describe with the word superintelligent, would be most valuable in areas where people struggle to keep track. One example is pattern memory. A single complaint about a noisy vehicle means little. Thirty similar complaints about the same service pattern over a season point to a maintenance or scheduling question. An agent with governed memory of past cases can surface that pattern to the planning team, with links to the underlying records.

Another gain is context across channels. A rider might report a problem by app, then follow up by phone, then post about it publicly. A stronger agent can connect those threads, so staff see one case rather than three partial ones. A third gain is better drafting, with replies that match the operator's tone and follow its approved facts without repetition.

These additions carry costs. Memory raises questions about retention and access, and complaints often contain personal data. In Brazil, the national data protection authority (ANPD) oversees the rules under the LGPD, so operators working in Portuguese or serving Brazilian riders should involve their legal and privacy teams before storing rider details in any agent memory. Each new capability also needs its own evaluation, because a better model can still be confidently wrong about a timetable.

How to measure whether the agent is working

Measurement should start before launch. Build a set of past complaints and past alerts, with the correct category, priority and escalation already decided by experienced staff. Run the agent against that set and record where it disagrees. Anthropic's writing on evaluations for agents recommends this kind of task-based check, repeated after every change to prompts, tools or data sources.

After launch, a practical checklist keeps the operation honest:

• Review a random sample of agent-classified complaints every week, and log every case where the category or escalation was wrong.
• Confirm that every published alert matches its approved source at the time of publication.
• Track how many escalations were reversed by supervisors, and read the reasons.
• Test what happens when a disruption feed is late or unavailable, and confirm the agent stops publishing rather than guessing.
• Review permissions after any change to the ticketing system, the feed provider or the staff roster.
• Keep an incident log with the time, the cause and the fix for every wrong message sent to riders.

The operator should also agree in advance on what counts as success. For many teams, the right first criterion is not fewer messages but fewer wrong answers reaching riders and faster routing of the cases that matter. Operations teams that already run recurring reviews can adapt the same routines, as described in how AI agents support operations teams with recurring work and reports.

If your team handles riders, complaints or service notices and you are unsure where an agent would help first, take the free Be Human AI diagnostic to find the first task worth handing to an agent.

Frequently asked questions

Can an AI agent publish service alerts to riders without human review? It can, but the safer design requires review for live disruption updates and for any message that states a restoration time or a cause. Routine notices tied to an approved, scheduled source can be published automatically once the agent has passed a source check. The operator should decide these categories in writing before connecting any publishing tool.

How does an agent handle a complaint that mentions a safety issue? The agent should detect safety, accessibility and legal signals before it attempts any classification, then notify the duty supervisor immediately and open a record. It should not send an automated substantive reply on those cases. The rider receives only an acknowledgement that the report has been passed to the responsible team.

Do we need a more advanced model to start? Usually not. A first agent for alerts and triage depends more on clean categories, reliable data sources and clear approval rules than on the most capable model. Stronger capabilities such as pattern memory can be added later, once the basic handoffs and evaluations are stable.

What data should we keep out of the agent? Keep out anything the agent does not need for its specific role, including full payment details, health information and identity documents attached to complaints. Store only the minimum needed to classify and route a case, and confirm retention and access rules with your privacy team, especially where Brazilian data protection rules apply.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.