All case studies

Agent OS.

Multi-Agent Coding Orchestration System

A persistent orchestration layer for Claude Code and Codex. Coordinate agents, workspaces, approvals and scheduled execution from Feishu / Lark.

Area
Agent systems
Implementation focus
Engine adapters, workspace routing, persistent sessions, approvals and scheduled execution.
What you can inspect
Watch an 84-second recorded task, from dispatch to a follow-up in the same native session.

Agent OS in action

84 seconds of real execution: task dispatch, human approval, Claude Code implementation and a follow-up in the same native session.

Synthetic demo repository · Waiting time condensed · English synthetic narration · Private conversation sidebar cropped.

Transcript and verification

A task arrives in Feishu: build POST /sum and regression tests. The team lead dispatches a product agent, which creates a specification for human approval. Once approved, local Spec/Tickets guide the developer using Claude Code. The initial implementation passes 9 tests.

A follow-up limits input to 100 numbers: 100 are accepted and 101 are rejected. All 11 tests pass. The developer’s native session identifier was compared before and after the follow-up and remained unchanged. These are results from this demo run, not production metrics.

The problem

A coding agent can execute a task. Coordinating multiple agents over time introduces a different set of problems: choosing an engine, preserving session context, routing work to the right repository and waiting for a human decision without losing the task.

How the pieces fit

A conceptual view of the orchestration responsibilities, mapped to the source modules below. Workspace boundaries select working directories; they are not an operating-system security sandbox.

Key engineering decisions

Separate orchestration from the engine

Claude Code and Codex sit behind a CLI adapter contract. Dispatch and session management work with an engine identity instead of embedding provider-specific execution throughout the runtime.

Persist the conversation boundary

Sessions are keyed by bot, chat and thread, with a separate native CLI session ID. Changing the workspace clears that native ID so context is not silently reused in another repository.

Make human approval a first-class state

Product-document review and task execution have distinct boundaries. Approval records and resumable sessions let the conversation wait for a decision before authorized work continues.

Reliability & failure handling

State transition rollback

Session changes are persisted. When saving fails, the in-memory state is restored rather than reporting a transition that was never saved.

Interrupted schedules stay visible

On startup, schedule runs left in a running state are marked failed with an interruption reason. A process restart is not silently reported as successful execution.

Explicit execution boundaries

Workspace selection, engine identity and approval scope are inspectable. The CLI runs with the host account’s permissions; deployments still require appropriate host isolation.

Evidence & scope

Source links are pinned to the reviewed revision so you can follow each implementation detail.

What this case establishes

Source-reviewed orchestration behavior. No production availability or customer deployment claim is made.

Continue exploringRAGOps Studio