Delivery and mobility / Ride-hailing and delivery
Grab: Automating simulator experiments and code improvements for dispatch strategy research
- Company
- Grab
- Country
- Singapore
- Adoption stage
- Limited operation
- Source published
- Date basis
- The date the source was published. It can differ from the date adoption started.
- How the source was checked
- Read the full source text
The work problem
According to Grab's official engineering blog, Grab's delivery and ride-hailing marketplace makes a continuous stream of dispatch decisions, such as whether to send a driver now, whether to combine orders and how far to look for a driver, and because these decisions interact, the right settings differ by time of day. However, implementing one strategy takes weeks of engineering and judging it through a production experiment takes weeks more, so Grab could test only about 12 strategies a year. Some questions also could not be answered in production at all, such as replaying last Saturday with 20% fewer drivers.
Technology and data
Grab built sim-rs, a simulator that runs on its own without production services or databases. Given historical booking and driver data as files and a configuration describing the strategy to test, it repeats demand arrival, driver movement, cancellations, order batching and driver assignment, and outcome recording at fixed time steps, processes a city-day of marketplace activity in tens of minutes and produces a single metrics report. Stages such as batching, allocation, cancellation and routing can be swapped through configuration, and each experiment keeps its configuration, input data, source revision and results together so that anyone can run it again. Grab connected an automated research loop called autoresearch, in which AI agents propose a change, implement it in source code, test it and keep or roll back the change depending on the verdict. Because an agent once found a shortcut that raised the metric while leaving actual dispatch decisions unchanged, Grab built safeguards into the environment: immutable core data, computed verdicts that agents cannot change, changes limited in scope on separate branches, and checks at two levels. Surviving changes are human-readable code, so engineers can review and deploy them like any other code change.
Results
According to Grab's official engineering blog, when the loop was asked to explore trip-recycling policy, it produced a concrete rule written as code: hold batched orders only as long as service-level deadlines permit, to raise the chance that another nearby order joins the trip. Grab also used the same machinery to improve the simulator itself, running it unattended over several nights. Across about 150 logged experiments, 3 out of 4 attempts failed to build or were rejected by later checks, but the driver eligibility checks became about 10 times faster and the step that adjusts assignment costs became about 24 times faster. Grab explained that because these steps run repeatedly in every replay, the speed improvements compound across later research.
Limits and open questions
The blog does not say whether the trip-recycling rule it found was applied in production or what effect it had, and gives no figures on how closely the simulator matches production results. The AI models used are not named in the source.
Sources
- Powering AI-led research through simulationengineering.grab.com, Accessed
Compiled from public sources. These are not results from ATF Works customers.