The system prompt, and what v0.7 took away
One parameter, one legacy name that will not die, and one release note that quietly changed what the parameter is responsible for.
The parameter is system_prompt
What v0.7 changed, and why it matters more than it reads
The v0.7 release notes list, among other things: base system prompt now empty, tool descriptions trimmed by roughly 43 percent, base input tokens down roughly 65 percent.
Read as a changelog that is a performance win and nothing else. Read as behaviour, it is a shift in who is responsible for instructing the agent.
Through v0.6, the harness shipped its own base prompt. Your system_prompt sat alongside it, and a terse one still produced a competent agent, because the framework was quietly supplying the framing: how to use the filesystem, when to plan, how to behave with tools. You could write one sentence and get structured behaviour, and it was easy to believe your sentence had done that.
From v0.7, the harness contributes nothing. Your system_prompt is the entire instruction surface.
That is the same trade the whole library keeps making. Defaults that did work for you, moved out into the open where you have to ask for them. write_todos went the same way in the same release, and for the same reason.
The prompt is not the only instruction channel
Worth holding as an architectural reading rather than a quoted rule, because it explains a family of questions that look like they are about prompting and are actually about placement.
Three things are present in context before the user has said anything:
- The system prompt. What you typed.
- Always-loaded memory. Every file passed as
memory=[...], in full, on every run. - Skill metadata. The name and description of every registered skill, loaded at startup so the agent knows what it could reach for.
All three are unconditional. None of them is the “prompt” parameter, and two of them are configured somewhere else entirely.
So the real question when you are deciding where a piece of instruction goes is not how do I word this, it is which channel should carry it and what does that channel cost. Module 3 is that question asked properly, with the cost model attached.
The practical consequence of an empty base
If you inherited an agent written against v0.6 and it starts behaving loosely after an upgrade, the first thing to check is not your prompt wording. It is whether your prompt was ever doing the work you thought it was.
That is a genuinely useful diagnostic instinct and it generalises well beyond this library: when a default disappears, the code that relied on it does not break, it degrades. Nothing throws. It just gets worse, quietly, in a way that reads as model drift.
Try it yourself
The parameter that does not exist
One of these is not a parameter. It is the most natural distractor anybody could write, because it used to be real and half the internet still types it.
Show answer
Correct answer: D — prompt
There is no prompt parameter. The instruction string goes in system_prompt. prompt was the legacy name and it survives in tutorials, blog posts and probably your muscle memory, which is exactly what makes it the trap rather than a lazy distractor. The other three are all real parameters on the create_agent surface that create_deep_agent inherits.
The empty base prompt
A currency fact with a behavioural consequence, which is a better thing to hold than the fact on its own.
What did deepagents v0.7 change about the base system prompt, and what does that mean for an agent whose own system_prompt is short?
Reveal answer
The base system prompt is now empty. Through v0.6 the harness contributed its own instruction text that sat alongside yours, so a terse system_prompt still produced a competently behaved agent because the harness was filling in the framing. From v0.7 the harness contributes nothing, so your system_prompt is the entire instruction surface and a terse one is genuinely terse. The related savings are tool descriptions trimmed by roughly 43 percent and base input tokens down roughly 65 percent.
Predict the upgrade
An agent is running happily on v0.6 with this configuration. The team upgrades to v0.7 and changes nothing else.
agent = create_deep_agent(
model=model,
tools=[search],
system_prompt="Answer the user's question.",
)Show answer
Correct answer: B — Instruction context shrinks and the agent may become noticeably less structured
The harness used to contribute a base prompt and now contributes none, so total instruction context drops and a one-line system_prompt is suddenly carrying the whole load. The last option is the tempting one because less context genuinely does help in many situations, and the v0.7 notes lead with token savings, which frames the change as pure improvement. It is a saving with a cost attached, and the cost lands on anyone who was relying on the default framing without knowing it.
Which channel carries it
A rule must apply on every single run, no matter what the user asks. Where does it belong?
Show answer
Correct answer: A — Always-loaded memory or the system prompt, since both are always present
Both the system prompt and always-loaded memory are unconditionally present, so either satisfies an always-applies rule, and the choice between them is about where the material is easiest to maintain. A skill is the strong distractor because skills genuinely are the reusable-instruction mechanism, but a skill only loads when something invokes it, so a rule that must apply unprompted would routinely never load at all. The reading that memory and the system prompt are equivalent channels for this purpose follows from how each is described, rather than from a rule stated in those terms.
Audit a terse prompt
Take any agent you have written, in any language, and read its system prompt as if the harness contributed nothing.
You can name at least one behaviour you were implicitly relying on the framework to supply, and you decided whether it belongs in the system prompt or in always-loaded memory.