How GLEE turns a vague idea into a shipped system — walk the actual pipeline

Most "AI builds things" claims skip the part that actually matters: how does a vague idea become a real, checkable artifact instead of a plausible-sounding paragraph? This is that pipeline, shown live, using the exact commands run to build the two features this page links.

Step 1 — Intake, not implementation. A fuzzy idea doesn't go straight to code. It goes through four gates: name the problem in one sentence (refusing solution-shaped answers), check whether an existing system already covers it, tag every unverifiable assumption `TBD` instead of inventing an answer, and trace the idea to a real product goal. Try it yourself: state a problem in one sentence, out loud, before naming any fix. Most people jump straight to "we should build X" — catch yourself doing that.

Step 2 — Check before you build. Before any new code, this session ran:

grep -rl "glee_pkg.router.orchestrator" --include="*.py" .
grep -n "glee_pkg.router" glee.sh

Two greps found a fully-built, CLI-wired routing system that had simply never been called. The lesson generalizes past this codebase: most "missing feature" reports are actually "existing feature, no one checked" reports. Run the two-command search before the multi-hour build.

Step 3 — Prove the fix against the real failure, not a synthetic example. The router's ability to route correctly was tested against the *exact* task that had just been mishandled (an Agora deployment-status lookup), not a made-up demo case:

python3 -m glee_pkg.router.dispatch_cli dry \
  --goal "check whether Agora is deployed: find its code directory, check if a server \
process is running, check if it is wired into any site build" \
  --acceptance always --compact

Result: the router recommended `local-goal-engine` (the cheapest tier), never a frontier agent — confirming the fix target was real, not assumed.

Step 4 — Receipts, not narration. The finding above is written up as a receipt (linked in this page's frontmatter as `receipt_path`) with the literal commands run and their output, not a prose summary of "I checked and it works." Anyone can re-run the same two commands and get the same answer.

Try it yourself, right now, on any codebase: pick a "we should build X" instinct you have this week. Before writing code, run `grep -rl "<keyword>"` across the codebase for five minutes. If you find something, you just saved the build. If you don't, you've earned the build with two minutes of evidence instead of an assumption.

This page updates when the underlying receipt changes — that's the whole point of a Lyceum companion: it's allowed to be wrong today and get corrected tomorrow, as long as every version traces to one real, checkable receipt.

← back to Agora: How to read any AI benchmark claim (before you believe it)

Companion relationship: extends