Running routes from an agent: 27 minutes of work

On 12 September, Simon Willison published the outcome of a mundane request: 5K and 10K running routes that loop out from his house and back, computed from OpenStreetMap data. The prompt fits in two lines. The system worked for 27 minutes and returned what he had asked for in three shapes: an embedded visualisation, a downloadable GPX file and GeoJSON files. The short loop is labelled "El Granada harbor loop 5.1 km", with street names along the line (Avenue Granada, Paloma Avenue, Coastal Trail) and the usual credit to OpenStreetMap contributors in the map footer.

The route is not the interesting part. The time budget is. In his 12 September post, Willison says the job was run by ChatGPT Work with GPT-6 Astra (Max), the same product he had examined in late August. We quote those names exactly as the source gives them.

Twenty seven minutes change the product

We measure assistants in seconds of response time because almost everything we ask for is text. A job that takes nearly half an hour belongs to a different category: there is no conversation, there is work handed off and collected later. That forces a redesign of the interface (status, notifications, cancellation) and changes the cost calculation, because nobody watches a screen for 27 minutes. It also changes the accuracy expectation: an answer that arrives in two seconds gets corrected on the fly; one that arrives in 27 minutes had better be right first time.

What makes the result verifiable

Three choices in the request explain why it can be checked:

1. Data with provenance: OpenStreetMap has a licence and traceability, so the map can be compared against the source.
2. Standard formats: a GPX opens on a Garmin watch and a GeoJSON in QGIS or any viewer. The result is not locked inside the chat.
3. One hard metric: 5.1 km is falsifiable. You measure it and the argument is over.

This is the pattern we recommend to anyone building agents: demand outputs in formats another tool can read and, where possible, a number that can be audited. Without that, a half hour job only produces the feeling of work well done.

Where to slow down

Two warnings. First, privacy: the request starts with a home address, handed to an assistant wired into a work account. For an individual runner that may be acceptable; in a team handling client data, the same gesture is a leak. Second, physical safety: a line that looks clean on a map can mean crossing a lane with no pavement or running against traffic. Willison knows the ground and filters that at a glance; someone who just landed in an unfamiliar city does not. Route generation is one of those cases where the error is not paid in tokens.

How to build the equivalent with Claude

The pattern is reproducible with nothing exotic: an MCP server exposing Overpass API queries over OpenStreetMap data, a skill that pins the output contract (GPX plus GeoJSON plus total distance) and a subagent dedicated only to the loop computation, so the rest of the session context is not dragged along. PostToolUse hooks log every call, which helps when the process runs for minutes and you need to know where the time went. Claude Opus 4.8 supports an optional 1M token context window, enough to hold a wide slice of geographic data without splitting it by hand. What no link in that chain solves is the final check on the ground.

We care less about the model headline than about the format shift: long, asynchronous jobs with a downloadable deliverable. The edge there does not come from the vendor, it comes from having defined properly which file has to come out the other end.