The Road Trip Agent: The Next Shelf

A planned series: build an AI agent that plans family road trips, days and the stops inside them, with everyone in the family contributing to the plan, on AWS, using coding agents to do the building. Then use it for real on the January 2027 holiday and write that up once we are home. Outlined here to mull over, the same way NEXT-UTH-IDEAS.md and NEXT-CRAFT-IDEAS.md are; nothing is written or scheduled yet.

Revised 6 November 2026 after a sceptical review (privacy, schedule, data terms, eval rigour, ordering) and Craig’s answers to it. Revised again the same day: several people plan one trip and the agent judges how fairly it serves them; the trip is planned before departure, not re-planned on the road; the Broome dates deliberately miss Staircase to the Moon.

Where it lives

Consulting and Craft, in its own group: “The Road Trip Agent”. It is practice, hands-on and first-person, which is what that stream carries (its Hands On group already has the Bedrock lease pilot). It is not an Exam Room track: no cert_code, no cert banner, no domain:, no exam checklist, and so nothing in check-exam-checklists.py or the AIP-C01 checklist changes. The group inherits the stream’s practice mode, so _data/modes.yml needs nothing unless the group wants a different mode.

The exam track is reference, not authority. Most decisions here have an AIP-C01 post about the same choice, and each post links the relevant ones with series-link.html at the point they help. The decisions themselves are made in our own context: this family, this trip, this budget, remote WA. An exam post is good background on the options; where our answer differs, the post says why, and that difference is often the most useful paragraph.

Slot. Thursday, as a block. The Thursday queue has six years of runway, so pushing it back by the length of this run costs nothing that matters. Because the examples use a made-up trip (below), the build posts carry no privacy risk and can start publishing once four or five are banked, rather than waiting for the holiday. Lay it with reschedule.py when it is ready, not before.

The made-up trip, and the real one

Every example uses a faux trip: Perth to Broome and back, as a family. Made-up dates chosen to make sense: a fortnight in the dry season during the WA July school holidays of 2027 (confirm the term dates against the Department of Education’s published 2027 calendar when post 1 is written, and pick the fortnight then). Up the North West Coastal Highway and back down the Great Northern, so the trip covers busy coast, long empty inland stretches and the Port Hedland to Broome run with one roadhouse in about 600 km.

The made-up dates deliberately miss a Staircase to the Moon night by a few days. Pick the fortnight so the Broome nights land two or three days before or after one of Broome’s published Staircase dates. The agent should notice, and propose nudging the Broome leg to catch it: what moves, which other legs stretch or shrink to absorb it, and what it costs (a longer day elsewhere, a school-holiday boundary, a booked overnight that would have to change). That is the events interface doing more than listing what is on: it proposes a change to the trip, and the family decides.

A made-up family goes with it, committed to the public repo: shared constraints (the longest leg anyone tolerates, the car’s range, budget) and, for each person, an age band and their own wants. The wants should pull in different directions on purpose, so fairness has something to measure: one wants fishing, one wants the dinosaur footprints at Gantheaume Point, one wants a pool every afternoon, one wants the shortest possible days in the car. Real family details never go in the public repo or in a post.

The real January trip is not published until we are home. No dates, no route and no overnights online beforehand. Afterwards a “real life use” post covers it with pictures and real prose: what the agent got right, where reality disagreed, and the learnings. The made-up trip lets the series show the agent planning stops as well as days, without anything personal being involved.

What the series is for

  1. Building an agent on AWS, decided in our own context. Strands, Bedrock, AgentCore, Amazon Location Service, with the exam track linked wherever it covers the same ground.
  2. Building software, and agents, with coding agents. What was asked, what came back, what review and evals caught, what was rewritten by hand.
  3. Planning as a family. Several people contribute to one plan, every change is attributed to whoever made it, and the agent can say how fairly the trip serves each person and suggest rebalances.
  4. A real-world data problem. Remote WA has thin map data, roadhouses with no hours listed, and closures that only the state publishes. Other people building for remote areas hit the same thing, so the series deals with it openly rather than around it.

