agents · review · first seen Nov 2, 10:32 UTC

CrewAI releases 1.15.34 with flow and runner updates

CrewAI shipped 1.15.34 with CLI options for Python flows and deploy creation, plus a changed response to empty LLM answers. Builders should check whether these paths affect their own runs before adopting the release more broadly.

L0 · primary1 source4 claims checked4 min read

What shipped

The release adds support for passing crewai run --inputs to a Python flow. The release notes identify a specific CLI-to-flow path; they do not say that every way of invoking a flow has changed. If you start a Python flow with crewai run, this is the path to test against the inputs you expect it to receive. [1]

Deploy creation now has a deploy create --zip option. The release notes also say the command prints the commit from which a zip is built. Those are the stated behaviors. The printed commit is useful to inspect, but it does not by itself establish what an archive contains or what is running after deployment. [1]

For an empty LLM answer, the runner retries once before raising a typed error. That changes the failure path; it does not guarantee a usable answer on the retry. The release also documents removal of the 1.15.29 agent executor and includes migration notes. The supplied material does not give the migration steps, so code that depends on that executor needs a separate compatibility review. [1][2]

Why it matters if you build

For a Python flow launched from the CLI, --inputs is worth testing with the invocation your project actually uses. Check what the flow receives, not just whether the command accepts the option. The supplied notes do not define the input syntax, validation rules, defaults, or behavior for other kinds of flows. Your existing expected result is the useful comparison. [1]

If deploy creation is part of your release routine, you can try the zip option and record the commit the command prints. That gives you an observable check at build time. It is not an end-to-end deployment check: the supplied notes do not describe archive contents, upload results, deployment timing, or rollback behavior. Keep those questions separate when deciding whether to change a deployment procedure. [1]

The empty-answer change matters to callers that handle failures and to tests that expect a run to fail immediately. An empty first answer now gets one retry; if the answer remains empty, the runner raises a typed error. Check the error your code receives and whether its handling still fits. The claim gives no measurement of how often this happens or what the retry costs. If your code also relies on the 1.15.29 executor, read its migration notes before treating this as a routine update. [1][2]

How to try it today

1. Run an existing Python flow with crewai run --inputs and check what the flow receives.
2. Try deploy create --zip in a suitable test path and record the printed commit.
3. Test an empty LLM answer and inspect the retry and typed error if the answer remains empty.
4. If your code uses the 1.15.29 agent executor, read the removal and migration notes before changing it.

What we checked

Every claim below was walked down the source ladder. The rung is how close the source is to the thing itself; the tense is the source's own.

1. shipped L0 · primary

   CrewAI 1.15.34 adds crewai run --inputs support for a Python flow.

   per GitHub releases · crewAIInc/crewAI (L0)
2. shipped L0 · primary

   CrewAI 1.15.34 adds deploy create --zip.

   per GitHub releases · crewAIInc/crewAI (L0)
3. shipped L0 · primary

   CrewAI 1.15.34 retries an empty LLM answer once before raising a typed error.

   per GitHub releases · crewAIInc/crewAI (L0)
4. shipped L0 · primary

   CrewAI 1.15.34 documents the removal of the 1.15.29 agent executor with migration notes.

   per GitHub releases · crewAIInc/crewAI (L0)

What is not confirmed

The supplied material does not establish the full --inputs syntax or its scope beyond a Python flow. It does not establish the zip contents or a deployment result, name the typed error class, or reproduce the executor migration steps. It also provides no measured reliability, latency, or cost change. Treat each as a question for the artifact or your own test, not as a reported outcome. [1][2][3][4]

Who should act, who should wait

Act now with a focused test if you launch Python flows through crewai run, use CLI deploy creation, handle empty LLM answers, or depend on the 1.15.29 executor. Each has a named change to check against your code. Wait on a broader rollout if you need verified archive contents, an end-to-end deployment result, a measured retry cost, or the exact executor migration steps before deciding. The supplied release summary does not settle those questions. [1][2][3][4]

Sources

• 1.15.34 — GitHub releases · crewAIInc/crewAI L0 · primary