惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

酷 壳 – CoolShell
酷 壳 – CoolShell
G
Google Developers Blog
V
V2EX
美团技术团队
H
Help Net Security
月光博客
月光博客
爱范儿
爱范儿
Engineering at Meta
Engineering at Meta
The Cloudflare Blog
U
Unit 42
大猫的无限游戏
大猫的无限游戏
Recent Announcements
Recent Announcements
A
About on SuperTechFans
博客园 - Franky
The GitHub Blog
The GitHub Blog
N
Netflix TechBlog - Medium
人人都是产品经理
人人都是产品经理
博客园 - 司徒正美
MyScale Blog
MyScale Blog
B
Blog
雷峰网
雷峰网
Y
Y Combinator Blog
云风的 BLOG
云风的 BLOG
T
The Blog of Author Tim Ferriss

LangChain Forum - Latest topics

Seeking help regarding the connection between Websocket and tool calls Tool invocation error with empty error message when using `InjectedState` + `Command` return in async tool How to use @langchain/react FileSystem middleware Using ChatSnowflake with agents Built llmsessioncontract on AgentMiddleware: runtime enforcement of tool-call protocols — feedback wanted DeltaChannelHistory not found in langgraph-api:3.12 Improving citation accuracy and reducing hallucinations in custom Parent-Child RAG pipeline (Gemma3:4B + FAISS+BM25 + Cross-encoder reranker) Built a live autonomous AI agent network using LangGraph-style economics — looking for feedback How are you validating LangChain agent output before it executes shell commands? Cross-site pattern pool for production agent failures — looking for 5 pilot teams (open spec, CC-BY-4.0) Metadata filter not filtering for alerts Using custom MCP servers with assistants How to use tool calling using ChatLlamaCpp and Gemma 4 E4B with create_agent? CLI - No Longer Sending traces to Langsmith Connecting the Slack integration fails with invalid_team_for_non_distributed_app The Docs says open router can be used with init_chat_model but throws an error Interested to contribute to langgraph postgre checkpointer for multiple adapter support Modal Inference Trouble understanding and editing experiment summary evaluators feedbacks SSL certificate error from httpx with LangGraph server [Feature Request] Wire allowed_msgpack_modules in langgraph.json Serving an agent with the LangGraph CLI dev command Proposal: implement delete_for_runs for SQLite checkpoint savers WikipediaLoader endup in JSONDecodeError Human-in-the-loop approval dashboard for LangGraph agents — open source, free to deploy Ombre — open source security and audit layer for LangChain apps Should interrupt() be split into two primitives — one for human input, one for s2s data fetching? Unable to delete runs from annotation queue First Bedrock call after idle is slow on TTFT (follow-ups in the same trace are fast)
Multiple response formats when creating agents?
@pawel-tward · 2026-04-19 · via LangChain Forum - Latest topics

April 17, 2026, 9:32am 1

It seems like when creating agents using create_agent() it is only possible to give the agent a single response format.

For my specific project, I would like my agent to respond in different formats depending on the situation.
Currently I achieve this by using seperate create_agent() instances, but this doesn’t feel very satisfactory.

Is there some way I can have a single agent, that is capable of following multiple response formats?
Or any ideas to achieve a similar effect without multiple create_agent() instances?

hi @Bergholdt

I think you don’t need multiple agent instances. create_agent’s response_format accepts one strategy object, but that object can wrap many schemas. Three patterns:

  1. ToolStrategy(Union[A, B, …]) - model picks the right schema per run. This is the documented, intended solution. Each union arm becomes a separate artificial structured-output tool (see _iter_variants in langchain/agents/structured_output.py).
  2. JSON Schema oneOf - same mechanism at the schema level if you’re not using Pydantic.
  3. wrap_model_call middleware that overwrites request.response_format - if you (not the model) decide the format based on runtime context, state, or the latest message. ModelRequest.response_format is a writable field, so one agent can dispatch to N formats per invocation.

