Run it reliably
Protect downstream systems with a cap
Bound how many turns one agent can execute at once and make overload visible to the caller.
Set per-agent concurrency caps.
What this changes for your team.
A per-agent cap bounds active execution for that published workload. When the cap is full, new work is refused visibly rather than accepted into a hidden backlog, helping contain bursts against provider limits or fragile downstream systems.
How it works in practice.
- 01
Choose the maximum simultaneous turns appropriate for the agent and its dependencies.
- 02
Publish the setting so the runtime checks live work against that cap on each start attempt.
- 03
Return a capacity refusal when every slot is occupied, leaving the caller to retry deliberately.
What you can plan around.
The behaviour you can design against, stated concretely.
The cap is evaluated in shared execution coordination, not independently by each browser.
Work beyond the cap is refused rather than queued silently.
Session ordering remains stricter than the agent cap when several messages belong to one session.
Bring one real process
See how Yekar.AI fits the way you work.
Start with a job your team already owns, plus the tools and decisions around it.
Talk to us