A prompt is enough until the work has to survive replanning, handoffs, recovery, and independent acceptance.The shape can change without changing what counts. (Image generated by author using AI - ChatGPT)The prompt can still be sitting at the top of the transcript, unchanged, while the job it…
Annons
Annons
A prompt is enough until the work has to survive replanning, handoffs, recovery, and independent acceptance.The shape can change without changing what counts. (Image generated by author using AI - ChatGPT)The prompt can still be sitting at the top of the transcript, unchanged, while the job it started has already become something else.That is the awkward part.The first instruction may have been perfectly clear. Then the work crosses into another session. A constraint changes. The plan gets revised. Another agent handles a later phase. A reviewer eventually has to decide whether the result is merely plausible or whether it still satisfies what the work was supposed to become.Nothing about that sequence means the original prompt was bad. It means the prompt has stopped being enough to govern the job.At that point, I care less about making the prompt longer and more about a different question:What is allowed to define the work now?A conversation is good at carrying instruction in the moment. Long-running agent work eventually needs something else:A current reference that can survive after the moment has passed.That is the useful role of a specification.The problem appears when the work develops memoryA transcript is excellent at preserving chronology.It can tell a later reader what was asked first, what the agent proposed, what changed, and which correction came next. In a long enough run, it may contain every decision that matters.That does not mean it contains a usable current contract.If a later participant has to reconstruct which instruction superseded which earlier instruction, which constraints are still active, what is deliberately out of scope, and how the result will be judged, the history exists, but the authority is scattered through it.The workflow has become stateful in practice while remaining stateless in authority.This is the point where “just keep the context” stops being the whole answer. More context can preserve more history. It does not automatically tell the next executor which parts of that history are allowed to govern the next action.A durable specification is useful because it can do something a transcript does badly: represent the present job.Three reasons to graduate the promptI would not create a specification for every agent task. Most tasks do not deserve the ceremony.The threshold starts to make sense when at least one of three things becomes important.1. The job will be interpreted more than onceOne session with one human close to the work can tolerate a lot of conversational state. Drift is visible quickly, and corrections can stay local.The risk changes when the job crosses sessions, context compaction, restarts, models, executors, or reviewers.Now several participants may be competent while holding slightly different versions of the assignment. Each has seen a different slice of the history. Each can make a reasonable local decision. The collection of those reasonable decisions can still move the job away from its intended target.A shared specification does not eliminate disagreement; it just gives disagreement somewhere visible to happen.Instead of asking whether everyone reconstructed the same conversation, the workflow can ask whether the proposed action is compatible with the same current target, constraints, and boundaries.That is a much more useful coordination surface.2. The rules will change while the job continuesLong-running work replans.Implementation reveals an awkward dependency. A requirement changes. An approach that looked sensible in the first hour becomes expensive in the fifth. A new constraint arrives after part of the work already exists.None of that is exceptional.The problem begins when every revision arrives as another conversational patch while the earlier instructions remain equally visible.A current specification needs some way to represent supersession. That can be version control, explicit amendments, a current-state section, or another inspectable revision mechanism. The exact format matters less than the result:A later participant should be able to distinguish current intent from historical intent without guessing.A spec that cannot absorb replanning is not a durable contract. It is a fossil.3. Acceptance and recovery need an independent referenceGeneration and acceptance are easy to blur in an agent loop.The same system can help define the work, perform the work, generate the tests, and explain why the result should count as successful. That chain can become internally consistent while moving away from the original need.A durable contract gives acceptance some distance from generation.It should remain possible to ask two separate questions:Did the implementation satisfy the checks?Do those checks still represent the intended outcome?Recovery creates a similar need.When a session ends, a branch is abandoned, or another participant resumes a partially completed job, the goal should not be to reconstruct the entire conversational history before making the next decision. The next participant needs the current target, active constraints, unresolved questions, relevant plan state, and acceptance conditions.The more expensive a wrong restart would be, the more valuable that current reference becomes.A useful specification has four jobsThe word specification can make this sound heavier than it needs to be.The artifact does not have to be enormous. It does not need a special framework. A Markdown file under version control may be enough.What matters is whether it can perform four jobs:Keep the current target and boundaries visible. The reader should be able to tell what outcome is required, which constraints still apply, what is deliberately excluded, and which decisions are not controlled by this artifact.Absorb revision without hiding history. When the plan changes, the governing state should change too. The artifact needs to distinguish superseded decisions from current ones rather than accumulating detached exceptions.Preserve acceptance. The work needs a reference for how completion will be judged that is not silently rewritten around whatever the implementation happened to produce.Remain addressable and recoverable. Humans and agents should know which artifact is current, be able to inspect it, and resume from it without conversational archaeology.Persistence is only one part of this. A file can survive for years and still be useless if nobody knows whether it is current.Current spec-driven workflows make the distinction concreteThe recent wave of spec-driven development tools is useful because it gives this abstract authority problem a visible shape.DeepLearning.AI’s Spec-Driven Development with Coding Agents, built with JetBrains, teaches project constitutions and feature specifications as a way to preserve context across agent sessions and support a plan, implement, verify, and replan workflow.Its official companion repository separates project-level material such as mission, technology, and roadmap from feature-level plan, requirements, and validation artifacts.GitHub’s public Spec Kit framing similarly describes specifications as living sources of truth that evolve with the project.I would not treat any of those structures as a mandatory schema for agent work.The useful part is the shared direction:The governing artifact is expected to live with the work, absorb change, and stay connected to planning and validation.That is very different from writing a larger prompt once and keeping it around forever.The specification can become the problem tooThere is an obvious failure mode here.A team can write a file, call it a specification, and assume the authority problem is solved. It is not.A specification can go stale. It can preserve generated assumptions nobody approved. It can become so large that nobody can tell which parts matter. It can contain an obsolete plan while newer instructions live somewhere else. It can turn a simple task into a documentation system that costs more to maintain than the ambiguity it was supposed to remove.There is also a timing problem.Some work is exploratory because the target is not settled yet. The team may be comparing approaches, discovering constraints, or figuring out which question is worth solving.Writing uncertainty into an authoritative document does not remove the uncertainty. It can give the first plausible guess more weight than it deserves.Sometimes the better sequence is:Explore → reduce uncertainty → specify what is stable enough to govern → implement → replan when evidence changes the contractThe goal is not to turn discovery into compliance, but to make the decisions that are ready to govern durable enough to survive the work.Use the lightest authority that can survive the jobI find it more useful to think of this as an escalation ladder than as a binary choice between “prompting” and “spec-driven development.”Use a prompt when the task is local, reversible, easy to inspect, and unlikely to outlive the conversation that defines it.Persist the outcome and constraints when the task may outlive the session but does not need much replanning or distributed interpretation.Use a versioned specification when the work will cross sessions, change while it runs, or move between multiple executors and reviewers.Keep acceptance separable from generation when the cost of a self-consistent but wrong result is high enough that the implementation should not be allowed to redefine success around itself.The artifact can stay small at every level. The important thing is that its authority matches the lifetime of the work.The decision ruleThe practical test I would use is this:Will someone need to make a consequential decision about this work after the original conversational context is no longer sufficient?If the answer is no, a prompt may be enough. If the answer is yes, persist the part that must still be true when the conversation is gone.That may be the desired outcome. It may be the active constraints. It may be the current decisions and how revisions supersede them. It may be the acceptance criteria. It may be enough recovery state for the next session to resume without rebuilding intent from history.The specification earns its place by remaining trustworthy after the prompt that started the work has stopped being sufficient.From Dream Atlas: The Spec Outlived the Prompt — the original log behind this article.I’m continuing to write about AI workflows, product work, and what I’m learning as I build, test, and tinker. If that sounds useful, follow me here on Medium. And if this piece earned a clap, I’d appreciate it ✨This story is published under the Generative AI publication. Connect with us on LinkedIn and follow Zeniteq to stay in the loop with the latest AI stories. Let’s shape the future of AI together!When an Agent Task Needs More Than a Prompt was originally published in Generative AI on Medium, where people are continuing the conversation by highlighting and responding to this story.