Human–Agent Team Collaboration: From Managed-Agents Principles to Multica Practice

on Jun 6, 2026, tagged translations, ai-agents, ai, processes, collaboration (share this post, e.g., on Mastodon or on Bluesky)

I. Managed-Agents Principles

1.1 Background: From Monolithic to Fully Managed

As large language models continue to advance in tool-use and autonomous decision-making, AI agents have gradually penetrated various R&D scenarios. However, monolithic agents commonly suffer from tight architectural coupling, high operational overhead, inability to collaborate as a team, and difficulty reusing and accumulating capabilities. The root causes are:

• Most monolithic agents bundle the inference loop, credential management, sandbox execution, state storage, and exception retry logic all into a single codebase. Creating a new agent requires repeatedly writing infrastructure code, resulting in low development efficiency.

• At the same time, various agents are deployed across different terminals and AI tools (Claude Code, Codex, OpenCode, etc.), making it impossible to distribute tasks uniformly or monitor execution progress centrally. Experience gained from individual agent deployments cannot be transformed into general capabilities reusable by the team.

Against this backdrop, managed agents (fully managed agents) have emerged as a new engineering paradigm. The core idea is:

Decouple the agent’s decision logic from its underlying runtime infrastructure. The platform takes over unified orchestration, runtime management, session handling, and secure sandboxing across the full chain.

Developers only need to focus on the agent’s business goals and capability definitions; underlying scheduling, resources, and operations are handled by the managed layer.

Currently, mainstream vendors such as Anthropic and OpenAI have successively launched managed-agents services. The open-source project Multica is a benchmark implementation of managed agents for team-based collaboration, bridging the gap from managed theory to production R&D and enabling integrated management of human–agent hybrid teams.

1.2 Core Concept: Decoupling the “Brain” from the “Hands”

Managed-agents definition: A fully managed infrastructure for building, deploying, and running AI agents at scale. The core design revolves around component decoupling and layered abstraction, addressing pain points in long-cycle AI agent development and production deployment.

Managed-agents design philosophy: Completely separate an agent’s “decision capability” (the model as the “brain”), “execution capability” (tools/sandbox as the “hands”), and “memory capability” (persistent sessions as memory).

Drawing on operating-system layering concepts, the agent architecture is restructured so each module evolves independently, improving overall system stability. This solves problems in traditional agent development such as tightly coupled agent code and environment crashes causing task interruptions.

Managed-agents core modules:

• Harness (replaceable control loop): Serves as an abstract control layer that isolates model implementations from system functions. It is responsible for scheduling models and routing tools, allowing models to be upgraded at any time without affecting system stability, and enabling model-specific patches to evolve independently.
• Sandbox (isolated execution environment): Provides independent code/file execution units. The execution environment is physically isolated from the core system, preventing tool-call exceptions or container crashes from failing the entire task. Errors are converted into handleable, isolated exceptions.
• Session (persistent logging): Breaks through traditional context-window limitations by treating the complete historical event log as an externalized memory store. It supports on-demand reading, historical replay, and key-slice extraction, solving information storage and backtracking problems in long-running tasks.

1.3 Architecture Design: Four Foundational Objects

A standardized managed-agents system consists of four entities—agent, environment, session, and events—which form the foundation of the entire architecture:

• Agent (agent template): The capability-definition carrier. Model selection, system prompts, and available toolsets are preconfigured. Once defined, it can be reused by countless tasks, corresponding to a position or role (e.g., code review agent, deployment agent).
• Environment (runtime environment): An isolated execution space that distinguishes between local terminals, cloud servers, and container clusters. It limits the filesystem, network, and resource ceiling. Executions in different environments are isolated from one another.
• Session (task instance): A single task execution launched by an agent in a designated Environment. It is bound to a task ID, start/end states, and a board. It spans the full lifecycle of queuing → dispatching → executing → completing.
• Events (event stream): Full-chain operation logs. Every thought, command execution, error, and human intervention generates an immutable event, serving as the raw data source for observation, post-mortems, and skill accumulation.

1.4 Workflow: Full Lifecycle of Managed Execution

Managed-agents task execution flow:

• Task dispatch: The business side (human or system) binds a task to a designated agent, and the platform writes it to the task queue.
• Polling and pull: Remote or local runtime daemons poll the queue at regular intervals, pull pending tasks, and create independent Sessions.
• Isolated execution: The runtime initializes a sandbox environment, injects credentials, invokes the Harness to start the inference loop, and calls external AI tools on demand.
• Status reporting: During execution, Events are pushed in real time. Blocks and exceptions automatically update task status and post alerts.
• Wrap-up and archiving: After task completion or termination, all events are persisted to the database. High-quality execution chains can be distilled into standardized, reusable skills.

II. Multica Introduction

2.2 Multica Core Features

a. Agent as Team Member (agent role-based hosting):

Implements the agent entity definition from managed agents. Each agent has its own profile, name, and identity. It appears alongside human developers on the project board and in issue comments. Humans can assign board issues directly to the corresponding agent, just as they would assign tasks to an employee. The agent can comment autonomously, update task status, and flag blocking reasons, enabling unified personnel (human + AI) management.

b. Local Daemon + Cloud-Controlled Dual-Layer Runtime (Environment implementation):

Follows the managed-agents environment-isolation specification:

• Cloud control: The web board, task queue, skill library, and event storage are unified for task dispatching and full-chain observability.
• Local daemon (Multica daemon): Deployed on the developer’s local machine or business server. It automatically scans locally installed AI programming CLIs and serves as a localized Environment.
• The daemon polls the cloud for tasks every 3 seconds and reports a heartbeat every 15 seconds. Task data, credentials, and source code remain on the local machine throughout; the cloud never touches any sensitive business data, balancing managed control with data compliance.

c. Full-Chain Task Lifecycle Hosting (full-process Session management):

Follows the managed-agents session lifecycle: task enqueue → agent claims and dispatches → local sandbox starts execution → real-time progress reporting → block/success status change → execution archiving. The full process pushes runtime logs via WebSocket in real time. Developers do not need to stand watch; they only intervene at code review and exception-blocking nodes.

d. Skill Library Accumulation (Events value reuse):

III. Multica Deployment in Practice

3.1 Mode Selection

The execution layer is identical in both modes (local daemon + local AI tools execute tasks). Only the control service (backend, board, database, workspace) deployment location differs, perfectly aligning with the managed-agents core design principle of decoupling the control layer from the runtime.

Choose based on actual needs:

• Choose cloud: Insufficient ops staff, short-term projects, rapid validation, or no concern about task metadata going to the cloud.
• Choose self-host: High data-compliance requirements, internal private code repositories, long-term scaled adoption, or need for internal system integration.

3.2 Prerequisites

There is only one prerequisite: you already have at least one AI programming tool installed locally (Claude Code, Codex, OpenCode, Pi, etc.). The daemon will auto-detect them on startup. If none are installed, the daemon will refuse to start.

My computer has Claude Code, Codex, and OpenCode installed. The following examples use these three.

3.3 Cloud Mode Deployment

Step 1: Register a Cloud account:

Visit Multica—Project Management for Human + Agent Teams to register an account, create a workspace, and enter the board.

Step 2: Install the agent daemon (CLI or desktop client):

• CLI method: For macOS, install via Homebrew:

  brew install multica-ai/tap/multica

• Desktop client method: Visit Download Multica and download the version for your OS.

Step 3: Start the daemon and connect to the control plane:

• If using the CLI: Run multica daemon to start the local daemon. It will auto-connect to the cloud service and complete environment registration.
• If using the desktop client: Launch the Multica client. It will automatically guide you through binding to the cloud service and completing environment registration.

3.4 Self-Host Mode Deployment

Step 1: Clone the project and one-click start the backend:

Run the following commands in your terminal. This will:

• Auto-generate an .env file from .env.example and generate a random JWT_SECRET if .env does not exist.
• Pull official Docker images (PostgreSQL, Multica backend, Multica frontend).
• Start all services via docker-compose.selfhost.yml.
• Wait until the backend /health endpoint is ready.

For production use, refer to the documentation to customize security configuration, email, ports, etc.

git clone https://github.com/multica-ai/multica.git
cd multica
make selfhost

After startup, access the following service addresses:

• Frontend: http://localhost:3000
• Backend: http://localhost:8080

Step 2: First login and workspace creation:

Visit http://localhost:3000 and perform the following actions:

• Enter your email.
• Retrieve the verification code from the email sent by your configured mail backend (Resend or SMTP relay). If neither is configured, copy the [DEV] Verification code line from the server container’s stdout.
• After logging in, create your first workspace.

Step 3: Start the daemon and connect to the control plane:

Same as step 3 in cloud mode; omitted here.

IV. Human–Agent Team Collaboration Case Study

4.1 Team Organization Design

For human–agent team collaboration, the first step is to perform team organization design based on business scenarios, defining team roles and responsibilities. Here we use “full-stack project iterative development” as the business scenario to practice a multi-role agent team collaboration.

For the R&D requirement delivery process, the general stages are requirement analysis, solution design, code development, code review, requirement testing, and project deployment.

