CrewAI 1.15: per-run state isolation for parallel Sume jobs

If you run several CrewAI crews at once, each should own its own Sume job ids and idempotency keys, and recent CrewAI releases help by scoping runtime state per run. CrewAI's changelog shows v1.15.22 on September 16 and v1.15.23 on September 28, 2026, with runtime state scoped per run to isolate concurrent runs. Isolation is inside CrewAI. Sume's concurrency is set by your plan, so parallel crews still share one limit.

Facts to design around

One key and one job id per crew run

Do not store a Sume job id in a module global. Keep it on the run's own state, and derive the Idempotency-Key from the run identity plus the task. A retry inside the same run then returns the original job. A different run gets a different key, so crews never collide.

If your tool is a hosted MCP call, Sume write and paid tools require an idempotency_key argument anyway. Optional dry_run and max_spend_usd let the agent check cost first.

Respect admission

Eight crews calling a Pro plan, which has concurrency 4, will see waits and eventually 429 queue_full when queue capacity fills. That is max(3, 5 times 4), so 20. Handle it in the tool, not in the model's reasoning.

• 429 rate_limited: sleep for retry-after, then retry with the same key.
• 429 queue_full: back off longer; the wave_size_hint in the generation_limits snapshot is only a hint.
• 402 insufficient_credits: stop and surface it.

Waiting inside a tool

A tool call should not block a crew for minutes. Submit, return the job id, and let a later task call jobs_wait (at most 55 seconds per call). Batch job_ids takes 1 to 20 ids and supports include_results: true, which suits a crew that fanned out several jobs.