[Bug]: Other first-party adapters drop ToolMessage.error too (langchain TS, aws-strands, vercel-ai-sdk, mastra)

[contextablemark]

Describe the Bug

Follow-up to #2226, split out of the review of #2263.

#2226 and #2263 treat this as a LangGraph bug, but the same one-line omission is present in several other first-party adapters: AG-UI's ToolMessage.error is never read when an incoming tool result is converted into the target framework's tool-result shape, so a client-reported tool failure is handed to the model as a success.

integrations/langchain/typescript — same fix as #2263, verbatim. src/messages.ts:46-51:

if (message.role === "tool") {
  return new ToolMessage({
    content: message.content,
    tool_call_id: message.toolCallId,
  });
}

@langchain/core's ToolMessage has the same status: "success" | "error" field the LangGraph fix targets, and the same provider plumbing consumes it. This is a direct copy of #2263's change.

integrations/aws-strands/python — hardcoded success. src/ag_ui_strands/agent.py:234-243:

if role == "tool":
    pending_tool_results.append(
        {
            "toolResult": {
                "toolUseId": getattr(msg, "tool_call_id", "") or "",
                "content": [{"text": _coerce_text(msg.content)}],
                "status": "success",
            }
        }
    )

The Bedrock toolResult block accepts status: "success" | "error", and here it is pinned to "success" unconditionally — a failed frontend tool call is asserted to the model as having succeeded. Same shape of fix: "error" if getattr(msg, "error", None) else "success".

The same file's agui_messages_to_strands-style conversion at agent.py:198-208 also rebuilds an AG-UI ToolMessage without error, dropping the field on that path too.

integrations/vercel-ai-sdk/typescript (src/index.ts:271-281) and integrations/mastra/typescript (src/utils.ts:202-214) both build a tool-result part from toolCallId / toolName / result with no error signal at all. Whether these are fixable depends on the AI SDK version in use — v5's tool-result output supports an error-typed output — so they need a look rather than a copy-paste of the same patch.

Steps to Reproduce

Same as #2226, with the adapter swapped. For the LangChain TS adapter:

1. Convert an AG-UI ToolMessage with error set via integrations/langchain/typescript's message conversion.
2. Inspect the resulting ToolMessage.status.
3. It is "success" (the default); langchain_anthropic and friends then report is_error: false to the model.

Expected Behavior

Every first-party adapter that converts an AG-UI tool message into a framework tool result should carry the failure signal across when the target framework has a slot for it. error set ⇒ the framework's error flag set.

Additional Context

• Worth deciding as a group rather than one PR per adapter, so the adapters do not diverge on the "does the error text travel too?" question. The claude-managed-agents adapters already do carry it — integrations/claude-managed-agents/typescript/src/agent.ts:30-32 and integrations/claude-managed-agents/python/ag_ui_claude_managed_agents/agent.py:521-532 newline-join content + error into the result text and set is_error from bool(error) — so there is an in-repo precedent to standardize on.
• [Bug]: LangGraph adapters drop ToolMessage.error, so a client-reported tool failure reaches the model as a success #2226's documentation note applies here as well: the tools concept page's "Tool Results" example omits error entirely, which is plausibly why adapter authors keep missing it.

Environment

integrations/langchain (TypeScript), integrations/aws-strands (Python),
integrations/vercel-ai-sdk (TypeScript), integrations/mastra (TypeScript), as of bb1c2afd
Related: #2226, #2263

[TheSeydiCharyyev]

Hi, I'd like to take this one, together with #2305.

I mapped all four:

• langchain/typescript (messages.ts:46) — a verbatim copy of fix(langgraph): carry ToolMessage.error onto the LangChain status flag #2263.
• aws-strands/python (agent.py:234) — pins status: "success"; same shape, "error" if getattr(msg, "error", None) else "success". Its reverse path (agent.py:198) also drops error, like [Bug]: LangGraph adapters drop ToolMessage status on the LangChain → AG-UI direction, so a tool failure is not durable across MESSAGES_SNAPSHOT #2305.
• vercel-ai-sdk (index.ts:271) and mastra (utils.ts:202) build a tool-result part with no error slot — these need an AI SDK v5 check first, not a copy-paste.

