London Postcode Finder

How it works

A search passes through nine steps in two passes. The first is fast and numerical. The second is slow and qualitative, and only looks at the five districts that survived the first.

The line a search travels

  • Agent: a model making a decision
  • Agent that only runs when needed
  • Scorer: a deterministic lookup
  • Memory

  1. Knowledge Loader

    Reads the distilled rules plus the last ten raw notes, and hands them to the orchestrator and the writer.

  2. Orchestrator

    Reads your tokens and your words, then decides. It ignores context that doesn't matter, shifts your weights when you signal a priority (“terrified of crime”), or spawns a context agent when you ask for something the scores don't measure (“a nursery nearby”).

  3. Context Sub-Agent

    Only when spawned. Turns the request into an OpenStreetMap query (or a web search when there's no map tag for it), counts matches around all 40 districts, and caches the answer for 30 days.

  4. Five scorers, in parallel

    Pass one. Each reads a monthly pre-computed score for all 40 districts from police, OpenStreetMap, TfL and ONS data. No model is involved, and it finishes in under a second.

    • Safety
    • Green space
    • Nightlife
    • Transport
    • Affordability

  5. Synthesiser, pass one

    Multiplies each score by your tokens, ranks the districts, applies the context agent's filter if one ran, and keeps the top five.

  6. Five research agents, in parallel

    Pass two. One agent per shortlisted district searches the web for recent news, local discussion and changes the monthly data can't see yet.

    • District 1
    • District 2
    • District 3
    • District 4
    • District 5

  7. Synthesiser, pass two

    Combines scores, research, your context and the memory into five recommendations, each with a verdict, a rationale, an honest tradeoff and a practical tip.

  8. Knowledge Writer

    Saves two or three full-sentence notes about what this search taught it, and counts the search.

  9. Distiller

    Every ten searches, after your results are already on screen, rewrites the notes into at most twelve rules, merging, refining or retiring the old ones. The dashed loop is this memory feeding the next search.

Scorers are not agents

The five data pipelines are deterministic: same input, same number, no judgement. Calling them agents would overstate what they do. The judgement lives in three places: the orchestrator deciding what your words mean, the context agent deciding how to measure something new, and the research agents deciding what's worth reporting.

Spawning is a filter, not a sixth score

If you need a nursery, a district with none nearby isn't a slightly worse fit. It's the wrong fit. So the context agent's result removes districts with zero matches from the shortlist rather than being averaged in, where a high nightlife score could drown it out. The “Why these results” panel shows which districts were removed.

Layered memory instead of retrieval

The domain is narrow: 40 districts, five dimensions, a few dozen kinds of request. Rather than retrieving similar past searches, it keeps what a long conversation keeps: a compressed summary of the old (the distilled rules) and the recent notes word for word. With repeated patterns, the summary gets sharper instead of just longer.

Why two passes

Web research is the slow, expensive part, so it only runs on five districts. Cached scores make pass one near-instant and immune to flaky public APIs. A whole search costs roughly $0.15 to $0.20 in model calls and takes about a minute.