CrewAI 1.15.7 fixes the tool-call path. Test it before you promote it.

A Responses tool-call item can carry both id and call_id, but the tool result must correlate through call_id. CrewAI’s 1.15.7 fix commit says the item’s id identifies the response item, while call_id identifies the function invocation whose output the model is waiting for. Returning a result against the wrong field can break an otherwise valid tool loop.

That detail makes CrewAI 1.15.7 an adapter and acceptance-test decision. Operators using OpenAI tools through the Responses API, models that CrewAI routes to Responses, GPT-5.6 with tools, or CrewAI’s Bedrock extra have a reason to canary the release. After reading, you should be able to test the relevant route, inspect the resolved bedrock-agentcore version where needed, and defer when none of these paths exists.

The Responses loop depends on the correct call identifier

A function tool loop has several participants. The model emits a request to call a function, the application executes that function, and the application sends the result back so the model can continue. OpenAI’s function-calling guide shows the Responses form of that return value as a function_call_output item whose call_id equals the call_id on the original function_call.

CrewAI has to translate between that form and its internal conversation history. Chat Completions puts a call inside an assistant message under tool_calls, followed by a message with role: "tool" and tool_call_id. Responses uses flat function_call and function_call_output items keyed by call_id. CrewAI’s commit says a raw Responses item can also contain a separate id; choosing that value for the result loses the correlation the Responses loop needs.

The visible failures follow the adapter’s processing order

CrewAI’s maintainers documented three failures in sequence on the Responses tool path. First, a helper did not recognize the flat {id, name, arguments} shape as a tool-call list, so the agent could return raw tool-call JSON as its final answer. Recognizing the list exposed the next problem: another helper looked for arguments inside a nested function object or under input, which could reduce valid top-level arguments to {}.

Once the tool call was recognized and its arguments survived, CrewAI still had to send the result back. The adapter was passing Chat Completions-shaped assistant and tool messages into a Responses request. The project’s fix commit reports that this follow-up produced a 400 because an input item carried content: null; the patch translates those messages into function_call and function_call_output items instead.

The same commit added an explicit preference for call_id when a raw item also has id. CrewAI says its normal extraction path already mapped the correct value, while a shared helper could select the item id. OpenAI’s guide independently documents the output shape and its use of call_id; CrewAI’s test totals and live endpoint results remain maintainer-reported evidence.

These symptoms identify different points of failure. Raw JSON means the executor may not have recognized a tool call. Empty arguments point to extraction. A 400 after the tool runs points to follow-up translation or another request-shape problem. A 404 before tool execution can instead mean CrewAI sent a Responses-only model to Chat Completions.

CrewAI 1.15.7 changes three separate OpenAI adapter decisions

Responses tool loops now preserve arguments and translate both sides

The Responses tool-loop change teaches CrewAI to recognize the flat call shape, read top-level arguments, prefer call_id, and convert stored Chat Completions-style tool messages into native Responses items. Messages without tool calls continue through the existing path. CrewAI’s maintainers report that a direct tool request returned 391 after the change instead of raw JSON, and that a chained 17 × 23, then + 9, run returned 400.

Those outcomes support a canary; they do not establish failure prevalence or regression freedom. The source evidence applies to CrewAI’s adapter behavior, not to an OpenAI-wide Responses failure or to other agent frameworks.

Known Responses-only models now route away from Chat Completions

A separate commit handles endpoint selection. CrewAI’s maintainers report live probes in which gpt-5-pro, gpt-5.5-pro, gpt-5.4-pro, gpt-5.2-pro, o1-pro, and o3-pro returned 404 through /v1/chat/completions and worked through /v1/responses. Version 1.15.7 matches a normalized, exact list of those models and routes them to Responses instead of treating the 404 as a missing model.

This change should be evaluated separately from tool-loop translation. Correct routing gets the request to the intended API. Translation still has to carry each function call, its arguments, and its correlated output through the loop.

GPT-5.6 tool errors receive one bounded retry

