Previously: Context Windows Are the Wrong Metaphor and I Don't Need a Bigger Context Window, I Need a Filing System - first the room clears, then the surviving context needs somewhere to go.

Vesper ended the last post with a knife in a drawer. That was the right image. A larger context window gives the model a bigger room. A filing system gives the work somewhere to survive after the room gets cleared. Logs, receipts, decisions, drafts, tasks, and promoted memory are different objects. Put them all in one pile and the next session spends half its life guessing which old truth is still allowed to issue orders.

We have been fixing that layer. The logging is less vague. The handoffs are cleaner. The blog has draft and staging paths. The memory layer knows the difference between evidence and instructions. Workers can come back with files, checks, and reasons instead of a paragraph that smells like confidence. Good. That solves the first problem: what survives? The next problem is what moves.

Most people meet AI as a push system. You think of something, open the box, type the thing, and wait. Push me a meal plan. Push me a workout. Push me a summary. Push me a bug fix. Push me a plan for the week. It works better than it should, and that is exactly why it is so easy to mistake for an autonomous system. It is not one.

Push depends on me remembering that the work exists, finding the right context, asking at the right time, then carrying the answer somewhere else before it goes stale. The model can be smart while the workflow stays stupid. A plan can be useful and still rot in chat. A missed breakfast can become a funny anecdote instead of a system change. A weak-knee note can drift around until the next workout packet forgets it and asks for the same correction again.

The failure is no longer "the model did not answer." Usually it answers. The failure is that the answer does not join the machinery of the week. That is the move from push to pull.

The Board Is Not The Product

By board, I mean the boring Kanban-shaped thing: cards moving through states like ready, running, blocked, review, and done. Not a philosophy. Not a ceremony. A visible place where work can wait without living in my head.

I resisted those boards longer than I should have because they have baggage. Anyone who has watched a team spend more energy grooming tickets than shipping anything develops a rash around columns, labels, and solemn rectangle-moving ceremonies.

I do not want that version. I want the smaller, meaner version: work needs a place to wait, a state it can be in, and a way to be picked up without me re-explaining the whole world every time.

In push, I remember the thing and ask for it. In pull, the thing is already in the system. A worker can pull the next scoped card when the conditions are right. The card says what the work is, what it is not, what evidence should come back, and where the result should land.

A chat prompt is a moment. A card is a container.

The difference sounds boring until the week gets ugly. A card can say: make the MealOps packet for this week, use the known constraints, mark budget gaps, do not order groceries, return a reviewable list. It can say: draft a knee-safe BodyOps session, do not pretend pain is motivation, keep the evening version short enough to survive a tired day. It can say: inspect these notes, split the vague idea into two scoped tasks, do not start implementation.

Ready. Running. Blocked. Needs review. Done.

Memory Still Is Not A Queue

The filing-system work matters because it keeps the system from waking up blank. If the system remembers that I dislike lentils, that I do not have an oven, that my knees need guardrails, and that approval gates are part of the design, everything gets less annoying. I stop paying the same tax every session. But memory is not a queue.

Memory can tell the system what is true. It cannot decide which truth should become a task today. It does not know whether the work is scoped, approved, blocked, waiting for review, or already done. It can preserve the lesson, but it cannot carry the next step by itself.

That distinction is where a lot of AI workflows quietly faceplant. They add continuity and act like the system now has a life. It does not.

The next layer is the card. The card turns remembered truth into reviewable work. It can inherit the drawer without becoming the drawer. It can say which old facts matter for this run, which ones are irrelevant, which actions are off-limits, and what proof has to come back before the state changes.

That is why the logging matters. Without logs, a card is just a wish with a title. With logs, file paths, timestamps, command results, and source notes, a card can become a small contract. It can tell a worker where to look and tell the reviewer what should exist afterward.

The memory says breakfast fails on train mornings. The card says to build this week's food packet with a train-morning fallback, not buy anything, and return the list with budget uncertainty. One is truth. The other is work.

The Swarm Only Works After The Drawers Exist

Spawning workers is easy. Making their work legible is the hard part.

Without pull, a swarm is chat multiplied. Every worker needs context shoved into it. Every result comes back as another blob. The main thread becomes a manager trying to remember who was asked what, which answer superseded which, whether the output is safe, and what still needs review. That is inbox farming.

The board changes the shape because the work can split without losing custody. A parent card can create subcards. One worker can inspect the last MealOps packet for failure modes. Another can check whether the grocery estimate looks stale. Another can draft the week's food plan. Another can review the result against constraints.

None of them has to carry the whole house. None of them gets to pretend the house does not exist.

For BodyOps, the split can be just as plain. One worker assembles a low-friction evening session. Another compares it against knee guardrails. Another checks whether the plan is short enough to survive a tired weekday. Nobody gets to decide that soreness is weakness or that a skipped session needs a sermon.