My default is to match #2263: set the framework error flag from bool(error), flag only, so these stay consistent with the fix you just merged. You pointed at the claude-managed-agents precedent that also carries the text — if you'd rather standardize on that across all adapters (and the forward fixes), I'll follow that as the group standard instead. Which do you want? I'll keep the adapters consistent either way.

[contextablemark]

Thanks for mapping all four, and yes — please take both.

Go with your default: flag only. To make that a rule rather than a coin flip, here's the standard I'd like the adapters to hold:

Set the framework's error flag from bool(error). Fold error's text into the result content only when the target has no flag at all.

That framing makes claude-managed-agents consistent rather than an exception: it folds the text because its transport is content: [{type: "text"}] + is_error — text-or-nothing. All four adapters here have a structured result slot plus a dedicated flag, so they don't face that constraint. Same reasoning, different mechanics, which is why "text travels" shouldn't be generalized from it.

The other reasons for flag-only: it keeps five adapters on one rule today instead of reopening freshly-merged #2263; bool(error) → flag invents nothing and changes no prompt; and folding text into content does change what the model reads. Worth noting #2226's own repro is content="Tool failed: invalid id", error="invalid id" — clients commonly duplicate the message, so folding risks doubling it. That's a behavior change deserving its own issue and tests, not a rider on four one-line fixes.

On the AI SDK question — both are v4, and v4 already has the slot. No version gate, and no v5 check needed. I dug into this because it's the only thing that looked like it might not be copy-paste:

• vercel-ai-sdk resolves ai@4.3.19 (pnpm-lock.yaml:1159). v4's ToolResultPart (ai/dist/index.d.ts:705) already carries isError?: boolean, documented as "Optional flag if the result is an error or an error message."
• mastra looks like it might be v5 — the file even has a comment referencing AI SDK v5's Responses API default — but the type it actually builds is v4. CoreMessage from @mastra/core/llm is export type CoreMessage = AiCoreMessage (@mastra/core@1.47.0, dist/llm/index.d.ts:10), imported from mastra's bundled _types/@internal_ai-sdk-v4. Same v4 type, same isError field. The as CoreMessage cast at utils.ts:212 is what's currently hiding the missing field from tsc.
• The flag does reach the model on both: v4's convertToLanguageModelMessage forwards part.isError onto the LanguageModelV1 tool-result part (which is what e.g. @ai-sdk/anthropic turns into is_error), and mastra's aiV4CoreMessageToV1PromptMessage spreads ...part rather than allowlisting fields, so nothing strips it on the v4 input path.

Caveat on that last point: I traced it through published dist output, not source. The type slot is certain; please pin mastra's behavior with a test rather than relying on my read of the internals.

So all four are the same one-liner:

• langchain/typescript/src/messages.ts:49 — status: message.error ? "error" : "success" (@langchain/core ≥0.3 ToolMessage has status; verbatim fix(langgraph): carry ToolMessage.error onto the LangChain status flag #2263)
• aws-strands/python/.../agent.py:240 — "status": "error" if getattr(msg, "error", None) else "success"
• vercel-ai-sdk/typescript/src/index.ts:278 — isError: !!message.error
• mastra/typescript/src/utils.ts:212 — isError: !!message.error

One correction to my own issue text: I filed the aws-strands second site (agent.py:207) as "#2305-shaped," but it's a different and simpler bug. _build_snapshot_messages is AG-UI → AG-UI — it rebuilds the client's own messages to seed MessagesSnapshotEvent (agent.py:602). So dropping error there erases the client's own error text from its own message on the snapshot echo, with no framework mapping and no invent-the-text question anywhere in it. It drops encrypted_value too. That one isn't blocked by the standards decision at all — feel free to ship it in the same PR as a plain field copy.

Happy with one PR for all four plus that snapshot fix, or split per-adapter if you'd rather — your call. A test per adapter next to the existing conversion tests, matching #2263's shape.

I'll take the docs/concepts/tools.mdx:166-172 fix separately so it doesn't sit in your PR.