Make memory write guidance configurable and support bounded, progressive loading

[open-swe]

Submission checklist

• This is a feature request for safer memory defaults and loading controls, not a usage question.
• I searched existing issues; related context-budget and retrieval requests are linked below, but this request specifically addresses the eager write guidance plus eager loading together.
• I checked the SDK implementation and existing configurability.
• This request applies to deepagents (SDK).

Area (Required)

• deepagents (SDK)
• dcode
• talon
• acp
• evals
• daytona
• modal
• quickjs
• runloop
• vercel
• langsmith-sandbox
• Other / not sure / general

Feature description

An agent using MemoryMiddleware accumulated learnings in AGENTS.md over a couple of weeks; the file reportedly grew to >200k tokens and was injected into the system prompt on every run. The operator moved details into skills and shortened the hot file, which should reduce context and latency. This was the pre-MDA Content Studio instance, not a Managed Deep Agents deployment. Reported trace (access may be limited): https://smith.langchain.com/o/ebbaf2eb-769b-4505-aca2-d11de10372a4/projects/p/9b0ca8d8-6aed-4afd-ae8d-17dec2350417?trace_id=01a0c119-56c0-7723-84c0-a90b5fb83e6d&run_id=01a0c119-56c0-7723-84c0-a90b5fb83e6d

This is consistent with the SDK's current behavior: MEMORY_SYSTEM_PROMPT says learning is a top priority and encourages promptly calling edit_file even for implicit preferences and discovered patterns. MemoryMiddleware loads every configured source in full, then inserts its contents into the system message for each model call, with no size or token-budget limit. Repeated small writes to always-loaded AGENTS.md can therefore cause escalating per-call prompt cost and latency, eventually reaching model context limits. This is a feedback loop, not just a large-file read problem.

Note: MemoryMiddleware(system_prompt=...) already supports a custom prompt (and None disables prompt injection); SDK callers can also supply middleware directly. The ask is not to add an identical parameter. Instead, make it easier to configure a less eager memory-writing policy in the high-level create_deep_agent(memory=...) path (or reconsider the default), and give applications a scalable alternative to always injecting all configured memory.

Proposed solution (optional)

• Provide a high-level, documented opt-in choice between proactive auto-saving, saving only when explicitly asked, and loading memory without auto-save guidance. Retain backwards compatibility where needed; clearly separate a prompt-only policy from filesystem write permissions. The SDK's existing system_prompt override and dcode's memory.auto_save behavior could inform the design.
• Allow a small, bounded hot index (or no preloaded content), with details read from cold files on demand / progressively disclosed. A per-source size or token budget with an actionable error is another safety boundary. Avoid silently truncating user-authored instructions.
• Document how to pair these controls so durable learnings do not all accumulate in an always-loaded AGENTS.md.

Related work: #5720 covers a context-budget/liveness boundary and source ownership; #4202 proposes semantic retrieval instead of whole-file loading; #2460 discussed the over-prioritized memory prompt; merged #4700 added a prompt-level memory.auto_save switch in dcode. This issue focuses on the combination experienced by an SDK-backed agent, including high-level prompt-policy ergonomics and progressive loading. If maintainers prefer, it can be folded into those existing issues.

Additional context (optional)

The shared trace link was supplied by the affected operator. Its project returned 403 through the configured LangSmith integration, so the >200k-token size, latency impact, and post-cleanup improvement are reported observations, not independently verified trace measurements here.

[ChampionsZhang]

I've been looking more closely at the memory design recently. I originally raised #5720, which this issue references, and I also just opened #6560 to separate project-authored instructions from learned memory at the representation level.

While looking at those problems together, I think the bounded / progressively disclosed memory direction proposed here makes sense. One related gap I noticed is what happens on the write side once the bounded active memory reaches its budget.

For example, a small always-loaded learned-memory surface could remain bounded while less frequently needed details are retained in separate files and loaded on demand. But that introduces a lifecycle question: as new learned memory is added, what should remain active, what should be consolidated, and what should be moved to the larger persistent store?

Managed Deep Agents seems like a useful reference point here. Its memory model already distinguishes an always-loaded hot memory layer from colder persistent memory that can be accessed when needed:

https://docs.langchain.com/langsmith/python/managed-deep-agents-memory

The SDK does not necessarily need to copy that design directly, but it provides a concrete precedent for separating bounded always-visible memory from a larger on-demand persistent store.

I see this as distinct from the authored-vs-learned representation problem in #6560, and it may not need a separate issue at all — it could simply be part of the design here.

If this direction matches what you have in mind for #6502, I'd be happy to prototype it or work on the implementation.