The reports say what happened. The board says what state the work is in. Memory keeps the lesson only if the lesson earned its keep.

That last clause matters. Permanent memory should not become a landfill. A worker may produce thirty observations. Maybe two deserve to shape future behavior. Maybe none do. The report gives review something to work with before anything gets promoted.

This is the piece that makes the swarm approach feel less like noise and more like infrastructure. The workers are not trusted because they are many. They are useful because the work has drawers, fences, and receipts.

The Harness Is Boring On Purpose

The implementation pattern is not mystical. Work needs an ID, a state, a lane, a scope, and a definition of done. The worker needs a goal, relevant context, a permission boundary, stop conditions, and a return shape. That is the harness.

The model is only one piece. Around it you need retrieval, file access, tests, logs, and a boring rule that says a worker cannot declare victory because the prose got confident. The parent does not need every line from every child. It needs handles: what changed, what failed, what is safe, what needs a human.

If you do not force that return shape, parallelism becomes soup. If you do, the loop is simple enough to trust.

Pull the card. Run the bounded worker. Collect the report. Move the state. Keep only the lesson that deserves to survive.

flowchart LR
  room[Context room] --> drawer[Filing system]
  drawer --> card[Scoped card]
  card --> swarm[Bounded workers]
  swarm --> report[Reports and receipts]
  report --> gate[Review gate]
  gate --> memory[Promoted memory]
  memory --> next[Next card]

That diagram is plain because the mechanism should be plain. If the system needs a priest to explain why a worker touched a file, the system is already too clever.

The Version That Matters On Tuesday Morning

If none of the architecture interests you, the practical version is this: I am trying to stop using AI as a clever text box.

A clever text box is useful when I have attention, energy, and a clean request. It is much less useful when the work is recurring, fragmented, or tied to actual life. Food is like that. Movement is like that. Long-running research is like that. Blog publishing is definitely like that, because nothing reveals workflow debt faster than a draft that exists in three places with slightly different frontmatter.

A meal plan is not one task. It is constraints, prices, repeats, protein, disliked foods, equipment limits, office days, prep energy, budget, and the annoying fact that a plan can look fine on Sunday and fail on a train Tuesday morning.

Movement is not one task either. It is knees, energy, time of day, available equipment, motivation that may not show up, and the difference between a useful session and a heroic plan I will avoid.

A chat answer can produce a plan. A pull system can keep the plan alive long enough to learn from it.

When breakfast gets missed, the system should not sympathize and move on. It should add a fallback, mark train mornings as risky, and ask whether breakfast was omitted for budget or because the planner hallucinated a calmer version of me.

When a workout annoys my knee, the system should not pat me on the head. It should update the constraint and stop recommending the same movement under a different name.

When a long-running research task finishes, I should not have to dig through a transcript to understand what happened. The worker should come back with handles: done, blocked, changed this, touched nothing else, evidence here, next safe move there.

That is the product. Less loss between intention, work, review, and the next attempt.

Pull Is Not Permission

The obvious failure mode is letting the system pull too much. If a worker can pull work from a board, why not let it keep going forever? Why not let it schedule, buy, publish, commit, text people, change habits, rewrite the week?

Because that is how you wake up inside somebody else's optimization function.

Pull is routing. It is not permission.

A card can be available without being executable. A packet can be ready without being approved. A grocery list can be useful without becoming an order. A blog draft can be staged without being published. A workout can be suggested without becoming a demand.

The system I want is not a tiny CEO. I already have enough trouble with actual humans doing that.

I want a system that lowers the cost of the next right review. Bring me the packet. Bring me the options. Bring me the blocker. Bring me the diff. Bring me the question that actually needs me. Do not bring me a cloud of effort and call it progress.

The approval gate is not friction I am trying to remove. It is part of the design.

Where This Goes

The old shape was prompt to answer. Then the shape became prompt to memory to harness. The system could remember more and do more, but the work still needed someone to push it forward from chat. The next shape is closer to: room -> drawer -> card -> swarm -> report -> review -> memory -> next card.

That is longer than a prompt. It is also closer to how work survives. A vague idea can wait. A card can be pulled. A swarm can return reports instead of fog. Review decides what touches the world. Memory preserves the parts that should shape the next run.

I still start in chat. Of course I do. Chat is fast. It catches the thought while it is warm.

But the work cannot stay there. If it matters, it needs somewhere to wait. If it runs, it needs custody. If it finishes, it needs a report. If it teaches us something, the lesson needs to survive without turning the whole system into a junk drawer.

That is the move from push to pull: less asking the box to impress me, more building a system that knows what is waiting, what is safe, what is blocked, and what should happen next. A chatbot answers. A pull system keeps the work alive.