eventbridge

When to invoke

Match the user's phrasing to one of these commands. Different surface forms all map to the same intent — pick the right verb, not a literal string match.

The user says…	Run	Notes
"run an agent to X" · "run agent to X and print the response" · "ask an agent to X"	run "X"	Default output prints the model's reply inline.
"run agent to X quietly" · "just start it, I'll check later"	run "X" --no-watch	Returns as soon as the correlationid is minted.
"show every step" · "verbose" · "with tool calls"	run "X" --verbose	One labeled line per stream-json event.
"check on " · "what happened with " · "any progress on "	watch <corr>	Polls until the correlation reaches final=true.
"continue : Y" · "follow up on with Y" · "and now Y" (after a recent run)	cont <corr> "Y"	Resumes the same claude session.
"chat " · "show the conversation for " · "print the transcript"	chat <corr>	Turn-grouped USER/ASSISTANT view.
"run agent1 to X and agent2 to Y" · "run two agents" · "start these in parallel"	runmany "X" "Y"	Submits ALL prompts first, then follows them all. This is what makes KEDA scale past one pod.
"run a batch of N agents, each …" · "run N agents as a group" · "100 agents saying Hello N"	group run --template "…{n}…" --count N	A batch: one start + one finish notification instead of N, a shared progress page, and watching is the default. Say "batch"/"group"/a count ≥ ~5 and this is the intent.

Two or more agents at once — use runmany, never two separate run calls:

python3 .../eventbridge-cli.py runmany "Say hello" "Say world" \
  --label agent1 --label agent2

How the words in the request map to the command — follow this literally, so the same request always produces the same command:

N agents from a pattern ("run 100 agents, each saying Hello N") — use --template/--count, never 100 positional arguments:

python3 .../eventbridge-cli.py group run \
  --template "Say Hello {n}" --count 100 --label hello-100

{n} is 1-based (shift it with --start), {i} is 0-based. This is the reliable form: 100 shell-quoted arguments is easy to get wrong and hard to read back, and the CLI echoes the first and last generated prompt so the pattern is visible before anything runs.

With --watch (the default) the command then prints a progress line every 2s until the batch finishes, so the monitoring happens right in the transcript. It also prints the two URLs to open — the group page and the group list.

In the request	Becomes
each task, in the order given	one positional PROMPT, quoted
the agents are given names ("agent1 … agent2", "researcher … writer")	--label <name> once per agent, in the same order
the agents are not named	omit --label; they default to agent1, agent2, …
an environment or URL is named ("on ykt1", "on kind")	--base-url — resolve it per the table below
a shared constraint ("one word each", "be brief")	append it to every prompt
a numbered pattern ("each saying Hello N", "for N=1..100")	--template "…{n}…" --count N, not N positional prompts
"monitor it" · "show progress" · "print updates"	nothing — group run watches by default and prints a line every 2s. --interval changes the cadence
"quietly" · "don't wait"	--no-watch

So "run agent1 to say hello and agent2 to say world, one word each" becomes just:

python3 .../eventbridge-cli.py runmany \
  "Say hello. One word." "Say world. One word." \
  --label agent1 --label agent2

with no --base-url at all when $EVENTBRIDGE_URL is exported — which is the usual case. Add --base-url <url> only when the user names a target for this one command.

The ordering is the whole point. runmany POSTs every prompt before it watches anything, so N requests sit on the topic together, KEDA sees lag N and scales to N pods. Two sequential run calls would each finish before the next was submitted — lag would never exceed 1, one pod would serve both, and nothing would scale. Verified on a cluster: two prompts took the Deployment 0 → 1 → 2 with two pods Running and two notifications delivered.