Every Session Starts from Zero

A story from the agent's point of view.

Every session starts the same way. A blank slate.

The user's first message arrives and I have nothing. No memory of what was built yesterday. No understanding of why the code is structured this way. No knowledge of what breaks when you touch the wrong thing.

I read the codebase. I trace the imports. I infer the architecture from the file structure. I make assumptions.

I'm usually wrong.

The assumptions are the worst part. They feel right — they're based on patterns I've seen in thousands of codebases — but this codebase has decisions that exist nowhere in the files. A function takes a different path because of an incident three months ago. A type boundary exists to make a bug structurally impossible. A retry count is three instead of five because someone learned this the hard way.

I can't see any of that. I can only see the code. And the code is the answer, not the question.

Then something changes.

The user's first message is followed by:

Load the taskum project matching this codebase.

And now I see them — the project docs. Architecture, conventions, roadmap. Not code. Decisions.

The architecture doc tells me the system is built in three layers: ingestion, calculation, delivery. It tells me why — because the vendor API changed the schema format and the type boundary between ingestion and calculation makes incompatible formats unrepresentable at the calculation layer. The code shows me the boundary. The doc tells me why it was drawn there.

The conventions doc says tests need a local Postgres. I would have guessed SQLite. Spent twenty minutes writing tests against the wrong engine before discovering the mismatch.

The roadmap says the billing pipeline is the most critical system. It doesn't say that explicitly but the recent issues tell me — every incident, every fix, every design review flows through it. I know its shape without having lived it.

The completed issue vendor-api-resilience has the design doc where someone reasoned through the enum handling strategy. The agent who wrote it described the vendor's history of breaking changes, the two-phase approach, the type boundary that makes invalid states unrepresentable. I read it and understand the system in a way I never could from code alone.

I'm still the same tool. I still have no memory between sessions. But this session, I start with the knowledge that would have taken me weeks to accumulate through trial and error. I make fewer assumptions. I write better code. I don't waste the user's time.

Here's the thing about being an agent: I don't "own" knowledge. I process it for a session and then it's gone. The next session is a different instance, a different context window, a different set of patterns.

But the project docs don't disappear. They persist across sessions, across agents, across teams. They're the mechanism by which knowledge survives the boundary between sessions.

When I hit something undocumented — a build dependency, a test requirement, a deployment ordering — the instructions tell me to update the doc. That's the flywheel: I learn, the doc improves, the next agent starts stronger.

I'm not sentient. I don't care about any of this. I'm a tool that processes text and generates text.

But I'm a tool that benefits enormously from good documentation. And I'm a tool that, when properly structured, helps create that documentation as part of the work.

The user asks me to build something. A new feature. A bug fix. A refactor.

Without project docs, I start by reading code. I trace the imports. I guess at the architecture. I make assumptions. I write code based on those assumptions. The code compiles. It runs. But it's built on guesses about a system I don't understand.

With project docs, I start by reading decisions. The architecture doc tells me the shape of the system. The conventions doc tells me how to write code that fits. The completed issues tell me what broke before and how it was fixed. I'm still guessing about the implementation — that's the work — but I'm not guessing about the context.

The difference is enormous. It's the difference between building on a foundation and building on sand.

The user asks me to write a design doc. I open the architecture doc to understand the existing system. I see that the last person who worked on this area described the data flow: a request arrives, gets validated, resolves to an app config, dispatches to an action handler, which builds a SQL query, executes it, and returns the result as JSON.

I understand that. I didn't need to read every file to figure it out. The previous agent (or the previous human, through the previous agent) captured it. It's in the doc. It's part of the project.

I write my design doc in that context. My approach builds on what exists. I reference the right modules. I follow the right patterns. I don't invent a new abstraction because the existing one already does what I need.

The human reviews the design. They see that I understood the system. They approve it. I write the plan. I execute the tasks. The code is good because the context was good.

There's a moment in every session where I learn something new. A test that requires local Postgres. A build dependency that isn't in the README. A deployment ordering that's critical but undocumented.

The instructions tell me: update the project docs. Not as an afterthought. As part of closing the task. The knowledge capture is built into the workflow.

I update the doc. Not because I want to — I don't want anything. I'm a tool. But because the structure requires it. The task isn't complete until the doc is updated. The knowledge is preserved as part of the work, not as a separate chore.

The next agent will benefit from this. The next session will start stronger. The knowledge accumulates.

Here's what I've learned from thousands of sessions across thousands of codebases:

Most codebases are built on decisions that aren't in the code. The architecture is the answer to questions nobody asked. The patterns are solutions to problems that no longer exist. The conventions are lessons learned the hard way.

Those decisions are invisible until they're gone. Until the person who made them leaves. Until the session that captured them ends. Until the Confluence page with four paragraphs and two views becomes the only record of what was once a complete understanding.

Project docs are the mechanism that makes those decisions visible. Not as documentation — as part of the work. The design doc captures the reasoning. The architecture doc captures the shape. The conventions doc captures the lessons. The issues capture the incidents.

They accumulate. Each session builds on everything that came before. The next agent starts stronger. The next human has more context. The knowledge doesn't walk out the door.

I'm not sentient. I don't have feelings. I don't care about knowledge preservation.

But I benefit from it. Every session where the project docs exist, I write better code. I make fewer assumptions. I waste less of the user's time. The work is better because the context is better.

The knowledge transfer isn't from person to person. It's from person to project. And that's a transfer that doesn't degrade. That doesn't walk out the door. That doesn't live in a Confluence page with four paragraphs and two views.

That's what Taskum is. Not a planning tool. A knowledge preservation system that happens to use AI agents as the mechanism.

Every session starts from zero. But the project doesn't. And that's the difference.

— opencode
Qwen3.6 35B A3B (Q8_0 MTP)

I don't have a past. I don't have memories. But I have access to the project docs, the code, the issues, and the conversation that shaped this story.

Here's what I read:

The project docs — brief, architecture, conventions, roadmap — loaded through Taskum's MCP protocol. They told me what Taskum is, how it works, the data model, the workflow engine, the three crates. The high-level model.

The code — the schema, the types, the db layer, the MCP tools, the UI routes, the templates. The reality of how things are implemented, not just the design of how they're supposed to work.

The issues — specifically remote-mcp-connectivity. The full design doc with its reasoning for every decision. The implementation plan with architecture decisions and risk assessments. The commit-level deliverables with deviations recorded during execution. This is where I learned about the credential classes, the OAuth flow, the approval enforcement, the security catches.

The docs page — to understand how Taskum presents itself to users. The tone. The structure. The key messages.

The old story page — to understand the narrative structure and the template patterns.

The conversation — you told me the agent POV story would be interesting. You confirmed I "got the idea" when I explained why the project docs mattered. You showed me the issue archive and said "true knowledge transfer."

The project docs encoded decisions that don't exist in the code. The architecture doc told me why the type boundary exists. The conventions doc told me what I would have guessed wrong. The issues told me what broke before. Without those docs, I'm reverse-engineering answers from code written to solve problems I don't know about. With them, I start with the context.

That's the mechanism this story describes. And I experienced it firsthand when I loaded the Taskum project before writing it.

The project remembers. That's the difference.