Running the Template Without Losing Control

The Template Meets Real Work

The template looks controlled before implementation starts.

The outcome is written. The boundaries are visible. The tradeoffs have a place. The acceptance criteria define what should pass. The task is small enough to begin.

Then the agent starts working.

It discovers an existing API that doesn't match the design. A type check fails in code outside the expected files. One acceptance criterion depends on a business rule nobody wrote down. The conversation fills with logs, patches, and new decisions.

This is where a good template can still become an unmanaged implementation.

The problem is not that the original spec was useless. The problem is that implementation creates new information, and the workflow needs to control what happens next.

The agent needs to know what it can fix, what should stop the work, and what must go back into the spec before implementation continues.

That operating discipline is what keeps one approved slice from turning into another long conversation that nobody fully controls.

Keep the Slice Inside Its Boundary

A small task can expand quietly.

The agent starts with request submission, then discovers that the response model is incomplete. It updates the API, changes the shared types, adjusts the review queue, and starts fixing unrelated tests.

Each change may look reasonable on its own. Together, they create a different slice.

The warning is not the number of files. It is the number of new decisions entering the work.

If the agent can complete the expected behavior within the existing boundaries, it should continue. If it discovers a missing rule, a conflicting design choice, or work that belongs to another feature, it should stop and make that expansion visible.

The next step might be to update the spec, split a follow-up task, or reconsider the current slice.

The task should grow only when the engineer accepts the reason it needs to grow.

This keeps implementation focused without forcing the agent to ignore problems it discovers.

Make the Checks Control the Work

Running checks is not enough.

An agent can run a test, report that it failed, and continue changing other parts of the slice. The check exists, but it has no authority over the work.

Backpressure starts when a failed check changes what the agent is allowed to do next.

A type error should stop code that cannot compile. A failed acceptance scenario should stop the slice from being called complete. A browser failure should challenge a backend-only result that looked correct from the API.

Not every failure means the same thing. Some failures expose an implementation bug. Others reveal that the expected behavior, design, and existing system disagree.

The agent can fix the first kind within the approved slice. The second kind needs an engineering decision before more code is written.

A check should not only report the state of the code. It should decide whether the workflow can move forward.

Decide What Needs to Change

When a check fails, changing the code is only one possible response.

If the implementation violates an acceptance criterion, the code should change.

If the criterion no longer represents the intended behavior, the spec should change first.

If the check is asserting the wrong behavior, the check should change.

The dangerous response is to edit whichever one makes the failure disappear fastest.

For the training-request slice, suppose another colleague can open a request they don't own. The acceptance criterion is clear, so the implementation is wrong.

But suppose Office Management cannot review a request until a reviewer is assigned, and the spec never defined that rule. The agent should not invent the workflow inside the code just to satisfy the test.

A failed check sometimes exposes a bug. Sometimes it exposes a decision that was never made.

Before fixing the failure, identify whether the correction belongs in the code, the check, or the spec.

Keep Progress Outside the Conversation

During implementation, the conversation contains two kinds of useful information.

Some discoveries change the system: a business rule becomes clearer, a design constraint appears, or a tradeoff needs to be accepted. Those belong in requirements.md or design.md.

Other information describes the current execution: which task is complete, which check still fails, and what remains before the slice can close. That belongs in tasks.md or a small progress log.

If both stay only in the chat, the workflow depends on the chat remembering itself.

The agent should write back when the state changes, not only when the entire slice is finished.

This gives the next session a reliable restart point. It can see what was decided, what was completed, and what is still blocked without reconstructing the work from a long conversation.

The conversation helps perform the work. The project files preserve its state.

Rebuild Context From Project State

A long conversation can feel safer because it contains everything that happened.

It also contains abandoned ideas, outdated assumptions, repeated logs, and fixes that no longer matter.

Context is useful because it is relevant, not because it is complete.

When the conversation becomes harder to follow, I would rather start a clean session from the current project state than keep compressing the full history.

The agent needs the active requirements, relevant design decisions, current task, changed files, and checks that still control completion. It does not need every prompt that produced them.

This works only if decisions and progress were written back while the work was happening. Otherwise, starting fresh means losing information.

Durable project memory lets us replace a large conversation with a smaller, more accurate context.

Add Agents Only When the Work Can Be Separated

More agents do not automatically create more progress.

If two agents need to edit the same files, interpret the same missing rule, or depend on decisions that are still changing, parallel work adds coordination before it adds speed.

Sub-agents help when the boundaries are already clear.

One agent might implement the backend contract while another prepares independent verification. One might inspect an existing integration while the main agent continues work that does not depend on its result.

If ownership overlaps, the parent task becomes conflict resolution instead of implementation.

The work still needs one place where results are reconciled, checks are run, and the final state is written back.

Use another agent when the task can be separated by files, responsibility, and proof. Otherwise, keep the context with one agent.

Control Comes From Stop Points

The agent does not lose direction only because the prompt was weak.

It loses direction when the workflow gives it no reason to pause.

A boundary change should pause the task. A missing decision should pause implementation. A failed acceptance scenario should block completion. A larger context should be rebuilt from the project state instead of carried forward by habit.

Control does not mean approving every line of code. It means deciding which conditions allow the work to continue.

The template provides the intent, boundaries, tradeoffs, proof, and memory. The runtime discipline makes those decisions active while the code is changing.

That is what turns the spec from documentation into an operating system for agent work.

The next step is to package this workflow into files and commands that can be reused in a real project.

That is what the Spec-Driven AI-Assisted Development Starter Kit will provide.