agent-pool for Google AI and Gemini CLI adds pipelines, cron and bounce-back

A new open-source agent orchestration layer has appeared for Google AI and Gemini CLI. The agent-pool MCP server stitches scattered delegations into pipelines, can send tasks back for rework, run them on a schedule and move execution to remote machines.

Automatic orchestration

The problem almost every multi-agent setup runs into is simple: the main agent spends too much time on dispatching rather than on actual work. If steps depend on each other (analysis, refactoring, tests, deployment), the orchestrator has to poll statuses, parse responses and launch the next executor by hand. agent-pool moves that logic into a background daemon. Steps and dependencies are described up front through create_pipeline, and the process keeps running even after the IDE restarts.

The key idea is not just to launch a worker, but to give agents a language of coordination. When a stage finishes, the executor sends a readiness signal, and if data is missing, the task can go back for rework with an explanation of why. This bounce-back resembles Request Changes in code review: the previous step supplements the artifact and passes it down the chain again. That makes the pipeline not a linear script but a managed loop with a cap on the number of returns.

"A worker can delegate tasks further on its own — the whole of fractal

orchestration is built on this."

The article describes the main mechanisms of this scheme:

• on_complete — starts the next step after a specific worker finishes
• on_complete_all — waits for the whole group and does a fan-in before the next stage
• on_file — reacts to a file appearing on disk
• signal_step_complete — tells the daemon that the step is truly finished
• bounce_back — returns the task back, while maxBounces limits the number of cycles

Cron and SSH

Scheduling is a separate feature. The schedule_task tool uses the standard cron format, so an agent can be set to run daily or hourly without a separate scheduler. Importantly, the daemon takes atomic file locks: even if you open several IDE windows at once, the same job runs only once. Results go into the scheduled-results folder, so the scenario works for routine server checks as well as for periodic assembly of weekly reports.

If the local machine is not enough, workers can be sent to a remote server over SSH. The runner is described in the agent-pool config, after which specific tasks start executing on a dedicated machine with Gemini CLI installed. The practical value is clear: tests, refactoring or bulk code analysis keep going even after the laptop is closed. The author describes a typical workflow like this: agents work in a separate branch, make commits and push the result, and in the morning the developer simply opens a pull request and reviews the outcome.

Context and control

Another useful detail is passing context between agents through Gemini CLI's built-in sessions. One worker can finish its research and save a session_id, and the next picks up the same conversation and continues without a repeated retelling of what was found. For long chains this saves tokens and reduces errors at the joints between stages: the second agent sees not a dry summary but the full history of the analysis. Active sessions can also be viewed separately and, if needed, joined manually.

There is also a layer of restrictions needed for real teamwork. Through policy, an agent can be given a read-only mode or safe editing without the right to run commands. If that is not enough, rules can be set more precisely in a separate YAML file. The include_dirs parameter complements this model: by default a worker sees only the working directory, and access to external configs or extra folders must be enabled explicitly. This approach makes automation noticeably safer than unconditional full access to the whole project.

Finally, agent-pool introduces groups, essentially templates for fractal teams. A group can store a runner, a skill, a policy and a max_agents limit once, and then dispatch several executors from it at once without duplicating settings. These groups persist across IDE restarts and plug directly into pipelines. If a step must run in parallel, the daemon spins up several agents, hands them indexes and waits for the combined result. Fail-fast applies: if one worker crashes with an error or sends a bounce-back, the other processes are cancelled immediately so as not to burn time and resources for nothing.

What this means

For developers, this is a signal that AgentOps is starting to move from experiments to everyday tools. When pipelines, a scheduler, remote runners and permission control come together around a single Google AI subscription, multi-agent scenarios become working infrastructure for code, tests and routine automation rather than a demo.