Devices that run through every post

The posts

# Post Kind
1 What the agent has to do, and how we’ll know it does it planning
2 Choosing the coding agent, fairly decision, coding agent
3 Setting up the repo so any coding agent can work in it coding agent
4 Choosing the model, from any vendor decision
5 Choosing the framework, the runtime, and how a family uses it together decision
6 The map data and what its terms allow decision
7 How good is the data out there? Remote WA, measured build
8 The first agent: days, stops, one route, a baseline build
9 Tests and evals first, and why the agent’s own tests can’t be trusted coding agent
10 The tools, and how they are exposed decision, build
11 What’s on where we’re going, and nudging the trip to catch it build
12 The family’s details: what’s kept, where, and who can see it decision, build
13 Planning together: several people, one trip, every change attributed decision, build
14 An agent building an agent: prompts and tool descriptions coding agent
15 What it must never do decision, build
16 The offline itinerary decision, build
17 Is it fair? How the trip serves each person, and rebalancing it build
18 Several coding agents at once, and where that goes wrong coding agent
19 Reviewing what the agent wrote coding agent
20 Off the laptop: deployment, tracing and what a plan costs build
21 Writing about building it, and what each post cost meta
22 Real life use: the January trip field report, after we’re home
23 The post-mortem: the trip, the coding agents, and the full bill field report

