AI Orchestrators

Instead of Orchestration for data engineering jobs, AI orchestration is all about scheduling and orchestrationg AI Agents.

I’d say the easiest is to use tmux to schedule multiple Claude Codes agents. And you could also extend to run multiple branches of the same repo with git worktrees.

But there’s also specific tools created on the daily basis, below are some of them.

Scheduler tools for AI agents:

• Agor: A next-gen AI Agents orchestration for AI coding by Maxime Beauchemin.
  • claudette-cli by Maxime Beauchemin that probably used for Agor ^b2cd57
• erk: : CLI utility for managing git worktrees by Nick Schrock
• trigger.dev: Build and deploy fully‑managed AI agents and workflows
• Gastown: multi-agent workspace manager by Steve Yegge ^b49c35
• Claude Code native orchestrator called Agent Teams. Check out the docs.
• anvil: IDE for parallel agent work. Create worktrees in one click. Share plans between agents. Execute with parallelism + isolation.
• Solo: Your all-in-one Laravel command to tame local development by Aaron Francis. It’s it’s own Terminal (?), see website.
• Superset.sh: Orchestrate swarms of Claude Code, Codex, etc. in parallel. Works for any agents. GitHub
• herdr: supervise multiple coding agents in one terminal.
• Omnigent: A Meta-Harness to Combine, Control and Share Your Agents by Databricks. GitHub ^037078

For Obsidian, but looks similar

See Voicetree in Second Brain Assistant with Obsidian (NoteGPT)).

• agtop: top-style TUI for monitoring AI coding agent sessions · GitHub

• AgentFS
  • ? similar to Open Table Formats?

In a sense, you can use OpenCode too for this, as it perists sessions. And with tmux you have automatic multiple sessions of OpenCode or Claude sessions.

With data engineering and 15 years of building orchestrators such as Airflow, Dagster, Prefect, Kestra, etc., we are now doing the same for AI agents.

Agor from Max, the original creator of Airflow. Agent Teams from Anthropic, native to Claude Code. Omnigent from Databricks. Superset-sh, herdr, Gastown.

I feel we are reinventing the wheel once again. I already felt that with Vector Databases, see my write-up at Don’t Build a Parallel Stack: Integrate Vectors into Data Engineering Workflow:

The data engineering lifecycle defines the end-to-end data engineering process, addressing all different components. When integrating vector operations into this lifecycle, we should aim to enhance rather than duplicate existing infrastructure. Vector operations should complement, not replace, your well-established data engineering practices.

Just as we don’t replace existing data connectors (like ODBC/JDBC) with each new technology wave, we shouldn’t create an entirely separate infrastructure for AI workloads. Instead, we should leverage existing tools like orchestration, scheduling, and processing frameworks while adding vector capabilities where they provide clear benefits.

This approach prevents duplication, maintains consistency, and leverages your team’s existing expertise. The goal should be to add vector storage and processing capabilities within your existing data engineering cycle, not to build a parallel system.

I continue with Don’t Repeat Yourself with AI Data Pipelines, and also my book on Patterns of Data Engineering started for that reason. Still, I guess it’s easier to build something new than to use existing tools. Obviously, the new tools also have their advantages in the narrow use case, but on the broader level, it’s an orchestrator IMO 🙂.

• AI workflows
• AI IDEs
• Tmux Tweets:
  • Tabs and Sessions
  • zellij: running agents

Origin: