Skip to main content
The introduction promised that agentic systems are built from familiar programming primitives. Part 1 explored those primitives individually—context, memory, agency, reasoning, coordination, artifacts, autonomy, evaluation, feedback, and learning. The rest of this chapter combines these elements into a complete working system. A virtual office is a team of software agents that work like a small company: tasks come in, a coordinator distributes them to appropriate workers, workers execute tasks and report results, a human manager provides oversight and handles escalations. This pattern applies to many problems where work is distributed across roles and tracked in a queue, such as content production, research operations, development workflows, and support systems. We build a virtual office that routes tasks through a coordinator, specialized workers, and a shared task board. The virtual office uses all ten elements from Part 1 in a single multi-agent system.

11.1 The System We’re Building

Before diving into code, let’s understand the architecture. The virtual office has four types of components: The Coordinator is the system’s brain. It receives incoming tasks, classifies them, assigns them to appropriate workers, monitors progress, handles stuck tasks, and escalates when necessary. The coordinator maintains the task board and makes routing decisions. Workers are specialized agents that execute specific types of tasks. A code worker writes and debugs code. A research worker gathers information and synthesizes findings. A writing worker produces documents and communications. Each worker has focused capabilities, relevant context, and appropriate tools. The Task Board is a shared artifact—a kanban-style board where tasks move through columns (backlog, in-progress, review, done). The coordinator and workers interact with the board to claim tasks, update status, and record results. The board makes system state visible to everyone, including the human manager. The Human Manager provides oversight. They can add tasks, approve high-stakes actions, review completed work, provide feedback, and intervene when things go wrong. The system is designed to operate autonomously but remain controllable.
The information flow is straightforward: tasks enter through the human manager or external triggers, the coordinator routes them to workers, workers execute and update the task board, the coordinator monitors and handles completion, and the human manager reviews results and provides feedback. This flow manifests all ten elements from Part 1.

11.2 The Task Board Artifact

Every multi-agent system needs a coordination mechanism. The task board serves this role—a shared artifact that makes work visible and provides operations for managing it.
The task board stores tasks and enforces workflow rules through its methods. The task board exposes methods like addTask, assignTask, and completeTask that enforce valid state transitions (for example, only in-progress tasks can move to review). The task board encapsulates workflow rules in one place: instead of scattering status checks across the system, you call its methods to enforce valid state transitions. Tasks can only move forward through certain transitions. Assignment requires the task to be in backlog. Completion requires it to be in-progress with a result. These constraints are enforced by the artifact’s methods, not by code scattered throughout the system.
The task board demonstrates several elements working together. It’s an artifact with semantic structure and typed operations. It provides memory that persists task state across sessions. The event history supports evaluation by tracking what happened when. The status transitions encode workflow rules that support coordination between components.

11.3 The Coordinator

The coordinator decides which worker should handle each task, monitors progress, and escalates problems—centralizing routing logic that would otherwise be duplicated across workers.
The coordinator demonstrates coordination patterns—routing tasks to appropriate workers, monitoring progress, handling exceptions. It implements autonomy through scheduled coordination cycles that run without human prompting. The escalation mechanism provides human-in-the-loop integration, pausing for human input when automated handling fails. The coordinator never executes tasks itself; it only routes work and handles exceptions. Its job is meta-work: ensuring tasks flow correctly, workers are utilized effectively, and problems get handled. This separation of concerns keeps each component focused. To make performance-aware routing useful, you should update WorkerInfo.metrics[taskType] whenever tasks complete—for example, incrementing success and failure counts and recomputing successRate and avgDuration. The default 0.5 success rate acts as a neutral prior when there is no historical data for a worker and task type.

11.4 The Workers

Workers isolate domain-specific prompts, tools, and reasoning patterns from routing: a code worker focuses on implementing and validating code, while the coordinator just hands it the right tasks.

The Code Worker

The code worker uses a plan-then-implement loop so you can inspect and adjust the plan separately from the code generation prompt. It uses feedback loops—generating code, verifying, fixing based on errors. The agency manifests in its ability to produce artifacts (code) that have effects. Its scheduled work cycle provides autonomy, checking for and executing tasks without external prompting.

The Research Worker

The research worker adds patterns you need for real research tasks: decomposing broad prompts into questions, ranking findings, and persisting useful results. It uses decomposition reasoning to break research tasks into questions. The signal boosting pattern appears in scoring and filtering findings. Memory accumulates through the knowledge store, with high-quality findings persisted for future use—this is learning in action. The streaming findings provide real-time visibility into progress. Knowledge extracted from research tasks persists for future use: subsequent research queries call knowledge.search before external search to reuse prior findings.

The Writing Worker

