Overriding / Disable Default Deep Agents Middleware, Example + Community Thoughts

[vivek (vtrivedy)]

Hey all, we've gotten some requests about customizing/replacing the built-in middlewares in Deep Agents. Starting this discussion to hear the community's overall thoughts! Sharing a snippet to override in the meantime if you say wanted to roll your own summarization.

NOTE
The updated version of overriding as of deepagents 0.4.0 is below. The middleware is private because we anticipate changing the interface, which will cause workarounds like these to change again.

NEW, USE THIS IF NEEDED

from deepagents import graph
from langchain.agents.middleware.types import AgentMiddleware


class CustomSummarizationMiddleware(AgentMiddleware):

    def __init__(self, model, **kwargs):
        pass

    def wrap_model_call(self, request, handler):
        raise AssertionError


graph.SummarizationMiddleware = CustomSummarizationMiddleware


from deepagents import create_deep_agent

agent = create_deep_agent(model="anthropic:claude-haiku-4-5")
agent.invoke({"messages": [{"role": "user", "content": "Testing"}]})  # AssertionError

OLD DO NOT USE:

from langchain.agents.middleware import summarization
from langchain.agents.middleware.types import AgentMiddleware

  class CustomSummarizationMiddleware(AgentMiddleware):
      def __init__(self, model, **kwargs): ...
      def before_model(self, state, runtime): ...
      async def abefore_model(self, state, runtime): ...

  # Monkey-patch BEFORE importing create_deep_agent
  summarization.SummarizationMiddleware = CustomSummarizationMiddleware

  from deepagents import create_deep_agent
  agent = create_deep_agent(...)

[Brett Gardner (brettgardner21)]

Do you have a recommended approach to removing middleware from deep agents or sub agents? Right now, if you pass the middleware argument as empty [] with main or subagents, it treats it as additive. The default middleware is still included (todos, summarization, filesystem) instead of allowing control over what middleware is included.

[joshb1050]

Centralizing my comment from #943, adding a +1 to Brett Gardner (@brettgardner21) and vivek (@vtrivedy):

One thing I want to emphasize is that configurability here isn’t about forcing users to tune things by default. Deepagents can (and should) work sensibly out of the box for most people.

The concern is that without any ability to customize, e.g. disabling middleware, changing the inputs to summarization, or swapping the prompt, advanced users quickly hit a ceiling. At that point, the path of least resistance is often to abandon deepagents entirely and go back to a more explicit ReAct-style agent where these decisions are controllable.

The fact that middleware exists at all implies this is intended to be a tunable framework. Given that, I think it’s reasonable to expect some level of granular configurability rather than treating middleware as fixed policy.

From my perspective, exposing these hooks preserves deepagents as a flexible abstraction rather than a closed one, without harming the default experience. This is explicitly an optional feature so that most users do not need to configure it.

[Brett Gardner (brettgardner21)]

joshb1050 vivek (@vtrivedy) Here is a specific use case, and why the current design is a big problem. We recently hit a wall with the deepagent harness for a standard multi-agent use case:

Use Case:

• Main Agent: Acts purely as a planner and task orchestrator.
• Sub-agents (x2): Responsible for single-responsibility tasks using specific tool subsets.

The Problem:
Right now, the ToDos and Filesystem middleware are being injected into every sub-agent by default. This adds 7 unnecessary tools and roughly 260–280 tokens to every prompt. For sub-agents that don't need to plan or touch the filesystem, this causes:

• Increased Latency and Cost: Slower inference due to bloated context.
• Agent Confusion: Sub-agents are attempting to plan unnecessarily or use filesystem tools for simple queries instead of the tools specified in the sub-agent prompt, leading to unexpected behavior and hallucinated paths.

Without the ability to override or disable these, using the harness for even a simple "1 Main, 2 Sub-agents" architecture was a non-starter. We had to pivot back to create_agent and manually implement the middleware/graph logic just to regain control over the sub-agent environments. Granular control is essential for keeping specialized agents "on the rails."

[Albert M (amavashev)]

Your example highlights something broader: in multi-agent setups the cost surface is the sum of every sub-agent's context, multiplied by concurrency. Trimming unnecessary middleware per sub-agent is the right move for token efficiency.

