It turns out that writing down the direction is necessary, but not sufficient.
Following up on my previous posts: Built Correctly, Built Wrong and The Agent Said It Understood.
The first project taught me that a careful process can still produce the wrong product. The second taught me that agents need durable context outside the chat.
At the end of the second post, I thought the next missing piece was project memory.
I still think that was right.
It just was not the whole answer.
From Task Memory to Project Memory
Task memory answers questions about one piece of work:
- What are we doing?
- What has happened?
- What decisions were made?
- What is still pending?
- What should happen next?
Project memory sits above that. It records the direction that should remain true across tasks: what the product is trying to become, what it is not trying to become, important constraints, rejected ideas, architectural decisions, and how the work should be verified.
That distinction mattered because an agent could do a reasonable job on the task in front of it while slowly moving the project in a direction I had already rejected.
The agent was not necessarily ignoring an instruction. Sometimes the instruction only existed in an old conversation, or in my head.
So I experimented with a Project Memory skill. It helped create simple Markdown files for things like the product brief, requirements, constraints, non-goals, acceptance criteria, and verification expectations. The point was to make the direction explicit and keep it with the project, rather than leaving it in a chat or in my head.
I only used it briefly but, from what I could tell, it appeared to help the work stay closer to the recorded direction and made it less likely that already rejected ideas would return.
But it was not foolproof.
An agent can read a rule, summarize it correctly, and still fail to follow it later. A document gives the agent a better chance of staying aligned. It does not enforce itself.
That led to the next question: if the context is durable, how should the work itself be organized?
The Ticket Becomes a Delegation Contract
In teams I had worked in, a ticket could be a conversation starter. Sometimes it was barely more than a sentence.
That worked because the ticket was not carrying the entire requirement. Business analysts, QA engineers, architects, developers, and stakeholders brought shared context. Missing questions appeared during refinement, implementation, testing, and review. The team shaped the work as it went.
An agent does not automatically share that context.
If I ask it to carry a change through more of the delivery lifecycle, it will encounter many of the same questions. If the answers are missing, it may stop and ask.
Or it may make a locally reasonable assumption and turn it into code.
That changes what a task needs to contain. The ticket becomes something closer to a delegation contract: the objective, relevant context, constraints, non-goals, acceptance criteria, what the agent is allowed to decide, and what should make it stop.
This does not mean writing a giant specification for every change.
A small, familiar, easily reversible bug fix may need very little. A new feature, an unfamiliar codebase, a production change, or anything difficult to reverse needs more.
The assignment only needs to be complete enough for the responsibility being delegated now.
Agents can also help with discovery. They can ask questions, challenge an idea, explore the codebase, and help turn a vague need into a workable task.
But discovery and execution are not the same thing. The agent should not start carrying out the task before the direction and boundaries are clear enough.
One Workflow Does Not Fit Every Task
Next Desk worked well for the kind of work that led me to build it: long-running tasks, several things in flight, work without a ticket, and tasks I might park for days before returning to them.
It was too much for a small change.
I tried letting each task define its own workflow, but the product was still doing too much. The overhead was not just in the steps. It was in having a workflow system at all when the task did not need one.
That made me rethink what should be reusable.
The answer was not one comprehensive workflow. It was a small set of ways of working that could be selected according to the task.
A known bug might be:
- I fix it.
- An agent reviews the change.
A new feature might involve discovery, a written plan, human approval, implementation, tests, and an independent review.
A sensitive or difficult-to-reverse change might add explicit checkpoints before anything consequential happens.
The number of steps should depend on the uncertainty, risk, reversibility, and cost of being wrong.
Not on how much process I happen to have available.
Flexible Steps, Strict Rules
This is what led me to the Agent-Assisted Engineering Playbook.
The Playbook separates two things I had previously mixed together:
- The route through the work can change. Different tasks can use different plays, with more or fewer steps.
- Some rules do not change. If an agent is reviewing, it does not also change the code. If an important ambiguity appears, it stops. Review findings are advice until a human accepts them. The human owns the final result.
I think of the stable rules as something between a code of conduct and a manifesto for working with agents.
The task-specific flow is a play.
The current model has a few practical pieces:
- A project profile tells the agent how the repository works, where the important instructions live, what commands are safe to run, and what evidence is expected.
- A play defines the kind of work being done and the useful checkpoints for it.
- A kickoff comment makes the selected play, current step, boundaries, and next action durable at the task level.
- The repository and task record hold the context, rather than relying on one chat staying alive forever.
The point is not to make every task look the same.
It is to be flexible where the work is genuinely different and strict where a violated rule would undermine the result.
The Human Is Still the Control
One of my earlier mistakes was treating agent review as stronger evidence than it was.
One agent would do some work. Another would review it. The findings would go back to the first agent. The work would be revised and reviewed again.
The cycles became long, which meant I looked at the actual product less often. I also trusted review findings too blindly instead of treating them as opinions that still needed human judgment.
Adding another agent did not remove the need for a human decision. It just produced another output to evaluate.
The same applies to the Playbook.
I do not know that an agent will stay within the rules simply because I wrote them down. Tests and automated checks can enforce some boundaries. Separate review can expose others. Durable task state makes drift easier to see.
But none of those makes the agent accountable for the outcome.
I am.
That means I still have to inspect the final diff, test the real behavior, decide which review findings matter, reject invented requirements, and check that the result belongs in the product.
The Playbook does not replace that responsibility. It makes the responsibility harder to lose inside a fast-moving conversation.
What I Know So Far
The honest limitation is that the Playbook has one consuming project so far: Engineering Reference.
In that project, it has been useful. It keeps project direction and task state durable. It lets the workflow adapt to the task. It makes the agent and human roles more explicit. And it gives me a way to say which rules are optional and which are not.
That is encouraging, but it is not proof that I have solved agent-assisted engineering.
I have not.
What I have is a better experiment.
Looking back, the progression has been fairly simple:
Prompt engineering → context management → workflow.
And the current version of the lesson is simpler still:
Clear task. Clear product direction. Human verification.
Agents can make the work move much faster. The job is to make sure the judgment, context, and controls move with it.
Happy coding.