Notes per post

  1. What it has to do. Plan days and the stops inside them, before departure, with several people contributing. Re-planning on the road is out of scope (see “Later” at the end). Overnights in remote WA in peak season are often booked months ahead, so the agent must plan around fixed overnights as well as choose them; say so plainly. Introduces the faux Broome trip, the made-up family and their competing wants, the privacy rule, and the eval set with its deterministic checks, repeat runs and held-out cases. Exam track: Building a Golden Dataset for LLM Evaluation; Picking an Evaluation Metric From the Cost of Being Wrong.
  2. Choosing the coding agent, fairly. Not a two-horse race and not decided in advance. Candidates: Claude Code, Kiro, OpenAI’s Codex CLI, Google’s Gemini CLI, and an open harness (Aider, OpenCode or Cline) driving other models, DeepSeek among them. Bias declared up front: Claude Code is the daily tool and the posts are drafted with Claude, so the method has to work against that. Three tasks from this build (a tool, a test suite, a refactor), the same repo state for each, a rubric written and committed before any run (evals pass, defects found in review, time, cost), and review done without knowing which agent wrote the diff where that can be managed. Publish the rubric and the losers’ best work. Exam track: Choosing Between Kiro, Amazon Quick, and Bedrock; Choosing a Model for Code Generation.
  3. Repo setup for any coding agent. AGENTS.md as the shared base with CLAUDE.md and Kiro steering where each tool needs its own, the layout, the test harness, what an agent may run. A multi-agent repo is the real test of a context file. Backward links: the two “Teaching your LLM the codebase” posts from April 2026.
  4. Choosing the model, from any vendor. The landscape is not just Claude: Bedrock’s catalogue carries models from Amazon, Anthropic, Meta, Mistral, OpenAI’s open-weight models and DeepSeek among others, and the direct OpenAI and DeepSeek APIs sit outside AWS. Confirm the current catalogue and which models are callable in or from Sydney when the post is written. Filter on tool-calling reliability on the faux-trip evals, cost per plan, latency, and where the data goes (a model hosted on Bedrock keeps the request inside AWS; a vendor’s own API does not). Routing a cheap model and a capable one is in scope. Exam track: Choosing a Model From the Bedrock Catalogue; Open-Weight or Proprietary: Choosing How You Host a Model; Cheat Sheet: Model Selection and Inference.
  5. Framework, runtime and the client. Strands on a laptop, AgentCore Runtime, Bedrock Agents, and the question the earlier plan skipped: how a family uses it together. Planning happens at home before departure, with several people adding to it, so the client is something each person can reach (a shared web app or a chat), and that decides inbound auth: one identity per person, with the children contributing through their own simple accounts or through a parent. Exam track: Choosing an Agent Framework for the AgentCore Runtime; Giving an Agent Credentials Without a Standing Key.
  6. The map data and its terms. Amazon Location Service’s providers (HERE, Esri, Open Data), and its service terms read before building: limits on storing or caching location data, attribution on anything shown, the exclusion of safety-critical use. These shape the eval fixtures (synthetic or openly licensed, not recorded API responses), memory, and the offline itinerary in post 16. Verify every clause against the current AWS Service Terms when writing; the reviewer quoted section 82 and that needs checking, not trusting.
  7. Remote WA data, measured. Pick 30 or more real places on the faux route (roadhouses, fuel, campgrounds, attractions) and count what the map data actually has: hours, fuel, phone, whether the place exists. Publish the numbers. Then the authoritative sources the map data cannot replace: Main Roads WA for road conditions and closures, Emergency WA for fire and flood, the Bureau of Meteorology for heat and weather. Decide what the agent states, what it hands off (“check Main Roads before leaving Sandfire”), and how it says what it does not know. Written so someone building for remote Queensland or the Northern Territory can reuse the method.
  8. First agent. Strands plus routing, planning days and stops for one leg of the faux trip, against the deterministic checks. The first scoreboard.
  9. Tests and evals first. Agents write tests that pass, which is not the same as tests that check. Hand-written evals, the held-out set, repeat runs, and judge calibration. Exam track: Evaluating an Agent’s Run, Not Just Its Answer; LLM-as-a-Judge: Designing a Rubric You Can Trust; Evaluating LLM Output With Bedrock Eval Jobs. Weigh AgentCore Evaluations alongside Bedrock evaluation jobs.
  10. The tools. Routing, places, weather, the authoritative-source hand-offs, and the choice of plain Python tools, an MCP server or AgentCore Gateway. Exam track: Lab: Wire a Tool the Model Can Call; Choosing Where an MCP Server Runs; Designing Safe Tool Schemas for an AgentCore Gateway.
  11. What’s on, and nudging the trip. A general events interface, not a food tool. Every source answers one question (what is happening near this place between these dates, and does it suit us) and returns one shape (what, where, when, how fixed, booking needed, source). Sources: any iCalendar feed (our cooking.ics with the food year, a family calendar of visitors, a club’s fixtures, a venue’s gigs); recurring patterns (parkrun, a monthly market); seasons (produce, fishing); hard constraints the plan works around (“grandparents arrive on the 14th”). Food and seasonality first, then a second unrelated source added without touching the agent. Use only feeds we are entitled to use and check each source’s terms. On the faux trip: a Broome event or two, a footy fixture in Port Hedland, a parkrun Saturday. Evals: suggests the right thing when passing at the right time, no 90-minute detour for it, never schedules over a fixed commitment. Then the step beyond suggesting: the agent proposes a change to the trip itself to catch something. The worked case is the Staircase to the Moon night the faux dates miss by a few days: the agent proposes moving the Broome leg, shows which other legs absorb it and what that costs, and leaves the decision with the family. Evals: proposes the nudge when it is cheap, does not when it breaks a fixed commitment, a booked overnight or the holiday dates, and never applies it unasked. Exam track: Grounding on Fresh Data: Tools or RAG.
  12. The family’s details. Decided before anything stores them: what is kept (age bands, tolerances, each person’s wants and who said them), where, for how long, who can see it, and why none of it is in the public repo. Then AgentCore Memory in practice: said once, applied to every later trip. Exam track: Designing Short-Term and Long-Term Memory for a Bedrock Chat Assistant; Keeping PII Out of LLM Prompts and Logs; Lab: Give a Bedrock Chatbot a Memory.
  13. Planning together. Several people contribute to one trip: wishes, must-haves, vetoes, and edits to the plan. Every change is recorded with who made it and why, so the plan has a history (“Dad moved the Karratha night; the pool afternoon went with it”). Weigh how that history is kept (a change log the plan is rebuilt from, or versioned snapshots), what each person may change, and how the agent handles two people asking for opposite things. Ties to post 5 (one identity per person) and post 12 (what is kept about each person). Evals: attribution is never lost or wrong, and a conflicting request is surfaced rather than silently resolved for whoever asked last.
  14. An agent building an agent. The coding agent writes the trip agent’s system prompt and tool descriptions; the evals measure whether that wording helps. Exam track: Prompt Engineering Techniques That Move the Needle; Finding Out Why a Prompt Stopped Behaving.
  15. What it must never do. Guardrails, the fatigue rule as a hard check, never asserting fuel, closures or fire danger it has not got from the authoritative source, and the safety-critical boundary from post 6. Exam track: Choosing a Guardrail Strategy: Managed, Custom, or Both; Configuring Bedrock Guardrails for PII, Topics, and Grounding; Putting Brakes on an Autonomous Agent.
  16. The offline itinerary. Signal drops out across long stretches, so the agent’s main output is something that works with none. Weigh the formats: a printable magazine (Craig made a mock-up offline magazine for his own version; it is the reference design), .ics for the calendar, an offline map export (GPX or similar), a saved web page. Then what the post 6 terms allow to be kept offline, and for how long, which is where the format choice meets the licence. The itinerary is produced once the plan is settled, before departure, and is what the family uses on the road.
  17. Is it fair? At the end of planning, the agent reports how well the trip serves each person: how many of their wants made it in, how much of the driving and the days went their way, whose vetoes held, measured from the attributed wishes rather than guessed. Weigh what “fair” should mean here (equal share, everyone’s top wish met, nobody’s must-have dropped) and say which one the agent uses. Where one person is short, it suggests rebalances that support them (“swap the second fishing morning for the wave pool in Karratha”) and shows what each swap costs the others. Deterministic scoring first, with an LLM judge only for the wording of suggestions. Evals: the faux family’s lopsided draft plan is flagged, the suggested rebalance improves the lowest score without breaking a constraint.
  18. Several coding agents at once. Subagents and worktrees building tools in parallel. The repo has a real failure to tell: a git reset --hard that wiped other agents’ in-flight edits.
  19. Reviewing what the agent wrote. The exam-track sweeps measured 6 to 13 wrong facts a post in agent-drafted prose. Apply the same audit to the code: invented AWS behaviour, parameters that do not exist, licence terms misread.
  20. Production. AgentCore Runtime, tracing a run, prompt caching, cost per planned trip, a budget alarm on the account. Exam track: Tracing an Agent’s Decisions in Production; Running agents in production with Bedrock AgentCore; Prompt Caching Versus Response Caching on Bedrock; Cost Guardrails: Budgets, Quotas, and Model Choice.
  21. The meta post. Writing about writing about it. Two streams of work kept apart: the build (sessions that wrote the agent) and the writing (sessions that wrote, verified and edited the posts). The setup for counting tokens and working out cost, time and outcome per post, how the blog’s own pipeline (style census, link checks, AWS fact verification) treats agent-drafted prose about a real build, and the footer that every post carries. Sits late because it reports numbers that only exist once the counting does; the planning conversation that produced this shelf is in the writing stream.
  22. Real life use. After the January trip, once home. Pictures and real prose. How planning together went, whether the fairness report matched how everyone felt about the trip, what the agent planned against what happened, where the data held and where it did not, what the offline itinerary was like in a car with children, and what we would change.
  23. The post-mortem. Every failure on the road becomes an eval case; the scoreboard against the larger set. The coding-agent side in numbers: tokens, cost, how much generated code survived to the final tag, which defects evals caught, which review caught, which only the trip found. Link the blameless post-mortem playbook only if it has published by then (it is dated 21 April 2027).

Practicalities

Later: the big lap

Re-planning on the road is deliberately out of scope for this run: the January trip is planned before we leave and followed. It becomes the centre of a possible later run on extended trips of six months or more, such as a lap of Australia, where the plan cannot be fixed in advance: re-planning when connected, weather and seasons moving under the route (wet season in the north, winter in the south), bookings made weeks rather than months ahead, and fairness tracked over months rather than a fortnight. Keep notes from this run that would feed it.