feat(agent): make responseFormat.strict configurable to support optional tool parameters #9535

Nitinref · 2025-12-02T17:45:24Z

🚀 What this PR does

This patch makes the strict behavior of responseFormat configurable when using createAgent.

Previously, createAgent always set strict: true internally — this caused agents using tools or optional parameter schemas to break with invalid_function_parameters.
Now, if the user passes responseFormat.strict = false, the agent honors it and does not enforce strict validation — enabling use of optional fields or more flexible tool parameter schemas.

✅ Why this matters

Enables tool schemas with optional parameters under structured output or JSON schema response formats.
Resolves the issue createAgent with responseFormat not working with tools with optional parameters #9528 — previously there was no way to bypass strict validation in agent usage.
Maintains backward-compatibility: if strict is omitted, the default remains true.

🔧 What changed

In AgentNode.ts, strict: true is replaced with logic that reads responseFormat.strict if supplied, else defaults to true.
This means only when explicitly requested, strict mode is relaxed.

🧪 Verification

Tested locally with real OpenAI model.
Example usage that works with optional tool parameters:

const agent = createAgent({
  model: new ChatOpenAI({ model: "gpt-4o-mini" }),
  tools: [myToolWithOptionalParams],
  responseFormat: {
    // your output schema...
    strict: false,
  },
});

Under this configuration, agent interacts successfully; no invalid_function_parameters error — the fix works as intended.

⚠️ Notes / Caveats

strict: false should be used consciously — disabling strict validation may reduce safety guarantees (e.g. tool parameter validation).
Users who rely on strict schema validation should either omit strict or explicitly set it to true.

changeset-bot · 2025-12-02T17:45:28Z

⚠️ No Changeset found

Latest commit: 5cc8841

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

Nitinref · 2025-12-02T17:48:06Z

Hi! Please let me know if any changes are needed.
Happy to update the PR. 🙂

MartijnLeplae · 2025-12-02T18:45:48Z

Hi, thanks for your PR! I will make some time later to go through it fully. Some initial comments:

Why did you remove the getState method? It seems unrelevant to this PR.
It seems you included changes of another pull request you made. I would keep each one clearly scoped.
I would personally not change the type of responseFormat here. Non-strict tool-calling should be possible while having strict outputFormat.
Perhaps changing the logic in responses.ts would be enough?
I was thinking changing the following lines to change: replace the else if with if such that the strictness of the toolcalling can be controlled with the supportsStrictToolCalling parameter. But perhaps some input from the initial author of that piece of code is needed so no unwanted side-effects are introduced.

langchainjs/libs/providers/langchain-openai/src/chat_models/responses.ts

Lines 73 to 78 in 3424293

    
           let strict: boolean | undefined; 
        
           if (options?.strict !== undefined) { 
        
             strict = options.strict; 
        
           } else if (this.supportsStrictToolCalling !== undefined) { 
        
             strict = this.supportsStrictToolCalling; 
        
           }

Nitinref · 2025-12-02T18:50:45Z

Thanks a lot for the detailed review! Really appreciate the guidance.

Regarding the getState removal — you're right, that change was not intentional for this PR. I will revert it.
It seems I accidentally committed a part of another PR I was experimenting with — thanks for pointing that out. I will remove unrelated changes and keep this PR fully scoped to the strict behavior only.
Your suggestion makes sense: avoiding changes to the type of responseFormat and instead updating the logic inside responses.ts to allow non-strict tool-calling while keeping strict outputFormat seems cleaner.

I'll update the PR accordingly and push a revised version soon.

Nitinref · 2025-12-02T19:07:34Z

Hi! I’ve pushed the updated changes, keeping the PR focused and applying the strict logic update in the responses API as suggested.

MartijnLeplae · 2025-12-02T19:13:11Z

Small note in general: make sure to follow contributing guidelines. (linting, formatting, testing, ...).
Also, but that's personal for me, I do not really enjoy reading llm generated pr descriptions etc. Just write it yourself. (well that is if you are not a bot yourself, which does seem like it ;) )

Nitinref · 2025-12-02T19:20:00Z

Thank you sir for the feedback i will follow the contributing guidelines from now.

MartijnLeplae · 2025-12-03T07:06:12Z

