It turns out agents do not need smarter prompts as much as they need somewhere for the work to live.
Following up on my previous post: Built Correctly, Built Wrong
I went ahead and created the next version of that idea: next-desk.
The previous attempt, which I called control room, taught me a few things. Mainly: use less ceremony, get feedback earlier and more often, and pay more attention to the product than to the architecture around the product.
Was this new attempt perfect or straightforward? No.
It still went adrift at times. I still had to course-correct. But because I was getting feedback earlier, I noticed those problems sooner. And because there was less ceremony, getting back on track was easier.
The biggest lesson from this round is that I did not start with a clear enough product vision.
I had an idea of what I wanted, but not enough detail. So I started with something basic that made sense, then added the next thing that made sense, then the next one. Eventually I realized I was basically recreating Control Room.
At that point I started doubting the whole idea. Maybe it was not as useful as I thought. Maybe I was just building the same thing again with a different name.
After sitting with it for a while, I realized there was a real product idea in there. It just needed to be defined more clearly. Not as a pile of features, but as a direction.
Once I had that direction, future decisions became easier: does this move the product closer to what it is supposed to be, or is it just another thing that seems useful in isolation?
I remember removing something because it did not seem needed, then realizing later that I actually needed it for the product I wanted. That was annoying, but not fatal. One nice thing about working with agents is that small experiments are cheaper to recover from. You do not need to dwell on every wrong turn. You can revise, rebuild, or bring something back.
Task Memory
The product idea I ended up with is what I would call task memory.
Let me explain that through the problems it is trying to solve.
Do any of these sound familiar?
- An agent finishes running and you are not entirely sure what you originally asked it to do.
- You get stuck in a review / revise / review again / revise again loop and lose track of where things stand.
- A chat gets long enough that you forget what has been done and what is still pending.
- You have to choose between keeping one long session with too much context, or starting a new session and rebuilding all the context from scratch.
- You come back after a weekend and cannot remember where a task was left.
- You finish a task, move on, then later someone asks a question about it and the details are buried somewhere in a chat.
- You need to return to an old task, but first you have to reconstruct what happened, why it happened, and what the next step was supposed to be.
- You have too many chats or sessions that you are afraid to delete because they might contain something important.
Before agents, a lot of this context lived in people.
Decisions, assumptions, notes, and half-formed plans lived in the mind of the developer, the reviewer, or the team. That was not perfect, but the amount of work in flight was smaller and slower.
With agents, we can do more. That is the point. But doing more also means producing more intermediate state: more attempts, more reviews, more partial decisions, more generated files, more explanations, more "I tried this but not that."
And chat is not a great permanent home for that.
That is why I started thinking about next-desk as task memory.
The key questions are simple:
- What is this task?
- What has been done?
- What decisions were made?
- What evidence or proof exists?
- What is still pending?
- What context does the next agent, or future me, need in order to continue?
That is intentionally boring.
I did not want to build something fancy. I wanted something simple enough to be useful while I was actually working.
What It Helps With
The core value is not that it makes agents smarter.
It is that it gives the work a place to live outside the chat.
The task becomes the durable object, not the conversation. The conversation can come and go. The agent can change. The session can end. But the task should still have enough memory for someone to understand where it stands.
In practice, that means next-desk is useful when a task has more than a couple of steps.
If I am doing a tiny one-off change, it is probably not worth the ceremony. But once a task involves exploration, implementation, review, revision, screenshots, test output, or decisions that may matter later, task memory starts paying for itself.
It helps me answer:
- What did I ask the agent to do?
- What did it actually do?
- What did I review?
- What changed after review?
- What is the current state?
- What should happen next?
That sounds basic because it is basic.
But basic things become important when the workflow gets faster.
What I Learned About Agents
One thing I learned, or maybe re-learned, is that agents can appear to understand the direction without actually staying on track.
They may summarize your intent back to you. They may write files to guide themselves or future agents. They may say they understand the goal, agree with the constraints, and will follow the plan.
That does not mean they will.
You still need feedback loops. You still need checkpoints. You still need to verify that the work is moving toward the product you actually want, not just toward the next locally reasonable change.
This is especially true when you do not have a clear product definition. If the direction is vague, the agent will happily keep making progress in a direction. It just may not be your direction.
That was the uncomfortable part of this project.
The agent was not the only reason the work drifted. The work drifted because I had not defined the product clearly enough.
Agents make that problem more visible because they make it cheaper to move. But moving faster does not automatically mean moving better.
The Next Missing Piece: Project Memory
What I feel like I am missing now is one layer above task memory.
Project memory.
Task memory is about execution state. It is about a specific unit of work: status, summaries, decisions, evidence, receipts, next steps.
Project memory is different. It is about what the project is trying to become.
It is the product direction, use cases, constraints, non-goals, conventions, architectural decisions, open questions, and things we keep rediscovering because nobody wrote them down in a useful place.
If I were starting next-desk again, I would probably start there:
Project memory -> tasks -> task memory.
Not because I want to turn this into a Jira clone. I really do not.
What I want is something that helps create and maintain the boring documents that make work better: a product brief, a technical plan, a task breakdown, known constraints, maybe a lightweight roadmap.
The point is not that the agent makes those decisions for me. The point is that the agent can help me write them down, challenge them, update them, and keep them connected to the work.
Before agents, stories were often conversation starters. A ticket could be one line because the team would discuss it, shape it, and refine it together. The developer would make assumptions, ask questions, and discover more during implementation.
That still happens, but agent-assisted work changes the pressure. There are fewer natural pauses. There are fewer human conversations inside the implementation loop. A vague task can turn into a lot of code very quickly.
So I think we need to put more effort into specifying the boring parts upfront.
Not because process is fun. It is not.
Because vague direction plus fast execution is a good way to arrive somewhere you did not mean to go.
I recently read somewhere that the best prompt is boring in the places that matter. I agree with that.
I do not think the answer is smarter prompts. I think the answer is simple prompts linked to well-defined documents.
The big takeaway, for me, is that project management and software delivery did not stop mattering because agents got better.
Agents help you move faster.
They do not guarantee you are moving in the right direction.
Happy coding.