Agents That Run Agents
Freddy has a migration that touches three areas of the app. He could start three threads. He has begun to wonder whether the agent could do that part too: split the job, start the threads, wait for them and tell him what each one did. It can, and this chapter is about doing it without losing control of it.
The problem
You are the coordinator. You read the task, decide it has three parts, start three threads, remember which is which, come back to each, and collect the results. It is reasonable work, and it is mostly bookkeeping. The agent is often better placed to do it, because it has just read the code and knows where the seams are.
The hard way
Copying a plan into three message boxes, with the part-specific instructions edited by hand, and a note to yourself about which thread is waiting for which. And if you want another tool, say Claude Desktop, to look at what your threads are doing, there is nothing to point it at.
What the gateway is
Elyra Workspace includes a small MCP server. Through it, agents can work with Workspace's threads. One agent can split a job into parts, start a thread for each, wait for them and collect the results. Other apps such as Claude Desktop or Codex can also control Workspace.
The server listens only on your own machine
(127.0.0.1). Every caller needs a token, and every
call is written to an audit log. The address is shown in
Settings → Agents & MCP.
Turning it on
Turn on Settings → Agents & MCP → Let agents
manage threads. Agents started afterwards get the tools as
an MCP server named elyra. In Claude Code they appear
as mcp__elyra__….
- Supported by Claude Code, Codex, Elyra (0.9.46 or later) and ACP agents. Pi can use MCP servers through an extension with its own configuration, but does not get the gateway from Workspace yet.
-
With Elyra 0.9.47 or later the gateway's tools are there from the
first message of a thread. With 0.9.46 Elyra registers them in
the background, so an agent may have to reach them through
mcp_searchandmcp_callfirst. - Each agent gets its own token, which only lasts while Workspace is running.
An example prompt:
“Split the migration into three parts. For each, create a thread in this project with a worktree, then wait for all three and summarize what each did.”
Chapter 7 is why the with a worktree is there: three threads editing one folder would collide.
The tools
You do not need to memorize them; the agent reads their descriptions. They fall in groups:
| Group | Tools |
|---|---|
| Look | list_projects, list_threads (optionally for one project, including archived), read_thread (the most recent part of a conversation) |
| Wait | wait_for_thread: wait until a thread finishes its turn or needs input, then return its status and last reply (default 10 minutes, at most 1 hour) |
| Start and steer | create_thread (a first message; optionally provider, model, title and a new worktree), send_message (queued if the thread is busy), interrupt_thread, set_thread_title, archive_thread |
| Propose | propose_automation: a card in the agent's own thread; created only if you accept it (chapter 12) |
| Browser | browser_open, browser_snapshot, browser_query, browser_console, browser_network, browser_screenshot, browser_reload, browser_click, browser_fill, browser_press, browser_wait and the journey tools browser_save_journey, browser_run_journey, browser_list_journeys (chapter 10) |
Projects can be named by id, name or path. A thread cannot wait
for, interrupt or archive itself. The browser tools work on the
caller's own thread; other clients pass a thread_id.
What an agent may do on its own
- Tool calls follow the thread's permission mode like any other tool. In Ask for approval mode you approve each one.
- An agent may read any thread, but the first time it messages, stops, renames or archives another thread, Workspace asks you: Don't allow, Allow once or Always allow. Always remembers that pair of threads; Settings → Agents & MCP → Agents changing other threads shows how many are remembered and forgets them.
-
Threads an agent started with
create_threadare its own, so it is not asked about those. - Paired clients such as Claude Desktop are not asked: pairing them was the permission.
- Browser actions in a page are asked about as chapter 10 described, and the browser tools only open and read pages served from this Mac.
Connecting Claude Desktop, Codex or Claude Code
Under External clients in Settings:
- Press Pair read-only client or Pair full-access client. Read-only clients can list, read and wait, but not change anything.
-
Use the copy buttons on the new client: Copy Claude
Desktop config (JSON for
claude_desktop_config.json), Copy Codex config (a block for~/.codex/config.toml) or Copy Claude Code command (aclaude mcp add …command to run in a terminal). - Paste it, and restart the client if it needs that.
Claude Desktop and Codex start Workspace's built-in bridge, which passes their requests to the running app. Elyra Workspace must be running for this to work. The server's port is kept between launches, so pasted configs keep working. Revoke (the trash icon) removes a client, and its token stops working at once; the list shows when each client was last used.
Start with Pair read-only client. Reading a thread is what most outside tools need, and it cannot change anything.
The audit log
Activity in the same Settings page lists the latest calls, newest first: time, caller (a client's name, or agent: thread title), tool, arguments, and whether it succeeded. Workspace keeps the latest 5,000 entries. It is the place to look when a thread did something you did not expect, and the reason the gateway is acceptable to leave on: nothing an agent does through it is unrecorded.
What you learned
- What the gateway is, where it listens and how it is guarded
- Which agents support it, and that Pi does not yet
- How an agent splits a job, and why it should ask for worktrees
- What an agent is asked about before it changes another thread, and what it is not asked about
- How to connect Claude Desktop, Codex or Claude Code, and why to start read-only
- How to read the audit log