libs/providers/langchain-openai/src/chat_models/responses.ts

      include: options?.include,
      tools: options?.tools?.length
        ? this._reduceChatOpenAITools(options.tools, {
-            stream: this.streaming,


Follow the steps here https://github.com/langchain-ai/langchainjs/blob/main/CONTRIBUTING.md#linting, to properly format/lint your code :)

MartijnLeplae · 2025-12-03T07:07:46Z

libs/providers/langchain-openai/src/chat_models/responses.ts

      strict = options.strict;
-    } else if (this.supportsStrictToolCalling !== undefined) {
+    }
+    if (strict === undefined && this.supportsStrictToolCalling !== undefined) {


Did you try to run the tests? I would be interested to know if this is a breaking change

Nitinref · 2025-12-03T15:52:35Z

Hey I ran pnpm test inside libs/providers/langchain-openai and all the tests passed fine on my side, I also checked the formatting with pnpm lint:eslint, and everything looks clean there too.
From what I’ve checked so far, this change shouldn’t cause any breaking issues.

christian-bromann

Thanks for the contribution @Nitinref! Two requests:

can we resolve the formatting? pnpm run format:check:fix should do that for you.
Can we have some unit tests for this?

Nitinref · 2025-12-05T08:59:47Z

All requested changes have been addressed, the branch is updated with main,
and lint + tests are passing locally. Let me know if anything else is needed.

christian-bromann · 2025-12-08T21:33:51Z

@MartijnLeplae any last thoughts?

MartijnLeplae · 2025-12-09T09:26:31Z

Yes actually @christian-bromann. Am I right that the change does not actually do anything?
My initial idea was to change the else if to if to make the strict variable overwritable by supportsStrictToolCalling.
The new code does do this, but it also added strict === undefined to the statement, which makes the behaviour equivalent to the current behaviour if I'm not mistaken.

Why did you add this extra check @Nitinref?

Nitinref · 2025-12-09T10:00:20Z

Thanks for the clarification @MartijnLeplae
You’re right — the extra strict === undefined check made the behavior equivalent to the previous implementation.
I misunderstood the intent initially.
The goal is:
if the user explicitly sets strict, always use that
otherwise, fall back to supportsStrictToolCalling
if neither is provided, default to false
I will update the PR to use the simplified logic:

const useStrict =
options?.strict ?? options?.supportsStrictToolCalling ?? false;

And pass strict: useStrict to the OpenAI tool definition.
This will correctly allow overriding strict mode while preserving current behavior.
Let me push the update shortly.

MartijnLeplae · 2025-12-09T10:19:12Z

I think your reasoning is not completely right @Nitinref

Writing

const useStrict = options?.strict ?? options?.supportsStrictToolCalling ?? false;

Is not the same as saying overriding is possible. The ?? operator will only use options?.supportsStrictToolCalling if options?.strict is undefined or null. Making it a fallback, and not an override if it is given, which is the current behaviour.

Perhaps to clarify more, my initial issue is that the createAgent always sets strict to true in these lines:

langchainjs/libs/langchain/src/agents/nodes/AgentNode.ts

Lines 839 to 849 in 8a77e9a

    
           Object.assign(options, { 
        
             response_format: { 
        
               type: "json_schema", 
        
               json_schema: jsonSchemaParams, 
        
             }, 
        
             ls_structured_output_format: { 
        
               kwargs: { method: "json_schema" }, 
        
               schema: structuredResponseFormat.strategy.schema, 
        
             }, 
        
             strict: true, 
        
           });

therefore options?.strict is never undefined or null when using agentNode, unless the agentNode code would be changed.

What do you think @christian-bromann ?

Nitinref · 2025-12-09T10:57:00Z

@MartijnLeplae since AgentNode always sets strict: true, options.strict never ends up undefined, so the fallback to supportsStrictToolCalling can't actually happen. I missed that connection earlier.I’ll update the AgentNode logic so user-provided strict truly overrides, and only fall back when it's not set. Will push the fix shortly. Thanks for catching this!

…rategy and update strict tool-calling tests

christian-bromann · 2025-12-09T16:51:06Z

@Nitinref @MartijnLeplae I just realized that this conflicts with a PR I put up last week that would allow to overwrite strict through the providerStrategy primitive. Any thoughts on what approach is better here?

Nitinref · 2025-12-09T17:02:46Z

@christian-bromann Thanks for pointing that out!
It looks like both changes try to solve the same issue but at different layers.
My view is:
If the user explicitly sets strict, that should take priority.
Otherwise, falling back to the providerStrategy’s strict value makes sense.
I’m happy to adapt this PR to follow the direction of your approach if providerStrategy is meant to be the main place for overriding strict.Just let me know which direction you prefer!

christian-bromann · 2025-12-10T20:02:48Z

I’m happy to adapt this PR to follow the direction of your approach if providerStrategy is meant to be the main place for overriding strict

Let's do that, I am happy to close out my PR if we can incorporate that idea here as well.

Let's recap: by default we maintain a strict type validation. User can disable that by setting it explicitly to false via:

// json schema / using default strategy
const agent = createAgent({
  model: new ChatOpenAI({ model: "gpt-4o-mini" }),
  tools: [myToolWithOptionalParams],
  responseFormat: {
    // your output schema...
    strict: false,
  },
});

// tool/provider strategy explicitly defined
const agent = createAgent({
  model: new ChatOpenAI({ model: "gpt-4o-mini" }),
  tools: [myToolWithOptionalParams],
  responseFormat: toolStrategy({ // or providerStrategy
    schema: z.object({ ... }), // or json schema
    strict: false
  }),
});

Right?

Nitinref · 2025-12-11T02:12:01Z

@christian-bromann Thanks for the clarification!
This makes sense — I’ll update the PR so the strict resolution follows:

user-provided strict
otherwise providerStrategy.strict
otherwise default true

Once I push the update, we can fully replace the logic from your PR.
I’ll tag you for review when it’s ready

Nitinref · 2025-12-11T18:43:19Z

I've updated the PR to move strict resolution entirely into AgentNode as suggested.
The logic now resolves strict in the correct priority order:

user strict override
providerStrategy.strict
default true
Let me know if you'd like any additional adjustments!

christian-bromann · 2025-12-12T17:35:02Z

2. providerStrategy.strict

How do you set strict via provider strategy, my idea in the PR was to allow something like:

  responseFormat: providerStrategy({
    schema: z.object({ ... })
    strict: false
  })

christian-bromann · 2025-12-12T17:35:34Z

I can go ahead and merge this change once pipeline passes and then merge my PR after.

Nitinref · 2025-12-12T19:02:18Z

@christian-bromann Thanks for the review!

Just to clarify — the strict resolution priority you described is already implemented in this PR inside AgentNode.ts:
This matches the desired behavior:

user override
providerStrategy.strict
default true
If there's any additional adjustment needed, I'd be happy to update it!

const resolvedStrict =
  preparedOptions?.modelSettings?.strict ??
  structuredResponseFormat?.strategy?.strict ??
  true;

christian-bromann · 2025-12-12T20:48:53Z

But it currently doesn't allow to define the strict value for a specific response format strategy, right?

christian-bromann · 2025-12-12T20:49:47Z

You've outlined this example:

const agent = createAgent({
  model: new ChatOpenAI({ model: "gpt-4o-mini" }),
  tools: [myToolWithOptionalParams],
  responseFormat: {
    // your output schema...
    strict: false,
  },
});

which I assume uses JSON schema. But what happens if I want to use a Zod schema?

christian-bromann · 2025-12-12T22:08:47Z

@Nitinref it seems like the current PR is not complete:

TypeCheckError: Property 'strict' does not exist on type 'ProviderStrategy<unknown>'.
 ❯ src/agents/nodes/AgentNode.ts:840:45
    838|       const resolvedStrict =
    839|         preparedOptions?.modelSettings?.strict ??
    840|         structuredResponseFormat?.strategy?.strict ??
       |                                             ^
    841|         true;
    842|

?

christian-bromann · 2025-12-13T01:14:17Z

Embedding this PR in #9578

Nitinref · 2025-12-13T01:30:18Z

Thanks for the clarification!
Glad to see the strict handling landed cleanly via ProviderStrategy — makes sense to expose it at the API level. Happy to help test or document this if needed.

github-actions bot added pkg:langchain pkg:@langchain/google-genai labels Dec 2, 2025

Nitinref changed the title ~~Fix agent responseformat strict~~ feat(agent): make responseFormat.strict configurable to support optional tool parameters Dec 2, 2025

Nitinref mentioned this pull request Dec 2, 2025

createAgent with responseFormat not working with tools with optional parameters #9528

Closed

6 tasks

fix(responses): make strict tool-calling configurable

c6a64e2

Nitinref force-pushed the fix-agent-responseformat-strict branch from cdf9827 to c6a64e2 Compare December 2, 2025 19:02

github-actions bot added pkg:@langchain/openai and removed pkg:langchain pkg:@langchain/google-genai labels Dec 2, 2025

MartijnLeplae reviewed Dec 3, 2025

View reviewed changes

Merge branch 'main' into fix-agent-responseformat-strict

d1a6884

christian-bromann requested changes Dec 4, 2025

View reviewed changes

Nitinref added 2 commits December 5, 2025 05:51

test: add strict tool-calling tests for responses

33d7dd7

test: add strict tool-calling tests + format responses.ts

5d0249d

Nitinref force-pushed the fix-agent-responseformat-strict branch from 533f3c9 to 5d0249d Compare December 5, 2025 02:43

Merge branch 'main' into fix-agent-responseformat-strict

158b545

Nitinref requested review from MartijnLeplae and christian-bromann December 6, 2025 04:37

fix(responses): correctly pass strict through provider json_schema st…

e12c27d

…rategy and update strict tool-calling tests

github-actions bot added the pkg:langchain label Dec 9, 2025

fix: correct strict resolution priority in AgentNode

3f0bd6f

formatting

b853ac8

Merge branch 'main' into fix-agent-responseformat-strict

5cc8841

christian-bromann added a commit that referenced this pull request Dec 13, 2025

embed #9535

c3600b0

christian-bromann closed this Dec 13, 2025

Nitinref deleted the fix-agent-responseformat-strict branch December 18, 2025 03:44

feat(agent): make responseFormat.strict configurable to support optional tool parameters #9535

feat(agent): make responseFormat.strict configurable to support optional tool parameters #9535

Uh oh!

Conversation

Nitinref commented Dec 2, 2025

🚀 What this PR does

✅ Why this matters

🔧 What changed

🧪 Verification

⚠️ Notes / Caveats

Uh oh!

changeset-bot bot commented Dec 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

⚠️ No Changeset found

Uh oh!

Nitinref commented Dec 2, 2025

Uh oh!

MartijnLeplae commented Dec 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Nitinref commented Dec 2, 2025

Uh oh!

Nitinref commented Dec 2, 2025

Uh oh!

MartijnLeplae commented Dec 2, 2025

Uh oh!

Nitinref commented Dec 2, 2025

Uh oh!

MartijnLeplae Dec 3, 2025

Choose a reason for hiding this comment

Uh oh!

MartijnLeplae Dec 3, 2025

Choose a reason for hiding this comment

Uh oh!

Nitinref commented Dec 3, 2025

Uh oh!

christian-bromann left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Nitinref commented Dec 5, 2025

Uh oh!

christian-bromann commented Dec 8, 2025

Uh oh!

MartijnLeplae commented Dec 9, 2025

Uh oh!

Nitinref commented Dec 9, 2025

Uh oh!

MartijnLeplae commented Dec 9, 2025

Uh oh!

Nitinref commented Dec 9, 2025

Uh oh!

christian-bromann commented Dec 9, 2025

Uh oh!

Nitinref commented Dec 9, 2025

Uh oh!

christian-bromann commented Dec 10, 2025

Uh oh!

Nitinref commented Dec 11, 2025

Uh oh!

Nitinref commented Dec 11, 2025

Uh oh!

christian-bromann commented Dec 12, 2025

Uh oh!

christian-bromann commented Dec 12, 2025

Uh oh!

Nitinref commented Dec 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

christian-bromann commented Dec 12, 2025

Uh oh!

christian-bromann commented Dec 12, 2025

Uh oh!

christian-bromann commented Dec 12, 2025

Uh oh!

christian-bromann commented Dec 13, 2025

Uh oh!

Nitinref commented Dec 13, 2025

Uh oh!

Reviewers

changeset-bot bot commented Dec 2, 2025 •

edited

Loading

MartijnLeplae commented Dec 2, 2025 •

edited

Loading

christian-bromann left a comment •

edited

Loading

Nitinref commented Dec 12, 2025 •

edited

Loading