Why It Exists

Why It Exists

I built dreamcontext because I kept hitting the same wall from two directions at once: my agents didn't know my project, and my project didn't live anywhere an agent — or a teammate — could actually see it.

A project is not a codebase. It is decisions and the reasons behind them, product features and their acceptance criteria, a roadmap with dates that are supposed to mean something, metrics that say whether any of it is working, and the knowledge of the people building it. In practice, all of that lives scattered across five platforms, three people's heads, and one slide deck — and the AI agent you work with every day sees none of it.

That blindness shows up everywhere, not just in code:

• When agents build, they make judgment mistakes a human has to catch. I have watched frontier models — repeatedly, on real projects — fetch entire collections instead of filtering at the query level; write cloud functions that trigger on a write and write back to the same path, no recursion guard, one deploy away from draining the billing; ship the happy path with no error boundary, no retry, no index on the field they just queried; and reshape code until the test goes green, which is not the same thing as the system being correct. A human engineer needs to be steering — and steering only works when both sides see the same picture: what was decided, what is in progress, what rules apply, what was tried before.
• When you plan, you plan on stale numbers. The metrics that should drive the next sprint live in a product-analytics tool, Stripe, a monitoring service, and a spreadsheet. Combining them is a project of its own, so decisions get made on the figure someone remembers — and the agent helping you plan has no figure at all.
• When you set a roadmap, it detaches immediately. The objectives live in a deck, the work lives in a tracker, and nothing computes one against the other. "Are we on track?" becomes a meeting. The roadmap becomes an abstraction nobody can reach from their daily work.
• When a teammate needs the picture, it's archaeology. The real state of the project is in heads, chat threads, and a wiki nobody trusts. Onboarding is excavation; a departure takes the reasons with it.
• When your platforms add AI, it's their agent, on their cloud. It has read everything, tells you nothing about what it retained, and your most sensitive material is now sitting behind someone else's API. You can't audit it, correct it, or take it with you.

That is what dreamcontext is. Not memory bolted onto an agent — the layer where the project actually lives: one big picture that you, your team, and your agents all see and act on. When I open my project's context files, I can see exactly what the agent knows, correct what it got wrong, and make sure the next session starts with accurate information. When a teammate pulls, they see the same picture I do — because the agents maintain it as human-readable files, not as a store behind an API.

None of these problems are accidental. They are structural — in how agent memory works today, and in where our projects are forced to live. The next section takes them one at a time.

---

Part of the dreamcontext deep dive — Home · README