Orchestrator agents > supervisors, on-completion triggers

[leventov]

This blog post: https://agor.live/blog/orchestration-layers describes three distinct mechanisms to push the work forward:

• Orchestrator agents:

Imagine an agent that:

Implements a feature
Spawns a test-writing agent
Spawns a review agent to check for edge cases
Spawns a docs agent to update documentation
Reports back with a complete PR

• Supervisors on a Schedule
• On-completion triggers for zones

It seems to me that orchestrator agents are strictly superior to the other two mechanisms and cover all the needs. Why we need "Supervisors on a Schedule" that are only triggered once every hour when the results or the current blockers of the subagents, if reported back to the orchestrator agent, could be addressed intelligently by the latter just-in-time, without a delay. In addition, the orchestrator agent might decide to pause other subagents if one of the subagents have reported serious problems that might require significant rework. The orchestrator has full context of the task to proceed (or decide human attention is needed) in the most intelligent way.

For "on-completion triggers for zones" -- orchestrator agent's prompt or instructions should contain exactly the guidance for moving the work between zones, intelligently. Automatic triggers are too dumb. For example, my workflow is that GPT-5.2 and/or Gemini generally reviews Claude's work, but for very simple one-line fixes that would just add latency and work without benefit -- orchestrator agents are exactly the place where intelligent decisions of this sort should be done. Exactly the same applies in your own workflow - https://agor.live/blog/context-engineering - you describe how "subagent for backend/frontend" or "single-shot everything" is intelligence-laden decision - I think orchestrator agents should be able to make a good educated guess.

Orchestrator agents could be hierarchical -- if the orchestrator sees a good chunk of work that it suspects will pollute its own context too much, it may spawn it into an async subagent which itself an orchestrator and knows it is a child of another orchestrator and they can communicate intelligently, but without overburdening each other context.

[leventov]

Another thing about orchestrators -- I think they should be excellent about triaging "open subagent loops" (i.e., situations where a subagent has stopped and awaits the input to continue) between automatable ("fix it", "proceed", etc.) and those that genuinely require human attention. For those that genuinely require human attention, orchestrators should label those subagents as such via some specialized tool call/mcp so that they appear in the global (or root loop-scoped) loop tray/stack that the human should attend to.

Orchestrators may decide that humans must review something not only because subagents or orchestrators don't know how to proceed or don't have a good idea, but also to let humans learn something about the decisions that they made or small things about the project that they found.

In the blog post, this phrase:

You prompted once. Four agents collaborated. You reviewed the output.

Really rubbed me the wrong way. I think "review everything at the end" is the sure recipe for "LGTM" style reviews and losing one's grip on the system. I think human attention and feedback must be as immediate/just-in-time as possible. I think "PR reviews" is too bulky of a process and should be a thing of the past; stacked PRs are bandaids. The future review/feedback/learning process should look like "group vibe coding / multi-conductor orchestration" that you described, but this requires intentional attention engineering being first-class concern of the system. My hunch is that is what "orchestration layers will teach us".

[mistercrunch]

Super good input. Agent orchestration is early, and Agor enables lots of things that are not possible elsewhere: agents reviewing other agents work and taking direct actions - while offering visual clarity around what's happening.

Seems between "agents on a schedule" and "zone-post-prompt-triggers" (not implemented), one can/could do a lot of things and implement arbitrarily complex workflows. Prompts like "review the work ... depending on complexity ... move to the 'Codex review zone' ... if less complex, move to the 'human review' zone, ...". Human in the loop + notification not fully solved, but if you have say a Slack MCP you can "please notify the owner via Slack MCP" and such.

About "agent on a schedule", they have clear virtuous use cases beyond supervision. Something as simple as "please produce a weekly report of everything that happened on this Agor board this week" or AI-enabled crontab-type use cases, like an "intelligent cron".

As to how these workflows should be expressed, with AI-in-the-loop, we might need more of a "workflow engine"-type UI, as opposed to just prompts and prompt triggers.

Clearly haven't solved all the things yet... and multi-agent / orchestrator-agent workflows patterns aren't well defined as of yet. Yet Agor is probably the one of the few places where any of this is actually possible to have agents review other agents' work and post-prompt or trigger new agents.

Personally, where I'm at in my workflows working with Agor: I have many boards, typically one per repo, and tend to manage 5-10 agents in parallel, and move worktrees manually from zones to zones. As my workflow become more clear, I have a few agents on a schedule the move things from zones to zones, but pretty experimental still. Feels like we're not quite at the place where all the unsupervised, fully automated, little-human-in-the-loop can be achieved model-wise, but clearly it's coming and will be building to support that.