The writing worker structures writing as draft → critique → revision, so you can plug in different editors or constraints at the critique step without changing the drafting logic. The streaming draft provides visibility into work in progress. The self-critique demonstrates the generate-evaluate pattern from Chapter 4, with separate passes for creation and evaluation.

11.5 Human Manager Interface

The human manager interacts with the system through actions that add tasks, provide feedback, and handle escalations.
The manager interface provides observability—the dashboard shows system state, alerts highlight issues needing attention, and dashboard can feed a UI or API endpoint. In production, you might push updates on state changes rather than polling every minute. The action methods give humans control: they can add work, provide feedback, handle escalations. Evaluation appears in performance reports that track what’s getting done and how efficiently.

11.6 Wiring It Together

The complete system connects these components. In a deployment, each component would run as its own Durable Object communicating through Idyllic’s infrastructure; the following class shows how they connect.

11.7 Elements in Action

The following walkthrough shows how the ten elements appear when the system processes a task. A human manager calls addTask("Implement user authentication", "Add login and logout endpoints with JWT tokens", "code", "high"). The task enters the task board artifact, persisted in memory, status set to backlog. The coordinator’s scheduled cycle runs. It sees the high-priority task in backlog. Reasoning about worker selection considers which workers can handle code tasks, their availability, and performance history. The code worker is selected and the task is assigned—this is coordination through routing. The code worker’s scheduled cycle runs, retrieves its assigned tasks from the board, and starts work on the next one. First, it generates a step-by-step implementation plan via the planning prompt. Then it generates code—agency, producing an artifact with effects. It verifies the code and finds issues—feedback through verification. It fixes the code based on errors and tries again—the iterate loop. After one or more fix-and-verify iterations, the code passes verification. The task moves to review status. The dashboard’s scheduled update notices this and adds an alert—observability. The human manager sees the alert and reviews the work. They might approve (task moves to done) or reject with feedback (task goes back to backlog with the feedback attached for the next attempt). If the code worker had gotten stuck—say, it couldn’t resolve a dependency issue—it would call blockTask with a reason. The coordinator would see the blocked task in its next cycle. After checking if a different approach might work, it would escalate to the human manager. The manager would receive an alert and could decide to reassign, modify the task, or cancel it—human-in-the-loop at work. Over time, performance metrics accumulate. If you update the worker metrics based on completed tasks, the coordinator can prefer workers that have higher success rates on a given task type. You can refine prompts based on failure patterns by analyzing blocked or rejected tasks and updating the worker prompts accordingly. Knowledge extracted from research tasks persists for future use: subsequent research queries call knowledge.search before external search to reuse what the system already knows. The system operates autonomously—scheduled cycles keep work flowing without constant human prompting. But it remains controllable—humans can add tasks, provide feedback, handle escalations, and intervene at any point. This balance between autonomy and control is necessary for production systems, alongside reliability, security, and monitoring concerns covered elsewhere.

11.8 Extending the Pattern

The virtual office pattern adapts to many domains. The same pattern extends to several domains: Content Production Office: Writers, editors, designers, and SEO specialists. Tasks are articles, graphics, and campaigns. The task board tracks content through ideation, drafting, editing, design, and publishing phases. The coordinator balances deadlines against quality. Development Shop: Architects, frontend developers, backend developers, QA engineers. Tasks are features, bugs, and technical debt items. The task board is a sprint board. The coordinator manages dependencies between tasks—some can’t start until others complete. Research Lab: Data collectors, analysts, synthesizers, and report writers. Tasks are research questions that decompose into collection, analysis, and synthesis phases. The knowledge base grows continuously, informing future research. Support Center: Classifiers, handlers by category, escalation specialists, and knowledge maintainers. Tasks are customer inquiries. The coordinator routes by intent and complexity. Successful resolutions feed back into the knowledge base. Here are some variations of the pattern: each variant adjusts the worker types, coordination rules, and artifact structure, but the underlying pattern remains. Tasks flow through a shared artifact, a coordinator manages routing and exceptions, specialized workers execute, humans provide oversight, and the system learns from outcomes.

Key Takeaways

  • A virtual office coordinates specialized workers through a shared task board artifact
  • The coordinator handles routing, monitoring, and escalation without executing tasks itself
  • Workers have focused capabilities, appropriate tools, and domain-specific reasoning
  • Human managers provide oversight through task creation, review, and escalation handling
  • All ten elements work together: context in worker prompts, memory in task state and knowledge stores, agency in task execution, reasoning in planning and decomposition, coordination in routing and handoffs, artifacts in the task board, autonomy in scheduled cycles, evaluation in performance metrics, feedback in verification loops, and learning in accumulated insights

Transition

Chapter 11 demonstrated a complete multi-agent coordination system. Chapter 12: Research System shows a different application—knowledge accumulation and synthesis over extended operation, building a system that gets smarter with every research task it completes.