How to Spin Up an AI Agent Team with Raven: A Conceptual Blueprint
How to Spin Up an AI Agent Team with Raven: A Conceptual Blueprint
Evermind's current public Raven release is a pre-alpha self-improving AI agent harness for long-running AI work. This conceptual blueprint describes Raven's next-version multi-agent direction — planner, worker, and reviewer roles coordinating through shared memory and peer review — rather than a capability of the current public release.
EverMind研究人员
About 13 minutes to read
Key Takeaways
• The current public Raven release is a pre-alpha self-improving Agent Harness. The multi-agent team model in this guide reflects Raven's next-version direction, not a capability of the current public release.
• Raven's next-version research prototype reports 56.7% at the 27B tier versus Hermes at 46.8%. These results do not describe the current public release.
• Current Raven setup uses the official installer followed by the raven onboarding flow. The team configurations below are conceptual examples, not current public Raven APIs.
• The conceptual team pattern uses three roles — planner, worker, and reviewer — each with one clear responsibility.
• The proposed team design uses shared memory for sequential and parallel coordination; actual latency depends on the selected memory and deployment configuration.
• In the proposed design, reviewer agents would read producer outputs, apply structured critiques, and pass revised artifacts downstream.
• The current public Raven release includes a skills system, evaluation, and reusable workflows, but the official README does not publish a fixed count of built-in skills.
What Is Raven and Why Use It for a Multi-Agent Team?
Evermind's current public Raven release is a pre-alpha self-improving AI agent harness for long-running AI work. It includes terminal-first execution, local tracing, long-term memory, skills, evaluation, and reusable workflows. The planner, worker, reviewer, and shared-memory patterns in this guide describe Raven's next-version multi-agent direction rather than current public functionality.
There are 3 reasons the proposed next-version design could improve on ad-hoc multi-agent scripting.
First, a structured harness can centralize routing, retry behavior, and memory sharing that ad-hoc scripts otherwise implement separately. In Raven, those multi-agent coordination patterns remain part of the next-version direction.
Second, the proposed design treats peer review as an explicit workflow step. One agent's output would become the input to a reviewer before results move downstream, allowing errors to be caught earlier in the pipeline.
Third, Raven reports results from an internal next-version research prototype: 56.7% at the 27B tier versus Hermes at 46.8%. The official README states that these results do not mean the current public release already supports the multi-agent network. Raven is released under Apache 2.0.
Prerequisites and Setup: Install, Access, and Environment
Running current public Raven starts with the official installer and the raven onboarding flow. Building the conceptual multi-agent pattern additionally requires custom orchestration because the current public release does not expose the team API described below.
Getting Raven from GitHub
Raven is open source under Apache 2.0 and available at github.com/EverMind-AI/Raven. For macOS, Linux, or WSL2, use the official installer and then launch onboarding:
curl -fsSL https://raven.evermind.ai/install.sh | bash
The storage stack Raven expects is Local Markdown + SQLite + LanceDB — no MongoDB, Elasticsearch, or Redis dependency is required. SQLite handles structured agent state; LanceDB handles vector retrieval; Local Markdown stores human-readable memory artifacts.
Free vs. Advanced Setup Paths
Raven onboarding supports local and hosted model providers. A local model can avoid provider subscription fees, while hardware and infrastructure costs still apply.
For hosted providers, run raven and complete the provider connectivity check during onboarding. Configuration covers these areas:
1. Select the provider and model, then enter the required provider credential through the onboarding flow.
2. Choose the sandbox or execution location and configure any chat channels.
3. Configure EverOS memory, Deep Research, and optional cold-start import from other AI tools.
Setup time depends on the provider, model, sandbox, and optional integrations selected during onboarding. The official README does not publish a fixed five-minute setup guarantee, and scaling to a multi-agent team still requires custom work in the current public release.
Defining Agent Roles and Responsibilities in Your Team
For the conceptual team pattern, give each agent one clear responsibility. Role clarity reduces duplicate work and keeps an orchestration graph easier to reason about.
The examples below divide work among specialist roles rather than one generalist agent. Treat them as architecture guidance for Raven's next-version direction, not as evidence that the current public release includes a 13-agent team system or a fixed-size built-in skill library.
The conceptual example starts with 3 roles before expansion.
Example Roles: Planner
In the conceptual team pattern, a planner agent decomposes the top-level goal into an ordered sequence of subtasks. Its instructions restrict it to task decomposition: it emits a structured task list and passes control downstream. Keeping planning separate from execution can make responsibilities and validation boundaries clearer.
Example Roles: Worker
The worker agent receives individual subtasks from the planner and executes them — querying APIs, writing code, retrieving documents, or calling external tools. A team typically runs multiple worker instances in parallel, each scoped to a domain such as web retrieval, code execution, or data transformation.
Example Roles: Reviewer
In the conceptual workflow, a reviewer agent inspects worker outputs against the original task specification before results surface or trigger the next stage. A dedicated review step can catch errors earlier, but its effectiveness depends on the evaluation criteria, model, and task.
The following block is conceptual pseudocode for three roles. It is not a supported current Raven configuration schema:
agents: - id: planner role: decompose system_prompt: "Break the user goal into ordered subtasks. Output only a task list." - id: worker role: execute system_prompt: "Execute the assigned subtask using available skills." - id: reviewer role: validate system_prompt: "Verify worker output against the original subtask specification."
In this pseudocode, each id represents a role that a future orchestrator would route work to.
Configuring Inter-Agent Coordination and Communication
In the proposed team architecture, coordination would rely on a shared memory layer that participants read and write during task execution. Roles would be defined before the team is connected. Multi-agent memory would provide durable state for dependencies, handoffs, and partial results. Retrieval latency depends on the selected EverOS mode and deployment rather than a guaranteed threshold for the current Raven release.
The conceptual workflow supports two coordination patterns: sequential and parallel. Sequential execution passes one role's output to the next; parallel execution runs independent subtasks and merges their results at an aggregator.
The following conceptual pseudocode illustrates a sequential setup; it is not a current Raven configuration file.
coordination: mode: sequential agents: - id: researcher passes_to: writer - id: writer passes_to: reviewer shared_memory: true
In this pseudocode, passes_to identifies the next role and shared_memory represents a shared state layer. Shared memory AI agents can stay aligned when every role reads the same reviewed state, but these fields are not documented current Raven configuration options.
A production multi-agent implementation should serialize conflicting writes or use locks. If two roles write the same memory key, the implementation should queue or reject one write to preserve consistency without manual arbitration.
Assigning Tasks and Orchestrating Workflows
In the conceptual workflow, a custom planner or orchestrator receives a top-level goal and produces an initial task graph for validation before dispatch. This is a design pattern, not a documented current Raven command.
The conceptual workflow has 4 design steps:
1. Define a goal object that states the objective in one declarative sentence. This gives the custom planner or orchestrator a clear basis for generating the initial task graph.
2. Generate and validate task nodes. A custom planner may propose each task_id, description, and assigned_role, but the implementation must verify those fields before execution.
3. Set dependency edges. Add a depends_on field to any task that requires earlier output. The conceptual orchestrator would enforce those edges before dispatch.
4. Configure handoff payloads. In each conceptual task node, specify an output_schema so downstream roles receive structured results. A production implementation should validate the payload before handoff.
5. The current public release does not document a multi-agent orchestration CLI command. Run raven for the supported TUI; treat the workflow.yaml example below as pseudocode for a custom or future orchestrator.
In this example, researcher and writer are specialized worker roles, while reviewer retains the validation role defined earlier. Conceptual orchestration pseudocode follows:
goal: "Research, draft, and fact-check a product comparison report" tasks: - task_id: research description: "Gather source material on target products" assigned_role: researcher output_schema: sources_list - task_id: draft description: "Write the comparison report from gathered sources" assigned_role: writer depends_on: [research] output_schema: draft_document - task_id: fact_check description: "Verify all claims in the draft against sources" assigned_role: reviewer depends_on: [draft, research] output_schema
In any dependency graph, a missing edge can let a role run before its required input exists. Validate the graph before implementing this conceptual workflow.
Agents Reviewing Each Other's Work: The Self-Improving Peer-Review Loop
In the proposed multi-agent design, a reviewer would read another role's output, write a structured critique, and pass the reviewed result downstream.
In this blueprint, a custom orchestrator would add a reviewer node with a dependency on the producer it audits. The reviewer would receive the producer's output as input, apply criteria that instruct it to score and flag problems, and write a revised artifact for downstream roles. Subsequent nodes would consume the reviewed artifact rather than the raw draft.
A custom reviewer design requires 3 decisions: the input it reads, the reviewed artifact it writes, and the evaluation criteria encoded in its instructions. Criteria are domain-specific—a code reviewer may check syntax and test coverage, while a content reviewer may check factual consistency and tone. The implementation should require a structured output schema when downstream roles need deterministic parsing.
The proposed review loop can be recursive: a second reviewer may audit the first critique, while dependency edges preserve order without manual orchestration. This is a design pattern for the next-version direction, not validated behavior of the current public release.
Adding a reviewer between drafting and publishing can surface errors earlier, but the current public Raven README does not publish a measured hallucination-reduction rate for this team pattern.
In the conceptual pattern, reviewers would store correction patterns and producers would reuse them on later runs. A self-improving AI agent can reuse critiques as feedback instead of discarding them after one task.
Connecting Tools, APIs, and Data Sources to Your Team
In the proposed team design, each role would receive only the tools, endpoints, and data sources it needs. This keeps permission boundaries narrow; the role-level integration schema described below is conceptual rather than a documented current Raven API.
The current public Raven release includes a skills system with built-in, workspace, EverOS, and mirrored skills, but the official README does not publish a fixed count. In a future team design, self-evolving agent skills could turn repeated tool sequences into reusable capabilities for different roles.
A custom implementation can wire integrations into the conceptual team in 4 steps:
1. Declare the integration in the agent's role definition file, specifying the endpoint URL, authentication method, and required scopes.
2. Inject credentials through environment variables or a secrets manager, never hardcoded in the config.
3. Bind the integration to a skill slot so the agent's planner knows which tool to invoke for which subtask type.
4. Attach a data source — a local file path, a database connection string, or an API feed — as a named provider the agent reads before generating output.
Roles sharing a data source should reference one provider rather than duplicate copies. Read and write scopes should be explicit to reduce duplicate fetches and prevent accidental overwrites during parallel execution.
Requirements for Autonomous and 24/7 Operation
Sustained multi-agent operation requires persistent state, restart recovery, and supervision. Current public Raven supports long-running agent-harness work and EverOS memory, but the unattended team behavior described here belongs to the conceptual next-version design.
A custom deployment needs 4 reliability controls:
• Implement persistent-state checkpointing in the custom orchestration layer so a crash mid-task can resume from the last saved checkpoint rather than restarting from zero.
• Add a supervisor process or service that monitors task progress and re-queues work according to explicit timeout and retry policies.
• Configure exponential-backoff retry for outbound tool and API calls, with limits that route persistent failures to human review.
• Route orchestrator, role, and tool logs to a centralized append-only sink so post-incident diagnosis does not require reconstructing events across processes.
Raven's official README reports efficiency results for an internal next-version research prototype, but it does not establish a validated 10× cost reduction for the current public multi-agent release. Production costs still depend on models, tools, workload, and infrastructure.
Unattended uptime depends on the reliability of the host, model provider, tools, memory store, and orchestration layer. A multi-agent design can introduce additional failure points, so restart and recovery behavior must be tested rather than assumed.
Monitoring, Debugging, and Iterating Your Agent Team
Current public Raven includes local tracing for LLM calls, tool inputs and outputs, subagent runs, and parent-child relationships. The proposed team-level handoff states in this blueprint would still need explicit instrumentation in a custom implementation.
Reading Traces and Diagnosing Failures
Operators should distinguish hard tool errors, repeated retries, and stalled handoffs. Because the current public README does not define team-level handoff status codes, a custom implementation should define and document its own states before relying on them for monitoring.
Iterating on Roles and Workflows
In this conceptual design, role definitions would be editable configuration. A custom implementation should capture failing inputs and re-run them against revised role definitions before production deployment; current Raven tracing documents recorded spans and artifacts but not an automatic team-level replay feature.
A custom monitoring and iteration checklist has 6 checks:
1. Confirm trace logging is enabled for each custom role and for the orchestrator.
2. Review recorded handoff outcomes and errors after each autonomous run.
3. Identify roles that repeatedly retry the same subtask.
4. Inspect tool-call payloads on hard errors to rule out malformed inputs.
5. Re-run the captured failing input against the updated role definition before redeploying.
6. Archive resolved traces as regression fixtures to prevent recurrence.
Safe and Secure Operation Considerations
The conceptual team design should enforce permission scoping per role, output review before handoff, and controlled local storage. These multi-agent controls are design requirements, not documented current-release guarantees.
In a custom team implementation, restrict each role to the tools and scopes its task requires. A research role should receive read-only web access, not write credentials. Keep keys out of role files and trace logs, rotate them regularly, and audit scopes whenever a role is added.
EverOS uses a local Markdown, SQLite, and LanceDB stack. Local storage reduces exposure to third-party database services, but model and tool calls may still send data externally unless deployment policies prevent that.
A custom team workflow should apply guardrails before handoffs and before tools write to external systems. Reviewer checks should validate outputs against defined safety criteria, and irreversible actions such as file deletion, external POST requests, or email dispatch should require human approval.
Review agent outputs on a defined cadence rather than trusting autonomous execution indefinitely. Consult the current Raven README and SECURITY.md before production use, and validate any custom multi-agent controls independently.
Where to go from here
The sections above provide a conceptual blueprint for a future Raven multi-agent team, not a current end-to-end setup guide. Use the current public Raven release for its documented terminal-first Agent Harness capabilities and EverOS for durable memory. Track the Raven repository for the next-version multi-agent direction before relying on the team APIs described here.
Before production use, review the current Raven README and SECURITY.md at https://github.com/EverMind-AI/Raven and validate the pre-alpha release against your own requirements.
Frequently Asked Questions
Can you spin up an AI agent team with Raven for free?
Raven itself is open source under Apache 2.0 and can be run without a license fee. The current public release does not provide the Harness-of-Harnesses team API described in this conceptual guide, so implementing that pattern requires custom work and any model or infrastructure costs still apply.
Is Raven available on GitHub, and is it open source?
Yes. Raven is open source under Apache 2.0 at github.com/EverMind-AI/Raven. It is currently pre-alpha, and its interfaces and configuration may change quickly.
How many agents do you need to start a Raven team?
The current public Raven release does not document a built-in team API or minimum team size. The conceptual example in this guide uses three roles: planner, worker, and reviewer.
How do team members in a Raven team review each other's work?
In the conceptual pattern, a reviewer would score a worker's output and return it to an orchestrator for revision or completion. This peer-review bus is not documented as a current public Raven capability.
Can a Raven agent team operate 24/7 without supervision?
Not as a documented current public feature. Raven supports long-running AI work, but the multi-agent supervisor, role dispatch, and peer-review loop described here belong to the next-version direction. Any custom 24/7 deployment needs alerting, recovery tests, and human approval gates.
How is spinning up a team with Raven different from a single-agent setup?
A team architecture distributes work across specialized roles, while current public Raven centers on one Agent Harness. The role-separated workflow in this guide is conceptual and should not be presented as a supported current team configuration.
Key Takeaways
• The current public Raven release is a pre-alpha self-improving Agent Harness. The multi-agent team model in this guide reflects Raven's next-version direction, not a capability of the current public release.
• Raven's next-version research prototype reports 56.7% at the 27B tier versus Hermes at 46.8%. These results do not describe the current public release.
• Current Raven setup uses the official installer followed by the raven onboarding flow. The team configurations below are conceptual examples, not current public Raven APIs.
• The conceptual team pattern uses three roles — planner, worker, and reviewer — each with one clear responsibility.
• The proposed team design uses shared memory for sequential and parallel coordination; actual latency depends on the selected memory and deployment configuration.
• In the proposed design, reviewer agents would read producer outputs, apply structured critiques, and pass revised artifacts downstream.
• The current public Raven release includes a skills system, evaluation, and reusable workflows, but the official README does not publish a fixed count of built-in skills.
What Is Raven and Why Use It for a Multi-Agent Team?
Evermind's current public Raven release is a pre-alpha self-improving AI agent harness for long-running AI work. It includes terminal-first execution, local tracing, long-term memory, skills, evaluation, and reusable workflows. The planner, worker, reviewer, and shared-memory patterns in this guide describe Raven's next-version multi-agent direction rather than current public functionality.
There are 3 reasons the proposed next-version design could improve on ad-hoc multi-agent scripting.
First, a structured harness can centralize routing, retry behavior, and memory sharing that ad-hoc scripts otherwise implement separately. In Raven, those multi-agent coordination patterns remain part of the next-version direction.
Second, the proposed design treats peer review as an explicit workflow step. One agent's output would become the input to a reviewer before results move downstream, allowing errors to be caught earlier in the pipeline.
Third, Raven reports results from an internal next-version research prototype: 56.7% at the 27B tier versus Hermes at 46.8%. The official README states that these results do not mean the current public release already supports the multi-agent network. Raven is released under Apache 2.0.
Prerequisites and Setup: Install, Access, and Environment
Running current public Raven starts with the official installer and the raven onboarding flow. Building the conceptual multi-agent pattern additionally requires custom orchestration because the current public release does not expose the team API described below.
Getting Raven from GitHub
Raven is open source under Apache 2.0 and available at github.com/EverMind-AI/Raven. For macOS, Linux, or WSL2, use the official installer and then launch onboarding:
curl -fsSL https://raven.evermind.ai/install.sh | bash
The storage stack Raven expects is Local Markdown + SQLite + LanceDB — no MongoDB, Elasticsearch, or Redis dependency is required. SQLite handles structured agent state; LanceDB handles vector retrieval; Local Markdown stores human-readable memory artifacts.
Free vs. Advanced Setup Paths
Raven onboarding supports local and hosted model providers. A local model can avoid provider subscription fees, while hardware and infrastructure costs still apply.
For hosted providers, run raven and complete the provider connectivity check during onboarding. Configuration covers these areas:
1. Select the provider and model, then enter the required provider credential through the onboarding flow.
2. Choose the sandbox or execution location and configure any chat channels.
3. Configure EverOS memory, Deep Research, and optional cold-start import from other AI tools.
Setup time depends on the provider, model, sandbox, and optional integrations selected during onboarding. The official README does not publish a fixed five-minute setup guarantee, and scaling to a multi-agent team still requires custom work in the current public release.
Defining Agent Roles and Responsibilities in Your Team
For the conceptual team pattern, give each agent one clear responsibility. Role clarity reduces duplicate work and keeps an orchestration graph easier to reason about.
The examples below divide work among specialist roles rather than one generalist agent. Treat them as architecture guidance for Raven's next-version direction, not as evidence that the current public release includes a 13-agent team system or a fixed-size built-in skill library.
The conceptual example starts with 3 roles before expansion.
Example Roles: Planner
In the conceptual team pattern, a planner agent decomposes the top-level goal into an ordered sequence of subtasks. Its instructions restrict it to task decomposition: it emits a structured task list and passes control downstream. Keeping planning separate from execution can make responsibilities and validation boundaries clearer.
Example Roles: Worker
The worker agent receives individual subtasks from the planner and executes them — querying APIs, writing code, retrieving documents, or calling external tools. A team typically runs multiple worker instances in parallel, each scoped to a domain such as web retrieval, code execution, or data transformation.
Example Roles: Reviewer
In the conceptual workflow, a reviewer agent inspects worker outputs against the original task specification before results surface or trigger the next stage. A dedicated review step can catch errors earlier, but its effectiveness depends on the evaluation criteria, model, and task.
The following block is conceptual pseudocode for three roles. It is not a supported current Raven configuration schema:
agents: - id: planner role: decompose system_prompt: "Break the user goal into ordered subtasks. Output only a task list." - id: worker role: execute system_prompt: "Execute the assigned subtask using available skills." - id: reviewer role: validate system_prompt: "Verify worker output against the original subtask specification."
In this pseudocode, each id represents a role that a future orchestrator would route work to.
Configuring Inter-Agent Coordination and Communication
In the proposed team architecture, coordination would rely on a shared memory layer that participants read and write during task execution. Roles would be defined before the team is connected. Multi-agent memory would provide durable state for dependencies, handoffs, and partial results. Retrieval latency depends on the selected EverOS mode and deployment rather than a guaranteed threshold for the current Raven release.
The conceptual workflow supports two coordination patterns: sequential and parallel. Sequential execution passes one role's output to the next; parallel execution runs independent subtasks and merges their results at an aggregator.
The following conceptual pseudocode illustrates a sequential setup; it is not a current Raven configuration file.
coordination: mode: sequential agents: - id: researcher passes_to: writer - id: writer passes_to: reviewer shared_memory: true
In this pseudocode, passes_to identifies the next role and shared_memory represents a shared state layer. Shared memory AI agents can stay aligned when every role reads the same reviewed state, but these fields are not documented current Raven configuration options.
A production multi-agent implementation should serialize conflicting writes or use locks. If two roles write the same memory key, the implementation should queue or reject one write to preserve consistency without manual arbitration.
Assigning Tasks and Orchestrating Workflows
In the conceptual workflow, a custom planner or orchestrator receives a top-level goal and produces an initial task graph for validation before dispatch. This is a design pattern, not a documented current Raven command.
The conceptual workflow has 4 design steps:
1. Define a goal object that states the objective in one declarative sentence. This gives the custom planner or orchestrator a clear basis for generating the initial task graph.
2. Generate and validate task nodes. A custom planner may propose each task_id, description, and assigned_role, but the implementation must verify those fields before execution.
3. Set dependency edges. Add a depends_on field to any task that requires earlier output. The conceptual orchestrator would enforce those edges before dispatch.
4. Configure handoff payloads. In each conceptual task node, specify an output_schema so downstream roles receive structured results. A production implementation should validate the payload before handoff.
5. The current public release does not document a multi-agent orchestration CLI command. Run raven for the supported TUI; treat the workflow.yaml example below as pseudocode for a custom or future orchestrator.
In this example, researcher and writer are specialized worker roles, while reviewer retains the validation role defined earlier. Conceptual orchestration pseudocode follows:
goal: "Research, draft, and fact-check a product comparison report" tasks: - task_id: research description: "Gather source material on target products" assigned_role: researcher output_schema: sources_list - task_id: draft description: "Write the comparison report from gathered sources" assigned_role: writer depends_on: [research] output_schema: draft_document - task_id: fact_check description: "Verify all claims in the draft against sources" assigned_role: reviewer depends_on: [draft, research] output_schema
In any dependency graph, a missing edge can let a role run before its required input exists. Validate the graph before implementing this conceptual workflow.
Agents Reviewing Each Other's Work: The Self-Improving Peer-Review Loop
In the proposed multi-agent design, a reviewer would read another role's output, write a structured critique, and pass the reviewed result downstream.
In this blueprint, a custom orchestrator would add a reviewer node with a dependency on the producer it audits. The reviewer would receive the producer's output as input, apply criteria that instruct it to score and flag problems, and write a revised artifact for downstream roles. Subsequent nodes would consume the reviewed artifact rather than the raw draft.
A custom reviewer design requires 3 decisions: the input it reads, the reviewed artifact it writes, and the evaluation criteria encoded in its instructions. Criteria are domain-specific—a code reviewer may check syntax and test coverage, while a content reviewer may check factual consistency and tone. The implementation should require a structured output schema when downstream roles need deterministic parsing.
The proposed review loop can be recursive: a second reviewer may audit the first critique, while dependency edges preserve order without manual orchestration. This is a design pattern for the next-version direction, not validated behavior of the current public release.
Adding a reviewer between drafting and publishing can surface errors earlier, but the current public Raven README does not publish a measured hallucination-reduction rate for this team pattern.
In the conceptual pattern, reviewers would store correction patterns and producers would reuse them on later runs. A self-improving AI agent can reuse critiques as feedback instead of discarding them after one task.
Connecting Tools, APIs, and Data Sources to Your Team
In the proposed team design, each role would receive only the tools, endpoints, and data sources it needs. This keeps permission boundaries narrow; the role-level integration schema described below is conceptual rather than a documented current Raven API.
The current public Raven release includes a skills system with built-in, workspace, EverOS, and mirrored skills, but the official README does not publish a fixed count. In a future team design, self-evolving agent skills could turn repeated tool sequences into reusable capabilities for different roles.
A custom implementation can wire integrations into the conceptual team in 4 steps:
1. Declare the integration in the agent's role definition file, specifying the endpoint URL, authentication method, and required scopes.
2. Inject credentials through environment variables or a secrets manager, never hardcoded in the config.
3. Bind the integration to a skill slot so the agent's planner knows which tool to invoke for which subtask type.
4. Attach a data source — a local file path, a database connection string, or an API feed — as a named provider the agent reads before generating output.
Roles sharing a data source should reference one provider rather than duplicate copies. Read and write scopes should be explicit to reduce duplicate fetches and prevent accidental overwrites during parallel execution.
Requirements for Autonomous and 24/7 Operation
Sustained multi-agent operation requires persistent state, restart recovery, and supervision. Current public Raven supports long-running agent-harness work and EverOS memory, but the unattended team behavior described here belongs to the conceptual next-version design.
A custom deployment needs 4 reliability controls:
• Implement persistent-state checkpointing in the custom orchestration layer so a crash mid-task can resume from the last saved checkpoint rather than restarting from zero.
• Add a supervisor process or service that monitors task progress and re-queues work according to explicit timeout and retry policies.
• Configure exponential-backoff retry for outbound tool and API calls, with limits that route persistent failures to human review.
• Route orchestrator, role, and tool logs to a centralized append-only sink so post-incident diagnosis does not require reconstructing events across processes.
Raven's official README reports efficiency results for an internal next-version research prototype, but it does not establish a validated 10× cost reduction for the current public multi-agent release. Production costs still depend on models, tools, workload, and infrastructure.
Unattended uptime depends on the reliability of the host, model provider, tools, memory store, and orchestration layer. A multi-agent design can introduce additional failure points, so restart and recovery behavior must be tested rather than assumed.
Monitoring, Debugging, and Iterating Your Agent Team
Current public Raven includes local tracing for LLM calls, tool inputs and outputs, subagent runs, and parent-child relationships. The proposed team-level handoff states in this blueprint would still need explicit instrumentation in a custom implementation.
Reading Traces and Diagnosing Failures
Operators should distinguish hard tool errors, repeated retries, and stalled handoffs. Because the current public README does not define team-level handoff status codes, a custom implementation should define and document its own states before relying on them for monitoring.
Iterating on Roles and Workflows
In this conceptual design, role definitions would be editable configuration. A custom implementation should capture failing inputs and re-run them against revised role definitions before production deployment; current Raven tracing documents recorded spans and artifacts but not an automatic team-level replay feature.
A custom monitoring and iteration checklist has 6 checks:
1. Confirm trace logging is enabled for each custom role and for the orchestrator.
2. Review recorded handoff outcomes and errors after each autonomous run.
3. Identify roles that repeatedly retry the same subtask.
4. Inspect tool-call payloads on hard errors to rule out malformed inputs.
5. Re-run the captured failing input against the updated role definition before redeploying.
6. Archive resolved traces as regression fixtures to prevent recurrence.
Safe and Secure Operation Considerations
The conceptual team design should enforce permission scoping per role, output review before handoff, and controlled local storage. These multi-agent controls are design requirements, not documented current-release guarantees.
In a custom team implementation, restrict each role to the tools and scopes its task requires. A research role should receive read-only web access, not write credentials. Keep keys out of role files and trace logs, rotate them regularly, and audit scopes whenever a role is added.
EverOS uses a local Markdown, SQLite, and LanceDB stack. Local storage reduces exposure to third-party database services, but model and tool calls may still send data externally unless deployment policies prevent that.
A custom team workflow should apply guardrails before handoffs and before tools write to external systems. Reviewer checks should validate outputs against defined safety criteria, and irreversible actions such as file deletion, external POST requests, or email dispatch should require human approval.
Review agent outputs on a defined cadence rather than trusting autonomous execution indefinitely. Consult the current Raven README and SECURITY.md before production use, and validate any custom multi-agent controls independently.
Where to go from here
The sections above provide a conceptual blueprint for a future Raven multi-agent team, not a current end-to-end setup guide. Use the current public Raven release for its documented terminal-first Agent Harness capabilities and EverOS for durable memory. Track the Raven repository for the next-version multi-agent direction before relying on the team APIs described here.
Before production use, review the current Raven README and SECURITY.md at https://github.com/EverMind-AI/Raven and validate the pre-alpha release against your own requirements.
Frequently Asked Questions
Can you spin up an AI agent team with Raven for free?
Raven itself is open source under Apache 2.0 and can be run without a license fee. The current public release does not provide the Harness-of-Harnesses team API described in this conceptual guide, so implementing that pattern requires custom work and any model or infrastructure costs still apply.
Is Raven available on GitHub, and is it open source?
Yes. Raven is open source under Apache 2.0 at github.com/EverMind-AI/Raven. It is currently pre-alpha, and its interfaces and configuration may change quickly.
How many agents do you need to start a Raven team?
The current public Raven release does not document a built-in team API or minimum team size. The conceptual example in this guide uses three roles: planner, worker, and reviewer.
How do team members in a Raven team review each other's work?
In the conceptual pattern, a reviewer would score a worker's output and return it to an orchestrator for revision or completion. This peer-review bus is not documented as a current public Raven capability.
Can a Raven agent team operate 24/7 without supervision?
Not as a documented current public feature. Raven supports long-running AI work, but the multi-agent supervisor, role dispatch, and peer-review loop described here belong to the next-version direction. Any custom 24/7 deployment needs alerting, recovery tests, and human approval gates.
How is spinning up a team with Raven different from a single-agent setup?
A team architecture distributes work across specialized roles, while current public Raven centers on one Agent Harness. The role-separated workflow in this guide is conceptual and should not be presented as a supported current team configuration.
Key Takeaways
• The current public Raven release is a pre-alpha self-improving Agent Harness. The multi-agent team model in this guide reflects Raven's next-version direction, not a capability of the current public release.
• Raven's next-version research prototype reports 56.7% at the 27B tier versus Hermes at 46.8%. These results do not describe the current public release.
• Current Raven setup uses the official installer followed by the raven onboarding flow. The team configurations below are conceptual examples, not current public Raven APIs.
• The conceptual team pattern uses three roles — planner, worker, and reviewer — each with one clear responsibility.
• The proposed team design uses shared memory for sequential and parallel coordination; actual latency depends on the selected memory and deployment configuration.
• In the proposed design, reviewer agents would read producer outputs, apply structured critiques, and pass revised artifacts downstream.
• The current public Raven release includes a skills system, evaluation, and reusable workflows, but the official README does not publish a fixed count of built-in skills.
What Is Raven and Why Use It for a Multi-Agent Team?
Evermind's current public Raven release is a pre-alpha self-improving AI agent harness for long-running AI work. It includes terminal-first execution, local tracing, long-term memory, skills, evaluation, and reusable workflows. The planner, worker, reviewer, and shared-memory patterns in this guide describe Raven's next-version multi-agent direction rather than current public functionality.
There are 3 reasons the proposed next-version design could improve on ad-hoc multi-agent scripting.
First, a structured harness can centralize routing, retry behavior, and memory sharing that ad-hoc scripts otherwise implement separately. In Raven, those multi-agent coordination patterns remain part of the next-version direction.
Second, the proposed design treats peer review as an explicit workflow step. One agent's output would become the input to a reviewer before results move downstream, allowing errors to be caught earlier in the pipeline.
Third, Raven reports results from an internal next-version research prototype: 56.7% at the 27B tier versus Hermes at 46.8%. The official README states that these results do not mean the current public release already supports the multi-agent network. Raven is released under Apache 2.0.
Prerequisites and Setup: Install, Access, and Environment
Running current public Raven starts with the official installer and the raven onboarding flow. Building the conceptual multi-agent pattern additionally requires custom orchestration because the current public release does not expose the team API described below.
Getting Raven from GitHub
Raven is open source under Apache 2.0 and available at github.com/EverMind-AI/Raven. For macOS, Linux, or WSL2, use the official installer and then launch onboarding:
curl -fsSL https://raven.evermind.ai/install.sh | bash
The storage stack Raven expects is Local Markdown + SQLite + LanceDB — no MongoDB, Elasticsearch, or Redis dependency is required. SQLite handles structured agent state; LanceDB handles vector retrieval; Local Markdown stores human-readable memory artifacts.
Free vs. Advanced Setup Paths
Raven onboarding supports local and hosted model providers. A local model can avoid provider subscription fees, while hardware and infrastructure costs still apply.
For hosted providers, run raven and complete the provider connectivity check during onboarding. Configuration covers these areas:
1. Select the provider and model, then enter the required provider credential through the onboarding flow.
2. Choose the sandbox or execution location and configure any chat channels.
3. Configure EverOS memory, Deep Research, and optional cold-start import from other AI tools.
Setup time depends on the provider, model, sandbox, and optional integrations selected during onboarding. The official README does not publish a fixed five-minute setup guarantee, and scaling to a multi-agent team still requires custom work in the current public release.
Defining Agent Roles and Responsibilities in Your Team
For the conceptual team pattern, give each agent one clear responsibility. Role clarity reduces duplicate work and keeps an orchestration graph easier to reason about.
The examples below divide work among specialist roles rather than one generalist agent. Treat them as architecture guidance for Raven's next-version direction, not as evidence that the current public release includes a 13-agent team system or a fixed-size built-in skill library.
The conceptual example starts with 3 roles before expansion.
Example Roles: Planner
In the conceptual team pattern, a planner agent decomposes the top-level goal into an ordered sequence of subtasks. Its instructions restrict it to task decomposition: it emits a structured task list and passes control downstream. Keeping planning separate from execution can make responsibilities and validation boundaries clearer.
Example Roles: Worker
The worker agent receives individual subtasks from the planner and executes them — querying APIs, writing code, retrieving documents, or calling external tools. A team typically runs multiple worker instances in parallel, each scoped to a domain such as web retrieval, code execution, or data transformation.
Example Roles: Reviewer
In the conceptual workflow, a reviewer agent inspects worker outputs against the original task specification before results surface or trigger the next stage. A dedicated review step can catch errors earlier, but its effectiveness depends on the evaluation criteria, model, and task.
The following block is conceptual pseudocode for three roles. It is not a supported current Raven configuration schema:
agents: - id: planner role: decompose system_prompt: "Break the user goal into ordered subtasks. Output only a task list." - id: worker role: execute system_prompt: "Execute the assigned subtask using available skills." - id: reviewer role: validate system_prompt: "Verify worker output against the original subtask specification."
In this pseudocode, each id represents a role that a future orchestrator would route work to.
Configuring Inter-Agent Coordination and Communication
In the proposed team architecture, coordination would rely on a shared memory layer that participants read and write during task execution. Roles would be defined before the team is connected. Multi-agent memory would provide durable state for dependencies, handoffs, and partial results. Retrieval latency depends on the selected EverOS mode and deployment rather than a guaranteed threshold for the current Raven release.
The conceptual workflow supports two coordination patterns: sequential and parallel. Sequential execution passes one role's output to the next; parallel execution runs independent subtasks and merges their results at an aggregator.
The following conceptual pseudocode illustrates a sequential setup; it is not a current Raven configuration file.
coordination: mode: sequential agents: - id: researcher passes_to: writer - id: writer passes_to: reviewer shared_memory: true
In this pseudocode, passes_to identifies the next role and shared_memory represents a shared state layer. Shared memory AI agents can stay aligned when every role reads the same reviewed state, but these fields are not documented current Raven configuration options.
A production multi-agent implementation should serialize conflicting writes or use locks. If two roles write the same memory key, the implementation should queue or reject one write to preserve consistency without manual arbitration.
Assigning Tasks and Orchestrating Workflows
In the conceptual workflow, a custom planner or orchestrator receives a top-level goal and produces an initial task graph for validation before dispatch. This is a design pattern, not a documented current Raven command.
The conceptual workflow has 4 design steps:
1. Define a goal object that states the objective in one declarative sentence. This gives the custom planner or orchestrator a clear basis for generating the initial task graph.
2. Generate and validate task nodes. A custom planner may propose each task_id, description, and assigned_role, but the implementation must verify those fields before execution.
3. Set dependency edges. Add a depends_on field to any task that requires earlier output. The conceptual orchestrator would enforce those edges before dispatch.
4. Configure handoff payloads. In each conceptual task node, specify an output_schema so downstream roles receive structured results. A production implementation should validate the payload before handoff.
5. The current public release does not document a multi-agent orchestration CLI command. Run raven for the supported TUI; treat the workflow.yaml example below as pseudocode for a custom or future orchestrator.
In this example, researcher and writer are specialized worker roles, while reviewer retains the validation role defined earlier. Conceptual orchestration pseudocode follows:
goal: "Research, draft, and fact-check a product comparison report" tasks: - task_id: research description: "Gather source material on target products" assigned_role: researcher output_schema: sources_list - task_id: draft description: "Write the comparison report from gathered sources" assigned_role: writer depends_on: [research] output_schema: draft_document - task_id: fact_check description: "Verify all claims in the draft against sources" assigned_role: reviewer depends_on: [draft, research] output_schema
In any dependency graph, a missing edge can let a role run before its required input exists. Validate the graph before implementing this conceptual workflow.
Agents Reviewing Each Other's Work: The Self-Improving Peer-Review Loop
In the proposed multi-agent design, a reviewer would read another role's output, write a structured critique, and pass the reviewed result downstream.
In this blueprint, a custom orchestrator would add a reviewer node with a dependency on the producer it audits. The reviewer would receive the producer's output as input, apply criteria that instruct it to score and flag problems, and write a revised artifact for downstream roles. Subsequent nodes would consume the reviewed artifact rather than the raw draft.
A custom reviewer design requires 3 decisions: the input it reads, the reviewed artifact it writes, and the evaluation criteria encoded in its instructions. Criteria are domain-specific—a code reviewer may check syntax and test coverage, while a content reviewer may check factual consistency and tone. The implementation should require a structured output schema when downstream roles need deterministic parsing.
The proposed review loop can be recursive: a second reviewer may audit the first critique, while dependency edges preserve order without manual orchestration. This is a design pattern for the next-version direction, not validated behavior of the current public release.
Adding a reviewer between drafting and publishing can surface errors earlier, but the current public Raven README does not publish a measured hallucination-reduction rate for this team pattern.
In the conceptual pattern, reviewers would store correction patterns and producers would reuse them on later runs. A self-improving AI agent can reuse critiques as feedback instead of discarding them after one task.
Connecting Tools, APIs, and Data Sources to Your Team
In the proposed team design, each role would receive only the tools, endpoints, and data sources it needs. This keeps permission boundaries narrow; the role-level integration schema described below is conceptual rather than a documented current Raven API.
The current public Raven release includes a skills system with built-in, workspace, EverOS, and mirrored skills, but the official README does not publish a fixed count. In a future team design, self-evolving agent skills could turn repeated tool sequences into reusable capabilities for different roles.
A custom implementation can wire integrations into the conceptual team in 4 steps:
1. Declare the integration in the agent's role definition file, specifying the endpoint URL, authentication method, and required scopes.
2. Inject credentials through environment variables or a secrets manager, never hardcoded in the config.
3. Bind the integration to a skill slot so the agent's planner knows which tool to invoke for which subtask type.
4. Attach a data source — a local file path, a database connection string, or an API feed — as a named provider the agent reads before generating output.
Roles sharing a data source should reference one provider rather than duplicate copies. Read and write scopes should be explicit to reduce duplicate fetches and prevent accidental overwrites during parallel execution.
Requirements for Autonomous and 24/7 Operation
Sustained multi-agent operation requires persistent state, restart recovery, and supervision. Current public Raven supports long-running agent-harness work and EverOS memory, but the unattended team behavior described here belongs to the conceptual next-version design.
A custom deployment needs 4 reliability controls:
• Implement persistent-state checkpointing in the custom orchestration layer so a crash mid-task can resume from the last saved checkpoint rather than restarting from zero.
• Add a supervisor process or service that monitors task progress and re-queues work according to explicit timeout and retry policies.
• Configure exponential-backoff retry for outbound tool and API calls, with limits that route persistent failures to human review.
• Route orchestrator, role, and tool logs to a centralized append-only sink so post-incident diagnosis does not require reconstructing events across processes.
Raven's official README reports efficiency results for an internal next-version research prototype, but it does not establish a validated 10× cost reduction for the current public multi-agent release. Production costs still depend on models, tools, workload, and infrastructure.
Unattended uptime depends on the reliability of the host, model provider, tools, memory store, and orchestration layer. A multi-agent design can introduce additional failure points, so restart and recovery behavior must be tested rather than assumed.
Monitoring, Debugging, and Iterating Your Agent Team
Current public Raven includes local tracing for LLM calls, tool inputs and outputs, subagent runs, and parent-child relationships. The proposed team-level handoff states in this blueprint would still need explicit instrumentation in a custom implementation.
Reading Traces and Diagnosing Failures
Operators should distinguish hard tool errors, repeated retries, and stalled handoffs. Because the current public README does not define team-level handoff status codes, a custom implementation should define and document its own states before relying on them for monitoring.
Iterating on Roles and Workflows
In this conceptual design, role definitions would be editable configuration. A custom implementation should capture failing inputs and re-run them against revised role definitions before production deployment; current Raven tracing documents recorded spans and artifacts but not an automatic team-level replay feature.
A custom monitoring and iteration checklist has 6 checks:
1. Confirm trace logging is enabled for each custom role and for the orchestrator.
2. Review recorded handoff outcomes and errors after each autonomous run.
3. Identify roles that repeatedly retry the same subtask.
4. Inspect tool-call payloads on hard errors to rule out malformed inputs.
5. Re-run the captured failing input against the updated role definition before redeploying.
6. Archive resolved traces as regression fixtures to prevent recurrence.
Safe and Secure Operation Considerations
The conceptual team design should enforce permission scoping per role, output review before handoff, and controlled local storage. These multi-agent controls are design requirements, not documented current-release guarantees.
In a custom team implementation, restrict each role to the tools and scopes its task requires. A research role should receive read-only web access, not write credentials. Keep keys out of role files and trace logs, rotate them regularly, and audit scopes whenever a role is added.
EverOS uses a local Markdown, SQLite, and LanceDB stack. Local storage reduces exposure to third-party database services, but model and tool calls may still send data externally unless deployment policies prevent that.
A custom team workflow should apply guardrails before handoffs and before tools write to external systems. Reviewer checks should validate outputs against defined safety criteria, and irreversible actions such as file deletion, external POST requests, or email dispatch should require human approval.
Review agent outputs on a defined cadence rather than trusting autonomous execution indefinitely. Consult the current Raven README and SECURITY.md before production use, and validate any custom multi-agent controls independently.
Where to go from here
The sections above provide a conceptual blueprint for a future Raven multi-agent team, not a current end-to-end setup guide. Use the current public Raven release for its documented terminal-first Agent Harness capabilities and EverOS for durable memory. Track the Raven repository for the next-version multi-agent direction before relying on the team APIs described here.
Before production use, review the current Raven README and SECURITY.md at https://github.com/EverMind-AI/Raven and validate the pre-alpha release against your own requirements.
Frequently Asked Questions
Can you spin up an AI agent team with Raven for free?
Raven itself is open source under Apache 2.0 and can be run without a license fee. The current public release does not provide the Harness-of-Harnesses team API described in this conceptual guide, so implementing that pattern requires custom work and any model or infrastructure costs still apply.
Is Raven available on GitHub, and is it open source?
Yes. Raven is open source under Apache 2.0 at github.com/EverMind-AI/Raven. It is currently pre-alpha, and its interfaces and configuration may change quickly.
How many agents do you need to start a Raven team?
The current public Raven release does not document a built-in team API or minimum team size. The conceptual example in this guide uses three roles: planner, worker, and reviewer.
How do team members in a Raven team review each other's work?
In the conceptual pattern, a reviewer would score a worker's output and return it to an orchestrator for revision or completion. This peer-review bus is not documented as a current public Raven capability.
Can a Raven agent team operate 24/7 without supervision?
Not as a documented current public feature. Raven supports long-running AI work, but the multi-agent supervisor, role dispatch, and peer-review loop described here belong to the next-version direction. Any custom 24/7 deployment needs alerting, recovery tests, and human approval gates.
How is spinning up a team with Raven different from a single-agent setup?
A team architecture distributes work across specialized roles, while current public Raven centers on one Agent Harness. The role-separated workflow in this guide is conceptual and should not be presented as a supported current team configuration.
您可能还喜欢这些
相关
Multi-round retrieval: letting the model decide when to stop searching
multi-round retrieval,agentic retrieval,fixed top-k,injection budget,core selection,EverOS,agent memory,LoCoMo,LongMemEval,EverMemBench,SubtleMemory,multi-hop retrieval,retrieval accuracy,prompt token cost
Do public SKILL.md files actually make agents better?
SkillCorpus,SKILL.md,agent skills,skill curation,skill retrieval,LLM agents,SkillsBench,GDPVal,agent harness
CRAFT: learning how to fuse video tokens, not just which to drop
CRAFT,video token compression,vision-language models,video VLM,KV cache,prefill cost,token merging,token pruning,temporal reasoning
Self-evolving agents have a measurement problem
self-evolving agents,agent harness,HarnessBank,credit assignment,LLM agents,agent evaluation,harness optimization,significance testing
How to Spin Up an AI Agent Team with Raven: A Conceptual Blueprint
Evermind's current public Raven release is a pre-alpha self-improving AI agent harness for long-running AI work. This conceptual blueprint describes Raven's next-version multi-agent direction — planner, worker, and reviewer roles coordinating through shared memory and peer review — rather than a capability of the current public release.
EverMind研究人员
About 13 minutes to read