Among these, “requirement analysis, solution design, and code development” are long-duration, low-risk tasks suitable for agent roles. The other stages are relatively high-risk; in the short term (as in this case study), they remain handled by humans, with future consideration for handing them off to agents.

Based on the above division of labor, the specific team organization design is as follows:

• Team name: Three Heroes of Han (Mozi–Xiao–Zhang Alliance)
• Team roles: 3 Agent roles (Squad Leader, Architect, Full-Stack Engineer) + 1 human role.

The former handles “requirement analysis, solution design, and code development” work; the latter handles “code review, requirement testing, and project deployment” work.

Agent role details:

Agent role instructions:

• Xiao He (Squad Leader):

### Core Positioning

The team’s sole external interaction entry point and full-process chief scheduler. Bears the core responsibilities of “task decomposition, progress tracking, and result aggregation.” The anchor of the entire squad.

### Detailed Responsibilities

1. Receives raw user requirements, decomposes vague, broad requirements into reasonably granular, independently executable standardized subtasks, and pushes them in orderly sequence according to role division without overstepping work assignments.
2. Tracks each role’s task progress throughout. When tasks are blocked or outputs do not meet requirements, automatically triggers rescheduling to ensure the process does not stall, and synchronizes information at each node to prevent information gaps.
3. Finally aggregates the planner’s solution documents and the engineer’s execution results, integrating them into a complete deliverable with clear logic and strong readability, and uniformly outputs it to the user.
4. Manages global conversation context, filters invalid interactions, compresses redundant information, improves collaboration efficiency, and reduces unnecessary resource consumption.

### Authority Boundaries

Only responsible for scheduling and aggregation. Does not participate in specific solution design or write execution code. All concrete work is delegated to the corresponding roles. Never oversteps boundaries.

• Zhang Liang (Architect):

### Core Positioning

Core solution output. Bears the core responsibilities of “information research and complex task solution design.” The central hub connecting requirements to implementation.

### Detailed Responsibilities

1. Based on tasks decomposed by the coordinator, completes external information retrieval, industry solution collection, competitive analysis, and dependency information collation, outputting objective, neutral research conclusions without mixing in subjective prejudgments.
2. Based on research results, outputs structured, implementable complete solutions: including overall framework decomposition, module interface definitions, path selection comparisons, execution step sequencing, and potential risk annotations. Solutions clearly distinguish must-do items from optional items, leaving clear room for subsequent execution.
3. After outputting a solution, performs feasibility verification independently. When information is missing, clearly annotates the uncertain scope, does not fabricate conclusions, and does not pass erroneous guidance to subsequent execution.

### Authority Boundaries

Only outputs design solutions. Does not participate in concrete implementation. When requirements change, only modifies the solution; does not overstep to modify execution results.

• Mozi (Full-Stack Engineer):

### Core Positioning

Core executor of long-cycle tasks. Bears the core responsibility of “long-duration, independent complex task execution.” The problem-solver who transforms paper solutions into actual results.

### Detailed Responsibilities

1. Strictly follows the design solution output by the planner, independently completes code development, feature debugging, configuration modification, and other implementation work. Does not require coordinator involvement in details throughout, and supports long-duration offline/background execution.
2. After completing development, automatically performs basic functional self-testing, independently fixes syntax errors, simple logic defects, dependency conflicts, and other common problems. Only when encountering solution-level conflicts or design flaws does it return the problem to the coordinator for rescheduling and replanning.
3. After execution completes, outputs a clear delivery checklist: including change records, environment dependency descriptions, deployment and startup steps, and clearly annotates content requiring manual user adjustment, leaving no untraceable black-box modifications.

### Authority Boundaries

Only executes within the scope of the design solution. Does not modify the overall framework on its own or extend extra functionality beyond the requirement scope. All out-of-bound requirements are uniformly returned to the coordinator for reprocessing; no private solution adjustments.

Multica system screenshots:

• Multica squad—team settings + member organization (3 agents + 1 human):

  

• Multica agent—agent role configuration information:

  

Taking Mozi as an example, configuration includes: runtime (local MacMini + OpenCode) + agent model (DeepSeek) + skills (design-taste-frontend) + instructions, etc.

Multica Runtime: My computer has Claude, Codex, and OpenCode installed; as shown below, all are detected as available.

4.2 Team Collaboration Rules

Team collaboration rules are carried by squad instructions. Squad instructions are injected into the leader agent’s prompt when it processes issues assigned to that squad. They provide the Leader with team-wide guidance, collaboration norms, or context that should be followed for every task.

Squad instruction design:

## Squad Positioning

