Overriding 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."