Training a Safe-Routes skill: notes from the loop

SafeRoutes is a road-trip planning system built around a strict separation: functions decide the route; agents only judge the world.

The project is manual-address-input and no-GPS by design. Given a start, destination, vehicle constraints, and trip constraints, it builds a vehicle-aware route and checks whether anchor POIs like gas, lodging, and repair stops are usable today.

The iron law

The core rule is simple: the agent never edits the route.

Agents can say whether a station is usable, whether a road description looks risky, or whether evidence is strong enough to trust. The route itself converges through the Orchestrator, a deterministic function layer that owns planning decisions.

That boundary keeps the system debuggable. If the route changes, the reason should be visible in code and data, not hidden inside an LLM completion.

Function + agent hybrid

The function layer handles geocoding, routing, corridor math, anchor planning, cost scoring, and persistence. The agent layer supplies world judgements through pluggable search, fetch, and LLM providers.

In practice, that means the planner can stay static-first and testable while still using agents for the messy part: validating current external conditions.

What the loop tests

The useful tests are not only "does the agent answer?" They are contract tests around degradation and authority.

If search fails, validation degrades to unknown. If fetch fails, the system can fall back to snippets. If the model output is malformed, the parser degrades instead of letting a bad answer mutate the plan. Architecture tests also keep the agent layer from importing routing or orchestrator internals.

Takeaway

The lesson is that agents get safer when their authority is narrow. A route planner can use LLMs without letting an LLM become the planner.

For this kind of system, I want agents to be sensors: gather evidence, make bounded judgements, expose uncertainty. Deterministic code should make the final route decision.