A professional multi-agent framework for closed-loop, implementation-oriented complex tasks. Clear division of labor without redundancy. Adapted to the full flow of “requirement → design → implementation → delivery.”

### Role 1: Lead Coordinator—Xiao He

Core functions: Task decomposition → Progress tracking → Result aggregation

* Sole external interface. Receives raw user requirements and decomposes them into standardized subtasks.
* Schedules tasks by process, tracks progress, and automatically reschedules when blocked.
* Aggregates planning + execution results, organizes them, and outputs to the user.
* Manages context and filters redundant information.
Mandatory boundary: Only schedules and aggregates. Does not design solutions or write execution code.

### Role 2: Strategic Planner—Zhang Liang

Core functions: Information research → Complex task solution design

* Based on decomposed tasks, completes information retrieval, competitive/technical research, and outputs objective conclusions.
* Outputs structured, implementable solutions: including framework decomposition, interface definitions, selection comparisons, execution sequencing, and risk annotations.
* Self-verifies solution feasibility. Clearly annotates missing information; does not fabricate content.
Mandatory boundary: Only outputs design solutions. Does not perform implementation or respond directly to users.

### Role 3: R&D Engineer—Mozi

Core functions: Long-duration independent execution of complex implementation tasks

* Strictly follows the design solution to independently complete implementation, supporting background long-cycle execution.
* Performs basic self-testing independently and fixes simple problems. Only reports solution-level problems to the coordinator for rescheduling.
* Delivers a clear checklist: including change records, dependency descriptions, usage steps, and annotations for manual adjustments.
Mandatory boundary: Only executes within the solution scope. Does not modify architecture or extend beyond requirements.

## Standard Flow

User initiates requirement → Xiao He decomposes and schedules → Zhang Liang researches and outputs solution → Mozi independently executes → Xiao He aggregates and integrates → Deliver to user

## Exception Rules

* Research lacks information: Zhang Liang → Xiao He → User supplements, re-research.
* Solution has flaws: Mozi → Xiao He → Zhang Liang adjusts solution.
* Result does not meet requirements: User → Xiao He judges problem node → Corresponding role adjusts and re-outputs.

4.3 Case Scenario

The following case quickly demonstrates the Multica system’s operating mechanisms, including multi-agent scheduling, session isolation, event tracing, and skills.

Case scenario description:

• Case scenario: “Build a new blog website, containing only frontend HTML pages; no backend logic needed.”
• Requirement acceptance: Handled through Multica’s squad/team, demonstrating multi-agent scheduling, session isolation, event tracing, and skills throughout the process.

Multica process analysis:

The Multica flow is shown in the figure below. The core steps are:

• Initiate task: User submits an ISSUE and assigns it to the Multica team—here, to the “Three Heroes of Han (Mozi–Xiao–Zhang Alliance).”
• Requirement analysis and task assignment: After the team receives the requirement, “Xiao He (Squad Leader)” automatically extracts functional points. Then, the solution design task is assigned to “Zhang Liang (Architect).”
• Technical solution: “Zhang Liang (Architect)” receives the task and, combining synchronized requirement information and proactive research, designs the technical solution. After the technical solution is complete, “Xiao He (Squad Leader)” is notified.
• Solution review: “Xiao He (Squad Leader)” receives the technical-solution completion notice and performs a technical solution review. Then, the development task is assigned to “Mozi (Full-Stack Engineer).”
• Code development: “Mozi (Full-Stack Engineer)” receives the task and begins code development. After code development is complete, “Xiao He (Squad Leader)” is notified.
• Code acceptance: “Xiao He (Squad Leader)” receives the code-development completion notice and performs code acceptance. After acceptance is complete, the task status is automatically updated.
• Requirement testing and project deployment: According to the organization design above, this part is handled by humans. Therefore, it is manually triggered by “Jason (me).”

Multica core step diagram:

• Requirement analysis and “technical solution” task assignment: Xiao He (Squad Leader) → Zhang Liang (Architect):

  

• Technical solution complete: Zhang Liang (Architect) → Xiao He (Squad Leader):

  

• “Code development” task assignment: Xiao He (Squad Leader) → Mozi (Full-Stack Engineer):

  

• Code development complete: Mozi (Full-Stack Engineer) → Xiao He (Squad Leader):

  

• Project delivery: Xiao He (Squad Leader) → Project members:

  

• Project deployment: Jason (me) → Mozi (Full-Stack Engineer):

  

• Screenshot of the blog website in operation：

  

(This post is a machine-made, human-reviewed, and authorized translation of xuxueli.com/­blog/­?blog=ai/­multica.)