PREFLIGHT: ADDING A CHECKPOINT BEFORE AGENT WORK
In this run, startup work consumed 42% of the context window.
Context: This is Part 3 of a series about building agent infrastructure. Part 1 built memory. Part 2 fixed testing. This part adds slowdown.
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.
In this run, the checkpoint stopped work on a service the agent's test showed it did not need.
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 runs against the usual product direction of adding speed, autonomy, and capabilities.
But the agent asked for a checkpoint. 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 .. Adding a checkpoint before agent work (you are here)
- Part 4: loop-demo .. Dogfooding Until It Worked