Some thoughts on orchestration layers
History
Most people use AI chat, which lives in your browser window and saves every conversation in a little sidebar. To discern important chats, you're able to mark favorites and organize them under projects, but otherwise the usage remains pretty simple. The need for agent orchestration arose from Claude Code, which lives in your terminal and is able to run code by itself. While you're generally able to resume sessions, it wasn't quite as friendly as resuming a chat - since you can't scroll through sessions as conversations. Finally technical reasons like context size, unsafe credentials storage, and the terminal being interruptible; meant you could benefit from an extra layer between the user and the model.
Clawdbot, Moltbot, Openclaw
The first iteration of an orchestration layer was a project by Steipete, which linked your Claude Code to any messaging app, notably whatsapp and telegram. It required an always-on computer to run the gateway and the Claude Code installation, so many users opted for a mac mini (to use the OS alongside openclaw) or a VPS (to run openclaw as a server). This way you could continue your session away from the computer, albeit in a hacky way, by putting the chat on existing message platforms. Power users would set up multiple telegram channels to steer more sessions at a time, making telegram the orchestration layer in this case.
Harnesses
Adoption of Claude Code incited other frontier labs and companies to create their own CLI tools, which became categorized as AI harnesses. These remained the first-class way to interface with AI, steadily solving the problems by putting more the AI behind more layers. Dangerous commands now trigger an approval request in the harness, entering credentials uses separate input, and context can be compressed. The harnesses also became feature-rich, adopting the MCP connector standard, skills, and mobile handoff, which used to be exclusive to openclaw.
Agentic AI
Now that your AI session has more power and continuity, it behaves less like an AI chat and more like an AI agent. It's worth focusing on specific features that make use of this paradigm shift.
/goal
A long-running session that continues the AI turns until it achieves its goal, stopping only for permission approvals and for actions that require a human operator.
Subagents
Spawns fresh sessions that answer to the main agent session. This is especially useful for keeping context down to a manageable size. In this case our main agent is another orchestration layer itself.
Cron jobs, webhooks
Anything that triggers another turn autonomously, without user input.
System prompt, SOUL.md
Global instructions that are injected into context on every new session, required for steering the agent.
What makes a good orchestration layer
- The control plane should be accessible from any device.
- The interface should match the purpose of the agent.
- The agent should not leak credentials in plaintext.
- The chat sessions should be persistent.
- The user should have root on the agent environment.
Examples
A CLI-oriented workflow can use tmux as the interface, connect to a VPS hosting the agent, and use the harness to control agent sessions. An assistant workflow can use messaging gateways to capture messages, handle them appropriately, and report back to a central place like a home channel.
Grok Bot
Has it all, it's the best orchestration layer.