Caveat: only ToolStrategy expands unions. ProviderStrategy / AutoStrategy take a single schema, so to get provider-native validation you must pick one variant (option 3 is how).

1 Like

Hi @pawel-twardziak
Thanks for the reply!

It is indeed me that decides the format. I know the format I want beforehand.
So if I understand you right I could create a wrap_model_call middleware that directly changes the response_format of the agent?
So it does something like this?:
def wrap_model_call(request, handler):
request.response_format = insert_current_format_here
return handler(request)

yes - that exact pattern works, with one important caveat about ToolStrategy that the docs don’t spell out.

What the source code actually does after your middleware runs

After wrap_model_call fires, _get_bound_model re-reads request.response_format (langchain/agents/factory.py:1198) and rebuilds the bound model from it. So mutating request.response_format inside the handler is enough - no other plumbing is required.

Caveat: ToolStrategy swaps must be a subset of the upfront declaration

This is buried in the factory but it will bite you if you don’t know it. When the final (post-middleware) format is a ToolStrategy, the factory validates that every schema variant was declared when the agent was built:

# sources/langchain/libs/langchain_v1/langchain/agents/factory.py
# Middleware is allowed to change the response format
# to a subset of the original structured tools when using ToolStrategy,
# but not to add new structured tools that weren't declared upfront.
for tc in effective_response_format.schema_specs:
    if tc.name not in structured_output_tools:
        msg = (
            f"ToolStrategy specifies tool '{tc.name}' "
            "which wasn't declared in the original "
            "response format when creating the agent."
        )
        raise ValueError(msg)

Concretely:

  • If you built the agent with response_format=ToolStrategy(A) and the middleware swaps in ToolStrategy(B), you get ValueError - B wasn’t declared up front.
  • The fix: declare the superset as a Union at construction time, and let the middleware pick one variant per invocation.
  • This check does not apply to ProviderStrategy. If you swap to ProviderStrategy(X) where the model supports native structured output, the new schema is accepted without the upfront-declaration requirement.

The full pattern for a predetermined, per-invocation format

Since you said you already know which format you want at call time, pass it via context_schema - that’s the read-only per-invocation channel the middleware docs recommend, and it’s exactly what runtime.context is for (see docs/src/oss/langchain/context-engineering.mdx):

from dataclasses import dataclass
from typing import Callable, Union

from pydantic import BaseModel
from langchain.agents import create_agent
from langchain.agents.middleware import wrap_model_call, ModelRequest, ModelResponse
from langchain.agents.structured_output import ToolStrategy


class ProductReview(BaseModel): ...
class CustomerComplaint(BaseModel): ...
class SupportTicket(BaseModel): ...

SCHEMAS = {
    "review": ProductReview,
    "complaint": CustomerComplaint,
    "ticket": SupportTicket,
}


@dataclass
class Context:
    response_format_key: str  # predetermined by the caller


@wrap_model_call
def select_format(
    request: ModelRequest,
    handler: Callable[[ModelRequest], ModelResponse],
) -> ModelResponse:
    key = request.runtime.context.response_format_key
    request.response_format = ToolStrategy(SCHEMAS[key])  # subset of the Union
    return handler(request)


agent = create_agent(
    model="gpt-5",
    tools=tools,
    # Declare the superset upfront so the subset swap above is always valid.
    response_format=ToolStrategy(Union[ProductReview, CustomerComplaint, SupportTicket]),
    middleware=[select_format],
    context_schema=Context,
)

agent.invoke(
    {"messages": [...]},
    context=Context(response_format_key="complaint"),
)

Why this shape:

  1. The Union on create_agent pre-registers every tool that any invocation might need - that clears the factory’s subset check.
  2. context_schema is the right carrier for “the caller already decided”: it’s read-only, per-invocation, and doesn’t pollute state.
  3. wrap_model_call runs once per model step, so retries inside the same invoke keep the format you picked.