The next layer is enforcing a budget ceiling across all of them before they run — so a shared budget can't be overdrawn by concurrent sub-agents that both checked the balance and both saw "enough."

I built exactly that as a middleware-compatible open protocol:
https://runcycles.io/ — the before_tool_call / after_tool_call hooks are the natural integration points.

[Islam Bassuni (bassuniz)]

Any new thoughts on this ?

[Mason Daugherty (mdrxy)]

Update for everyone watching this thread: as of deepagents 0.5.4, there is now a first-class, supported way to do this — no more graph.SummarizationMiddleware = ... monkey-patching. The new API is the profiles system landed in #2892.

There are two extension points, both keyed by "provider" or full "provider:model":

• ProviderProfile — shapes how resolve_model builds the client (init_chat_model kwargs, pre-init checks, env-derived headers).
• HarnessProfile — shapes how create_deep_agent assembles the agent: base_system_prompt, system_prompt_suffix, excluded_tools, tool_descriptions, extra_middleware, excluded_middleware, and a GeneralPurposeSubagentProfile for disabling/renaming/re-prompting the auto-added general-purpose subagent.

Registrations are additive — re-registering under the same key merges on top — and there is a declarative HarnessProfileConfig for YAML/JSON-backed profiles, plus deepagents.provider_profiles / deepagents.harness_profiles entry points for plugin authors.

Replacing the original monkey-patch

The "custom summarization" listed above from vivek (@vtrivedy) example becomes:

from deepagents import (
    HarnessProfile,
    create_deep_agent,
    register_harness_profile,
)
from langchain.agents.middleware.types import AgentMiddleware


class CustomSummarizationMiddleware(AgentMiddleware):
    name = "SummarizationMiddleware"  # match by name to displace the built-in

    def wrap_model_call(self, request, handler):
        ...


register_harness_profile(
    "anthropic:claude-opus-4-7",
    HarnessProfile(
        excluded_middleware=frozenset({"SummarizationMiddleware"}),
        extra_middleware=[CustomSummarizationMiddleware()],
    ),
)

agent = create_deep_agent(model="anthropic:claude-opus-4-7")

Multi-agent case

cc Brett Gardner (@brettgardner21)

Profiles resolve per selected model, including for subagents — so if your two specialized subagents run on a different model (or even the same one) and don't need the planner/filesystem stack, you can register a profile that strips them:

from deepagents import HarnessProfile, register_harness_profile

register_harness_profile(
    "openai:gpt-5.5",  # whatever your subagents resolve to
    HarnessProfile(
        excluded_middleware=frozenset({
            "TodoListMiddleware",
            "FilesystemMiddleware",
            "SummarizationMiddleware",
        }),
    ),
)

A few guardrails worth knowing about:

• Load-bearing scaffolding (SubAgentMiddleware, _PermissionMiddleware, and yes FilesystemMiddleware itself, since several other pieces depend on it) cannot be excluded — the harness raises ValueError at assembly time rather than silently producing a broken agent. If you hit that wall and the use case is legitimate, please open an issue with the shape of the agent you're trying to build; that's the signal we need to revisit which middleware is truly load-bearing.
• Every exclusion must match at least one assembled middleware — typos fail loudly.
• Profile keys are deliberately narrow today (provider or provider:model). For "applies to every agent regardless of model," create_deep_agent(middleware=..., system_prompt=…, tools=…) still apply unconditionally — and we're actively working on a follow-up that lets you shape the harness without having to key by provider or model at all, so model-agnostic overrides won't have to go through the call site forever. Specific shapes / use cases that profiles' provider-or-model keying makes awkward today are very welcome on this thread — they directly inform that design.

On the broader framing

cc joshb1050

Agreed with the framing — defaults stay sensible out of the box, and customization is opt-in through a typed, supported surface rather than reaching into private modules. The previous graph.SummarizationMiddleware = ... workaround in the OP can now be considered deprecated.

Full field surface, merge semantics, and plugin packaging live in the profiles documentation. Curious to hear what people land on once they've ported their existing overrides over — happy to keep iterating.

[Segev Finer (segevfiner)]

This currently registers globally based on the specific model name, what if I want to use different customized agents all based on the same base model, or have a profile that should only be used for a specific case? It doesn't seem possible with the current API...

[Mason Daugherty (mdrxy)]

That's on the roadmap -- correct that there is no wildcard (yet)