The third change remains on CrewAI’s Chat Completions path. CrewAI’s maintainers report that GPT-5.6 tool requests received a 400 when a server-side reasoning_effort default was in effect, even though neither the application nor CrewAI had supplied the field. Their probes succeeded when the retry sent reasoning_effort="none" explicitly.

CrewAI 1.15.7 catches that specific 400 and retries once with the explicit value. The match uses the structured parameter and error message, unrelated 400 responses do not trigger it, and a second failure surfaces instead of looping. The reported model behavior and live outcomes belong to CrewAI’s commit evidence; they should not be generalized to every GPT-5.6 client or endpoint.

One chained two-tool run can accept or reject the canary

Run the test in a non-production environment with the same model name, API selection, CrewAI configuration, and dependency lock used by the intended deployment. Define two local tools with deterministic behavior: multiply(a, b) returns a * b, and add(value, increment) returns value + increment. Keep their schemas strict enough that missing arguments fail visibly.

Give the agent this instruction:

Use multiply with a=17 and b=23. Pass that tool's exact result to add as value, with increment=9. Return only the final integer.

Capture both the application’s tool-execution log and the provider request items. The first tool must receive {"a":17,"b":23} and return 391. Its function_call_output must use the original function call’s call_id, even when the source item also contains a different id. The second tool must then receive {"value":391,"increment":9}, return 400, and leave the agent with a human-readable final answer of 400.

Reject the canary for that route if the run ends with raw tool-call JSON, either tool receives {}, the output uses the item id instead of call_id, the second tool never runs, the final answer is not the integer 400, or the provider request returns an HTTP 400 or 404 error. A correct final number without the trace is insufficient because the model could calculate the answer without proving the adapter carried the calls and results correctly. This acceptance test is a BaristaLabs recommendation derived from the documented mechanism; it is separate from CrewAI’s reported test suite and live probes.

This is the same reason a model bake-off needs a harness: the final answer alone cannot tell you which route, translation, or tool behavior produced it.

Bedrock deployments need the resolved AgentCore version

CrewAI 1.15.7 also changes its optional Bedrock dependency range from bedrock-agentcore>=1.7.0,<1.8.0 to >=1.18.1,<2.0.0, with related boto3 and aiobotocore changes so the dependency set can resolve. A declared CrewAI version does not prove which AgentCore build is inside an existing lock file or container. Check the deployed environment directly, for example with python -c "from importlib.metadata import version; print(version('bedrock-agentcore'))", and require 1.18.1 or later where that package is installed.

CVE-2026-16796 is limited to bedrock-agentcore versions below 1.18.1 and a specific Code Interpreter method. The GitHub advisory describes a remote authenticated user whose input can influence crafted package arguments passed to install_packages; the published vector also includes user interaction. The resulting command execution occurs inside the Code Interpreter sandbox.

CrewAI’s own dependency PR says its code did not call install_packages, so the project described its exposure as limited. That statement rules out calling every CrewAI deployment vulnerable. Applications that do pass untrusted or model-generated package names to the method still need the patched dependency and strict validation of dynamic package names.

Promote 1.15.7 only when the relevant evidence passes

Canary 1.15.7 when production uses Responses tools, one of CrewAI’s known Responses-only model routes, GPT-5.6 with tools, or the Bedrock extra. For an OpenAI route, promote only after the chained test preserves both argument sets, correlates outputs through call_id, and finishes with the integer 400. For a Bedrock deployment, require the resolved bedrock-agentcore version to be 1.18.1 or later. If none of these routes exists, the available sources give that deployment no specific reason to take this release immediately.

If opaque provider traces prevent the chained test or an uncertain dependency tree prevents the AgentCore version check, BaristaLabs can help through AI consulting or a focused CrewAI provider-adapter upgrade review. Promote only after the evidence required for the affected route passes; otherwise defer the production change.

Sources

• CrewAI 1.15.7 release
• CrewAI 1.15.7 on PyPI
• CrewAI Responses tool-loop commit
• CrewAI Responses-only model routing commit
• CrewAI GPT-5.6 bounded-retry commit
• CrewAI Bedrock AgentCore dependency PR
• OpenAI function-calling guide
• GitHub advisory for CVE-2026-16796