If instead you want to skip the Union gymnastics and your model has native structured output, swap to ProviderStrategy(SCHEMAS[key]) in the middleware - no upfront declaration needed, though you lose the Union fallback for providers without native support.

Sources

  • Source (git repo): langchain/libs/langchain_v1/langchain/agents/factory.py
    lines ~1196–1255 - response_format re-read after middleware, and the ToolStrategy subset validation.
  • Source (git repo): langchain/libs/langchain_v1/langchain/agents/middleware/types.py
    • ModelRequest.response_format is a writable dataclass field.
  • Docs: Overview - Docs by LangChain - wrap_model_call
    signature, editing the request, custom context_schema.
  • Docs: Context engineering in agents - Docs by LangChain -
    context_schema + runtime.context as the per-invocation channel.

1 Like

Wow thank you for the detailed response and guidance!
It’s much appreciated.

no problem - let me know if it works for you

1 Like

Worked like a charm! :smiley:

1 Like

Hmm, actually I am not certain it is working.
I am experiencing some issues.

I will provide snippets of my code this time for context.

# Response formats:
class AgentDecision(BaseModel): ...
class AgentJobSolution(BaseModel): ...
class AgentVote(BaseModel): ...

RESPONSE_FORMATS = {
    "decision": AgentDecision,
    "job_solve": AgentJobSolution,
    "vote": AgentVote,
}

@dataclass
class ResponseFormatContext:
    response_format_key: Literal["decision", "job_solve", "vote"]


class EnergyMiddleware(AgentMiddleware):
    ...
    def wrap_model_call(self, request, handler):
        key = request.runtime.context.response_format_key
        request.response_format = ToolStrategy(RESPONSE_FORMATS[key])
        return handler(request)


class EnergyAgent:
    ...
        self._agent = create_agent(
            model=model,
            tools=tools,
            middleware=[EnergyMiddleware(model_size=model_size)],
            response_format=ToolStrategy(Union[AgentDecision, AgentJobSolution, AgentVote]),
            context_schema=ResponseFormatContext
        )

That is the setup.
And then I am calling the agent down the road passing state info and setting the reponse_format_key accordingly. An example:

        # Invoke agent to make a decision
        response = self._agent.invoke(
            {"messages": decision_messages, 
            "energy": self.energy, 
            "max_energy": self.max_energy,
            "phase_log": [],
            },
            context=ResponseFormatContext(response_format_key="decision"),
        )

What I am noticing is that the agents don’t seem to have one specific response format as if I had called an agent that was just initialized with a single response format when using this approach.
I am having problems where the agent is returning one of the other response formats.
For instance in a call from the invoke example above, the agent called the AgentDecision ToolStrategy instead and returned that format.

When inspecting the EnergyMiddleware.wrap_model_call trace in LangSmith it also seems like the response format is not changed from the Union:

image

I’m not sure if I am missing something?

hi @Bergholdt

alright, lemme follow up on this - thanks for reporting the issues! :slight_smile:

1 Like

would it be possible for you to share the langsmith thread with me?

in the meantime

instead of

@wrap_model_call
def select_format(
    request: ModelRequest,
    handler: Callable[[ModelRequest], ModelResponse],
) -> ModelResponse:
    key = request.runtime.context.response_format_key
    request.response_format = ToolStrategy(SCHEMAS[key])  # subset of the Union
    return handler(request)

try this

  class EnergyMiddleware(AgentMiddleware):
      def wrap_model_call(self, request, handler):
          key = request.runtime.context.response_format_key
          return handler(
              request.override(response_format=ToolStrategy(RESPONSE_FORMATS[key]))
          )

Two changes: .override(…) returns a new ModelRequest, and you must forward that new request to handler. If you mutate in place and forward the original, the factory may still see the Union because of dataclass aliasing plus the deprecation path.

Also worth double-checking: that every invoke() passes context=ResponseFormatContext(response_format_key=“…”), and that the key actually exists in RESPONSE_FORMATS. Full known-good snippet is in the doc.