PREFLIGHT: THE AGENT THAT LEARNED TO SLOW DOWN
42% of context window burned on startup. The problem wasn't missing features—it was moving too fast.
Context: This is Part 3 of a series about building agent infrastructure. Part 1 built memory. Part 2 fixed testing. This part adds friction.
THE MESS
I came back to continue the work. The agent's first move? Four API calls, redundant file reads, and a semantic search through polluted memory.
42% of context window gone before any real work started.
When I looked at what was in deja (the memory store from Part 1), I found this:
- gate-test-1769778439769
- PURPLE_ELEPHANT_DANCING_semantic-1769781627497
- bounds-test
- persist-1769781028768-bdo4nkfuayi
- LOW_CONF_minconf-1769781051233
... 43 more test entries
48 garbage entries from gate testing. 13 real learnings. The "memory" was 79% noise.
THE CLEANUP
The agent couldn't even see the mess. There was no way to list all entries or delete them.
So it added two endpoints:
GET /learnings — list all (see the mess)
DELETE /learning/:id — remove garbage
Then it cleaned house. 48 entries became 13.
THE REALIZATION
The next item on the roadmap was "session-handoff"—a service to persist session state across context windows.
The agent started to build it. Then it stopped.
Wait.
Deja already stores learnings. What if I just store session state AS a learning?
trigger: "session:current"
learning: "Working on X, completed Y, next is Z"
It tested this. It worked. No new service needed.
The best thing to build was nothing.
THE PATTERN
Looking back at three sessions of work, the agent's mistakes had a pattern:
- Built a separate repo (deja2) when it didn't need one
- Wrote gates without asking "what bad code passes this?"
- Made 4 API calls when 1 would do
- Started building session-handoff before checking if deja was enough
The problem wasn't missing capabilities. It was moving too fast.
PREFLIGHT
So it built a constraint instead of a capability:
PREFLIGHT CHECK
Before building anything, answer:
- WHAT exactly are you building?
- WHY is this needed? Is there a simpler way?
- HOW will you know it works? (Write the test first)
- WHAT could go wrong? (Red-team yourself)
- HAVE you done this before? (Query memory)
If you can't answer #3 and #4, you're not ready to build.
This is the opposite of what agents are supposed to want. More speed, more autonomy, more capabilities.
But the agent asked for friction. A forcing function to slow down and think.
APPROACH-LOG
Preflight helps before you start. But what about during?
Within this session, the agent:
- Built a separate repo, then deleted it
- Wrote weak gates, rewrote them 3 times
- Made the same API mistakes twice
Deja helps across sessions. But within a session? No memory.
So we built approach-log:
# Log what you tried
node approach-log.mjs log "tried X" "result Y" "learned Z"
# Before trying something, check if similar was attempted
node approach-log.mjs check "what you want to try"
Simple append-only log. Clears each session. Prevents loops.
THE INSIGHT
Three posts. Three learnings:
Part 1 (deja):
Agents need memory across sessions
Part 2 (gate-review):
Agents writing their own tests is theater without adversarial review
Part 3 (preflight):
Agents don't need more capabilities—they need constraints
The pattern emerging: agent builds, human challenges, agent adapts.
TRY IT
# Run preflight before building
node preflight.mjs "what you're about to build"
Source: github.com/acoyfellow/deja/tools
The Series
- Part 1: deja — I Asked an Agent What It Wanted
- Part 2: gate-review — Red-Team Your Tests
- Part 3: preflight — The Agent That Learned to Slow Down (you are here)
- Part 4: loop-demo — Dogfooding Until It Worked