The Problem In Depth
Every feature in dreamcontext exists because one of these problems bit me on a real project. This is the catalog — each problem, and what it became. The first four are about the agent; the rest are about the project, the team, and the platforms we were all tolerating.
You ask the agent to work on a task. The task references something, maybe a caching strategy you decided on two weeks ago. One paragraph. A clear decision that already lives somewhere in your project. But the agent does not know that. So it starts digging.
It greps for "cache." Finds 14 matches across 8 files. Reads 3 of them. Realizes those are implementation files, not the decision. Searches for "strategy." Reads 2 more files. Finds a comment that references a config pattern. Reads the config. Now it searches for where that config is used. Reads 2 more files. Finally pieces it together.
Three minutes. Multiple tool calls. Context window already filling up. And then it says: "Ok, now I completely understand the codebase. Let me plan the implementation."
You have not started working yet. You have been watching your agent do archaeology on a decision it already knew yesterday. This happens every session. And it scales with your project. More files, more decisions, more things to re-discover. You are paying for search, not for work.
 Without dreamcontext The agent does archaeology on decisions it already knew yesterday. |
 With dreamcontext The decision is already in the snapshot. One read if needed. No spiral. |
What it became: the hook mechanism — context pre-loaded before the first message, zero tool calls.
A CLAUDE.md works for small projects. "Use tabs. Prefer functional. API is in /src/api." That is fine when your project is simple.
But when you have 200 files, 15 active decisions, 3 in-progress features, and a deployment process with edge cases, one file either balloons into a wall of text the agent skims past, or stays too shallow to help.
Think about it: identity and principles, user preferences, technical decisions, task progress, deep reference docs. These are structurally different types of knowledge. They change at different rates, serve different purposes, and need different formats. Putting them in one file is like storing your calendar, contacts, journal, and reference library in one document. It works until it doesn't.
What it became: the brain-region architecture — purpose-built files that change at different rates, kept sharp by the sleep cycle.
It does not matter how your agent searches. Grep, glob, fuzzy match, RAG, vector store. The search technology is not the problem. The problem is that search is the wrong approach for baseline context.
Every time your agent greps for a function, reads a file to remember a decision, or globs for config files to understand project structure, it is spending tokens. Tool calls, output parsing, reasoning about what to search next. Whether that is a local rg call or a vector similarity query, the cost is the same: tokens and time burned on re-discovery instead of actual work.
Your agent should not need to search for who it is, what it is working on, or what decisions were already made. That is not a search problem. That is baseline context that should already be there when the session starts.
The write side has the same issue. Adding a technical decision, logging task progress, and creating a knowledge doc are structurally different operations. They belong in different places with different formats. A flat append to a single file cannot express that difference.
And when it comes time to retrieve, structure is what makes the difference between a clean answer and noise. "What are my active tasks?" is a directory listing, not a search query. "What does the soul file say about error handling?" is a file read, not a fuzzy match across everything. When your context is structured, you don't need clever retrieval. You just go to the right place.
What it became: the SessionStart snapshot for baseline context, and BM25 recall for everything deeper.
Some tools offer built-in memory behind their API. Sometimes you can see what the agent "knows." Sometimes you can even edit it. But every interaction ties you deeper to that platform. You can copy-paste to another tool, export to a file, find workarounds. But should you have to struggle with friction just to access your own project's context?
When you switch tools, or the service changes its API, or you want to work offline, that knowledge is trapped behind someone else's interface. The friction is the lock-in. Not a hard wall, just enough resistance that most people stop trying.
Your agent's memory should be files in your repo. Markdown and JSON. Readable, editable, diffable. You should be able to open your agent's understanding of your project in any text editor, fix a wrong assumption, and commit the change. That is ownership.
What it became: everything is plain markdown and JSON in your repo, browsable in Obsidian, owned by you.
The numbers that tell you whether the project is actually working — active users, conversion, revenue, error rate — live in five different systems with five different logins: a product-analytics tool, Stripe, a database console, a monitoring service, a Google Sheet someone maintains by hand. Checking them all is a chore, combining them is a project, and keeping them combined is impossible — so nobody does. Decisions get made on the number someone remembers from last month, or on a screenshot pasted into a doc that was stale the moment it was pasted.
And your agent is worse off than you: it sees no metric at all unless you paste one into the conversation. An agent that helps you plan a sprint without knowing that retention dropped two weeks ago is planning blind.
What it became: Lab — curated insights fetched from any API or script, rolled up, cached in the brain, surfaced to every session, and bindable to a roadmap objective's Key Result so progress is measured, not asserted.
The roadmap lives in a deck. The tasks live in a tracker. There is no computed connection between them — so "are we on track for the Q3 target?" is a meeting, not a query. Objectives drift into abstraction: they get written once, presented twice, and then stop steering anyone's daily work, because nothing in the daily work points back at them. Project visibility dies not from a lack of information but from the information living in places that never talk to each other.
What it became: the roadmap objective board — PO-authored objectives as files, tasks linked many-to-many, a full-DAG forecast cascade where a slip upstream visibly moves every dependent, and slip detection surfaced in every agent session — so the roadmap is something the daily work computes against, not a slide.
Every project-management platform makes you work its way. The view you actually want is three custom fields and a plan upgrade away. The export is lossy. The automation almost does what you need. And when AI arrives, it arrives as their assistant, on their data model, answering questions their way. You adapt your process to the tool, because the tool will not adapt to you. Meanwhile your agent — the one that actually builds the product — can't meaningfully read any of it.
What it became: tasks as files you own, with the views you'd pay extra for — Kanban, Gantt, calendar, heatmap, Eisenhower, RICE, custom fields declared in one file — and two-way sync to ClickUp or GitHub Issues so the rest of your team keeps working where they already are.
Onboarding someone is archaeology: the real state of the project lives in heads, Slack threads, and a wiki nobody trusts. The person who knows why the auth flow is shaped that way leaves, and the reason leaves with them. Handoffs are lossy, "ask Deniz" is the documentation, and the docs that do exist are stale enough that reading them is riskier than not. Teams don't have a writing problem — they have a maintenance problem. Nobody's job is keeping the shared picture true, so nobody does.
What it became: knowledge files as the single source of truth that agents maintain during sleep, shared over Brain Cloud Sync — pushed, pulled, and merged like code, with a semantic merge agent for prose conflicts and attribution that rides tags, not file forks.
The AI assistant embedded in your drive, wiki, or PM tool has read everything and tells you nothing about what it retained. Its memory is opaque, its context is whatever the vendor decided, and your project's most sensitive material — strategy docs, credentials in pasted snippets, unreleased plans — is now training-adjacent data in someone else's cloud. You cannot audit what it knows, correct what it got wrong, or take the knowledge with you. For anyone who takes data security seriously, an agent you can't inspect, running on data you can't fence, is not a feature — it's a liability.
What it became: local-first everything. The brain is files in your repo. The dashboard binds to loopback only, with CSRF/CORS/path-traversal guards; the in-dashboard chat is read-only, enforced three independent ways; credentials live gitignored at 0600 and are structurally redacted; a scrub gate blocks secrets before every push. Nothing leaves your machine unless you turn sync on — and then it goes to your own GitHub, not ours.
The decisions that shape a project — migrate or not, hire or not, this architecture or that one — get answered by whatever a single model says in a single pass, anchored by however you happened to phrase the question. One perspective, no adversarial pressure, no record of the dissent. You wouldn't run a real decision review that way.
What it became: Council — N personas with scoped mandates, blind first rounds so positions form independently, cross-context rounds so they sharpen, and a synthesized verdict that cites the voices — stored in the brain, promotable to knowledge.
Real work spans repositories. The decision made in the API repo is invisible from the app repo. Each project becomes a silo with its own partial picture, and the copies people make to bridge them go stale immediately. Multiply by a team and the "big picture" exists nowhere at all.
What it became: Federation — live, opt-in, read-only recall across your projects' brains, a reference never a copy — and Linked Repos, so one brain can govern a family of bare code repos without owning them.