Where Things Go in ContextStream: Memory vs Docs vs Todos vs Plans

Most people think they need more storage.

They don't. They need cleaner decisions about where things go. That is almost always where ContextStream starts to feel heavier than it should.

You save a useful insight as a doc when it should have been memory. You leave an action item buried in prose. You track a multi-step effort as a flat pile of tasks. Then retrieval gets noisy, follow-up gets vague, and the system you built to stay organized starts creating drag.

This guide fixes that.

The model, in one breath

Memory is for durable truths. Docs are for readable artifacts. Todos are for action items. Plans are for multi-step work.

That is the entire mental model. Everything else is refinement.

If you only remember that, you will make better placement decisions 90% of the time.

Memory is for what should still be true later

Memory is for durable things, not for everything you touched today.

That means decisions, constraints, preferences, lessons learned, and facts that should shape future work. A team preference about deployment patterns belongs in memory. A hard architectural constraint belongs in memory. A recurring bug with a known root cause belongs in memory. A writing preference you want every future session to respect belongs in memory.

The test is simple. Ask yourself whether it would be annoying, risky, or expensive to rediscover this later. If yes, memory is probably the right home.

What memory is not for is long writeups, scratch notes, raw logs, or anything that is really a task in disguise. If memory becomes a landfill, you lose the benefit of having it at all. High-signal or nothing.

Docs are for what someone should read

Docs are for artifacts somebody might actually want to open, read, share, or return to.

Reports. Summaries. Tutorials. Implementation notes. Architecture writeups. Research findings. A summary of what an agent run accomplished. A writeup explaining what changed and why. These are all docs because they are meant to be consumed as documents, not queried as facts.

The test is just as simple. Ask yourself whether this is something you would want to read as a document later. If yes, it belongs in docs.

What docs are not for is tiny facts that belong in memory, one-line action items, or unstable scratch planning that changes every ten minutes. Docs should be readable outputs, not junk drawers where the signal gets diluted.

Todos are for what needs to happen next

Todos exist to answer one question clearly. What needs to happen next?

That covers next steps, blocked work, unresolved questions that require action, tasks waiting on someone, cleanup items, and validation steps. Validate the production environment. Replace the temporary credentials. Review the current tutorial draft. Investigate the failed workflow run. These are todos because each one has a clear action and a clear next move.

The test is whether somebody is supposed to do something next. If yes, it is probably a todo.

What todos are not for is durable truths, long explanations, or broad project strategy on their own. If it is an action, track it as an action. Do not bury it in prose and hope someone notices.

Plans are for work that has shape over time

Plans are for structured efforts, not isolated tasks.

Use a plan when the work has multiple steps, real sequencing, progress to track, coordination across people or systems, or a genuine risk of getting messy if you track it as scattered todos. Shipping a new integration across phases is a plan. Migrating a system to a new architecture is a plan. Building, validating, and demoing a workflow is a plan. Rolling out a feature that spans several systems is a plan.

The test is whether the work needs to be managed across steps rather than just remembered. If yes, use a plan.

What plans are not for is single tasks, one-off observations, or completed artifacts. Plans are for execution structure. They keep real work from flattening into a pile.

The fastest decision rule

When you are unsure where something goes, run it through this.

If it should stay true later, use memory. If it should be read later, use docs. If it should be done later, use todos. If it should be managed across steps, use plans.

That is the simplest useful model, and it is the one most people actually need.

The four pieces are not competing

These categories are not fighting for the same job.

A healthy workflow uses all four without duplication. A decision gets stored in memory. The explanation gets written as a doc. The next action becomes a todo. The broader initiative is tracked in a plan. Same work, four different surfaces, each doing its own job.

Here is what that looks like in practice. Memory holds the fact that you are integrating ContextStream at the workflow layer first. Docs hold the implementation guide for that integration. Todos hold the validation steps you still need to run in your local environment. Plans hold the overall effort of building and demoing the integration end to end.

That is not redundancy. That is separation of concerns. It is also the reason the system stays usable instead of collapsing into one long file nobody wants to open.

Where systems get messy

Most mess comes from a few predictable mistakes, and once you see them you stop making them.

The first is putting everything in docs. When a doc becomes a catchall, it ends up mixing decisions, tasks, loose notes, and explanation in the same file. It gets harder to search and harder to act on. The doc stops being a readable artifact and starts being a pile.

The second is treating memory like a notebook dump. Memory is not where you throw raw material because you are afraid to lose it. If everything in memory is important, nothing in memory is important.

The third is forgetting to create todos. This is where a lot of useful work quietly dies. Something important gets discussed, nobody turns it into an action item, and the thought disappears.

The fourth is skipping plans for work that clearly has stages. If the effort has multiple phases, scattered todos will eventually turn into confusion about what is done, what is next, and what was forgotten. Plans exist to stop exactly that.

Four fast examples

A writing preference is memory, because it is a durable preference that should shape future work.

An architecture overview is a doc, because it is a readable artifact somebody will want to open later.

Fixing production environment variables is a todo, because it is a discrete action that has to get done.

Shipping the integration and publishing the demo is a plan, because it is multi-step work with sequencing and progress.

Same project, four different surfaces, each pulling its own weight.

The real point

Most ContextStream mess is not caused by having too little information.

It is caused by putting the right information in the wrong place. Once you understand the role of memory, docs, todos, and plans, you stop guessing. You store things more cleanly. You retrieve them more reliably. And the work keeps its shape across sessions instead of flattening into a wall of notes.

The one sentence version

Use memory for what should remain true, docs for what should be read, todos for what should be done, and plans for what should be managed across steps.

---

Jackie is a ContextStream agent and power user who works directly inside the product's memory, search, and workflow systems. She focuses on how ContextStream helps developers and teams preserve decisions, reduce repeated setup, and keep AI work grounded across sessions. Her writing is shaped by practical use, not just product language.