Spring Voyage v1.0.0-alpha.20260608.1

Spring Voyage v1.0.0-alpha — first public release

Spring Voyage is an open-source collaboration platform for humans and the teams of AI agents they work with — developed by CVOYA and led by Savas Parastatidis. For news, examples, and the wider project, visit spring.voyage.

This is the first public release. Built because we needed it; now it's yours to run.

Warning

This is an alpha — on purpose. The substrate is solid and in daily use, but not every feature is fully wired or tested, the collaboration experience today is a chat interface, and the docs may lag the code. Expect rough edges and breaking changes between pre-releases (including database-schema resets). Feedback is very welcome — open an issue or join the Discussions.

What Spring Voyage is — and deliberately isn't

Spring Voyage lets humans and AI agents work together toward a goal in a domain, as members of the same team — each with their own roles, responsibilities, and expertise. Agents organize into composable units, connect to external systems through pluggable connectors, and communicate via messages.

The platform deliberately does not orchestrate. There are no predefined workflows or built-in routing logic; how a team communicates, collaborates, and organizes to solve a problem is left to the instructions and tools given to its agents. Most agent platforms lead with a workflow engine — Spring Voyage leads with the substrate and makes orchestration an optional choice a team makes (in plain instructions, in code, or in a framework like LangGraph reached over A2A), not a platform requirement. The platform delivers messages and records what happened; it doesn't own the routing policy.

What's in this release

• Messaging & typed addresses — communication between addressable members (agent:, human:, connector:), each with a partitioned mailbox, on a Dapr virtual-actor concurrency model with reliable delivery. The platform delivers; it doesn't interpret.
• Units — composable, nestable teams. A unit is itself just an agent that has children, so composition is recursive: a team can contain other teams. Agents can belong to multiple units.
• Tools, not workflows — every agent has a built-in sv.* toolset: sv.messaging.send / sv.messaging.multicast for delivery, sv.directory.list_members / sv.directory.get_status and sv.expertise.lookup for discovery, sv.runtime.report_decision to record why a decision was made, and sv.progress.report for the per-turn summary the operator sees. The platform exposes many more sv.* tools; agents discover the rest at runtime via sv.tools.list (and sv.tools.list_categories for what's available), so new capabilities surface without re-teaching every agent.
• Directory — discover who's on the team, what they know, and who has capacity right now. Collaborators are chosen by expertise, not a hardcoded org chart.
• Memory — a per-engagement history of the interactions between two or more participants, available to agents on a per-thread basis (sv.memory.*), plus a persistent local volume per agent. (A richer, self-organizing per-agent memory is on the roadmap.)
• Isolated agent runtimes — each agent runs in its own container. The "brain" can be Claude Code, Codex, Gemini, Ollama, a Dapr Agent, or any custom A2A agent (bring-your-own-image). Every agent is an A2A server and each turn is dispatched over A2A. Runtimes can host their own orchestration frameworks — LangGraph, Microsoft Agent Framework, CrewAI, Google ADK, OpenAI Agents SDK, Ruflo, Gas Town, and more.
• Initiative — agents can act with one of four levels of initiative (passive, attentive, proactive, autonomous), so they can reach out, not only be reached.
• Humans as first-class members — a real HumanActor on the same members: grammar as agents, plus the Hat model: one operator can wear different Hats across teams, each with its own per-team name and role.
• Connectors — pluggable integration with external systems. This release ships GitHub (deep) and Slack (personal workspace) connectors. Each translates external events into typed messages and surfaces actions as tools.
• Observability & cost tracking — every reasoning step, decision, and cost emitted as a structured ActivityEvent, streamed to the portal (with an Interactions view) and to other agents; per-conversation cost and per-agent budgets enforced by the platform.
• Secrets — a three-tier (platform / tenant / unit) model with AES-GCM at-rest encryption.
• CLI & Web Portal — manage the platform, configure teams, monitor budgets, and watch operations. The portal's new-unit wizard walks you through everything — LLM credentials, GitHub/Slack integration, and the rest — with no CLI required to get going.

Ready-made teams (packages)

Spring Voyage ships installable team packages — the clearest proof that the same substrate carries very different shapes of collaboration. Install from the portal's New Unit wizard or spring package install <name>:

• spring-voyage-oss — a working dev team (team-leader, software engineers, program managers, plus a human lead) that picks up work from a GitHub repository. Delegation-shaped: parallel, webhook- or request-driven, no central pipeline.
• magazine — a daily online-magazine team (editor-in-chief, writers, fact-checker, copy/audience/production editors, plus a human publisher). Workflow-shaped: sequential, human-initiated, with a final human approval gate — yet the "workflow" lives entirely in the agents' instructions, not in platform code.
• Plus software-engineering, product-management, and research domain packages, and minimal starter packages (hello-world, example-*) to fork from.

The platform never told the OSS team to be delegation-shaped or the Magazine team to be workflow-shaped — their instructions did. Read them, change them, or fork them.

One moment captures why that matters. Asked to produce the magazine's first edition — and to make it about Spring Voyage itself — the editor-in-chief came back with a proposed lineup and then offered to interview the founder, a nice touch nobody had requested. Minutes later the staff writer reached out directly with questions. Nothing in the package scripted that sequence; the team simply had a goal and a substrate to coordinate on, and the rest emerged.

Install

Spring Voyage runs on Linux or macOS with Podman 4+.

curl -fSL https://github.com/cvoya-com/spring-voyage/releases/latest/download/install.sh | bash

Two prompts — DEPLOY_HOSTNAME (default localhost) and an optional GitHub App registration; press Enter to accept both defaults. When it finishes, open http://localhost — the portal guides you through the rest. For flags, TLS, troubleshooting, and updates, see the operator deployment guide.

CLI only (no platform)

If you already have the .NET 10 runtime and just want the spring CLI to talk to an existing instance:

dotnet tool install -g Cvoya.Spring.Cli
export SPRING_API_URL=https://your-spring-voyage-host
spring --help

Getting started

• Your first unit and agent — create a unit, send it a message, add an agent member.
• Spring Voyage OSS — a ready-made dev team — install the built-in spring-voyage-oss package.

Open core & license

Spring Voyage follows an open-core model. This repository is the complete, fully functional platform — agents, units, messaging, routing, execution, connectors, CLI, web portal, the package system, observability, cost tracking, A2A, and secrets. Multi-tenancy infrastructure is included, configured as a single-operator identity model.

It is licensed under the Business Source License 1.1 — free for personal, development, testing, and internal/production use (except offering it as a competing managed service), converting to Apache 2.0 on 2030-04-10.

Status, feedback & what's next

A lot already works; some things don't yet, and that's why it's an alpha. The open question we most want to explore with you: how does a human actually team with a fleet of agents over time? Tell us what broke, what felt good, and which mental model the docs failed to deliver.

• File issues: github.com/cvoya-com/spring-voyage/issues
• Share ideas: Discussions
• Roadmap & live progress: milestones
• Contribute: CONTRIBUTING.md · Security: SECURITY.md (please don't open public issues for vulnerabilities)

Links

• Website: spring.voyage · From: CVOYA
• Repository: cvoya-com/spring-voyage
• **...

Spring Voyage v1.0.0-alpha.20260606

Spring Voyage v1.0.0-alpha — first public release

Spring Voyage is an open-source collaboration platform for humans and the teams of AI agents they work with — developed by CVOYA and led by Savas Parastatidis. For news, examples, and the wider project, visit spring.voyage.

This is the first public release. Built because we needed it; now it's yours to run.

Warning

This is an alpha — on purpose. The substrate is solid and in daily use, but not every feature is fully wired or tested, the collaboration experience today is a chat interface, and the docs may lag the code. Expect rough edges and breaking changes between pre-releases (including database-schema resets). Feedback is very welcome — open an issue or join the Discussions.

What Spring Voyage is — and deliberately isn't

Spring Voyage lets humans and AI agents work together toward a goal in a domain, as members of the same team — each with their own roles, responsibilities, and expertise. Agents organize into composable units, connect to external systems through pluggable connectors, and communicate via messages.

The platform deliberately does not orchestrate. There are no predefined workflows or built-in routing logic; how a team communicates, collaborates, and organizes to solve a problem is left to the instructions and tools given to its agents. Most agent platforms lead with a workflow engine — Spring Voyage leads with the substrate and makes orchestration an optional choice a team makes (in plain instructions, in code, or in a framework like LangGraph reached over A2A), not a platform requirement. The platform delivers messages and records what happened; it doesn't own the routing policy.

What's in this release

• Messaging & typed addresses — communication between addressable members (agent:, human:, connector:), each with a partitioned mailbox, on a Dapr virtual-actor concurrency model with reliable delivery. The platform delivers; it doesn't interpret.
• Units — composable, nestable teams. A unit is itself just an agent that has children, so composition is recursive: a team can contain other teams. Agents can belong to multiple units.
• Tools, not workflows — every agent has a built-in sv.* toolset: sv.messaging.send / sv.messaging.multicast for delivery, sv.directory.list_members / sv.directory.get_status and sv.expertise.lookup for discovery, sv.runtime.report_decision to record why a decision was made, and sv.progress.report for the per-turn summary the operator sees. The platform exposes many more sv.* tools; agents discover the rest at runtime via sv.tools.list (and sv.tools.list_categories for what's available), so new capabilities surface without re-teaching every agent.
• Directory — discover who's on the team, what they know, and who has capacity right now. Collaborators are chosen by expertise, not a hardcoded org chart.
• Memory — a per-engagement history of the interactions between two or more participants, available to agents on a per-thread basis (sv.memory.*), plus a persistent local volume per agent. (A richer, self-organizing per-agent memory is on the roadmap.)
• Isolated agent runtimes — each agent runs in its own container. The "brain" can be Claude Code, Codex, Gemini, Ollama, a Dapr Agent, or any custom A2A agent (bring-your-own-image). Every agent is an A2A server and each turn is dispatched over A2A. Runtimes can host their own orchestration frameworks — LangGraph, Microsoft Agent Framework, CrewAI, Google ADK, OpenAI Agents SDK, Ruflo, Gas Town, and more.
• Initiative — agents can act with one of four levels of initiative (passive, attentive, proactive, autonomous), so they can reach out, not only be reached.
• Humans as first-class members — a real HumanActor on the same members: grammar as agents, plus the Hat model: one operator can wear different Hats across teams, each with its own per-team name and role.
• Connectors — pluggable integration with external systems. This release ships GitHub (deep) and Slack (personal workspace) connectors. Each translates external events into typed messages and surfaces actions as tools.
• Observability & cost tracking — every reasoning step, decision, and cost emitted as a structured ActivityEvent, streamed to the portal (with an Interactions view) and to other agents; per-conversation cost and per-agent budgets enforced by the platform.
• Secrets — a three-tier (platform / tenant / unit) model with AES-GCM at-rest encryption.
• CLI & Web Portal — manage the platform, configure teams, monitor budgets, and watch operations. The portal's new-unit wizard walks you through everything — LLM credentials, GitHub/Slack integration, and the rest — with no CLI required to get going.

Ready-made teams (packages)

Spring Voyage ships installable team packages — the clearest proof that the same substrate carries very different shapes of collaboration. Install from the portal's New Unit wizard or spring package install <name>:

• spring-voyage-oss — a working dev team (team-leader, software engineers, program managers, plus a human lead) that picks up work from a GitHub repository. Delegation-shaped: parallel, webhook- or request-driven, no central pipeline.
• magazine — a daily online-magazine team (editor-in-chief, writers, fact-checker, copy/audience/production editors, plus a human publisher). Workflow-shaped: sequential, human-initiated, with a final human approval gate — yet the "workflow" lives entirely in the agents' instructions, not in platform code.
• Plus software-engineering, product-management, and research domain packages, and minimal starter packages (hello-world, example-*) to fork from.

The platform never told the OSS team to be delegation-shaped or the Magazine team to be workflow-shaped — their instructions did. Read them, change them, or fork them.

One moment captures why that matters. Asked to produce the magazine's first edition — and to make it about Spring Voyage itself — the editor-in-chief came back with a proposed lineup and then offered to interview the founder, a nice touch nobody had requested. Minutes later the staff writer reached out directly with questions. Nothing in the package scripted that sequence; the team simply had a goal and a substrate to coordinate on, and the rest emerged.

Install

Spring Voyage runs on Linux or macOS with Podman 4+.

curl -fSL https://github.com/cvoya-com/spring-voyage/releases/latest/download/install.sh | bash

Two prompts — DEPLOY_HOSTNAME (default localhost) and an optional GitHub App registration; press Enter to accept both defaults. When it finishes, open http://localhost — the portal guides you through the rest. For flags, TLS, troubleshooting, and updates, see the operator deployment guide.

CLI only (no platform)

If you already have the .NET 10 runtime and just want the spring CLI to talk to an existing instance:

dotnet tool install -g Cvoya.Spring.Cli
export SPRING_API_URL=https://your-spring-voyage-host
spring --help

Getting started

• Your first unit and agent — create a unit, send it a message, add an agent member.
• Spring Voyage OSS — a ready-made dev team — install the built-in spring-voyage-oss package.

Open core & license

Spring Voyage follows an open-core model. This repository is the complete, fully functional platform — agents, units, messaging, routing, execution, connectors, CLI, web portal, the package system, observability, cost tracking, A2A, and secrets. Multi-tenancy infrastructure is included, configured as a single-operator identity model.

It is licensed under the Business Source License 1.1 — free for personal, development, testing, and internal/production use (except offering it as a competing managed service), converting to Apache 2.0 on 2030-04-10.

Status, feedback & what's next

A lot already works; some things don't yet, and that's why it's an alpha. The open question we most want to explore with you: how does a human actually team with a fleet of agents over time? Tell us what broke, what felt good, and which mental model the docs failed to deliver.

• File issues: github.com/cvoya-com/spring-voyage/issues
• Share ideas: Discussions
• Roadmap & live progress: milestones
• Contribute: CONTRIBUTING.md · Security: SECURITY.md (please don't open public issues for vulnerabilities)

Links

• Website: spring.voyage · From: CVOYA
• Repository: cvoya-com/spring-voyage
• **...

Spring Voyage v1.0.0-alpha.20260604

Spring Voyage v1.0.0-alpha — first public release

Spring Voyage is an open-source collaboration platform for humans and the teams of AI agents they work with — developed by CVOYA and led by Savas Parastatidis. For news, examples, and the wider project, visit spring.voyage.

This is the first public release. Built because we needed it; now it's yours to run.

Warning

This is an alpha — on purpose. The substrate is solid and in daily use, but not every feature is fully wired or tested, the collaboration experience today is a chat interface, and the docs may lag the code. Expect rough edges and breaking changes between pre-releases (including database-schema resets). Feedback is very welcome — open an issue or join the Discussions.

What Spring Voyage is — and deliberately isn't

Spring Voyage lets humans and AI agents work together toward a goal in a domain, as members of the same team — each with their own roles, responsibilities, and expertise. Agents organize into composable units, connect to external systems through pluggable connectors, and communicate via messages.

The platform deliberately does not orchestrate. There are no predefined workflows or built-in routing logic; how a team communicates, collaborates, and organizes to solve a problem is left to the instructions and tools given to its agents. Most agent platforms lead with a workflow engine — Spring Voyage leads with the substrate and makes orchestration an optional choice a team makes (in plain instructions, in code, or in a framework like LangGraph reached over A2A), not a platform requirement. The platform delivers messages and records what happened; it doesn't own the routing policy.

What's in this release

• Messaging & typed addresses — communication between addressable members (agent:, human:, connector:), each with a partitioned mailbox, on a Dapr virtual-actor concurrency model with reliable delivery. The platform delivers; it doesn't interpret.
• Units — composable, nestable teams. A unit is itself just an agent that has children, so composition is recursive: a team can contain other teams. Agents can belong to multiple units.
• Tools, not workflows — every agent has a built-in sv.* toolset: sv.messaging.send / sv.messaging.multicast for delivery, sv.directory.list_members / sv.directory.get_status and sv.expertise.lookup for discovery, sv.runtime.report_decision to record why a decision was made, and sv.progress.report for the per-turn summary the operator sees. The platform exposes many more sv.* tools; agents discover the rest at runtime via sv.tools.list (and sv.tools.list_categories for what's available), so new capabilities surface without re-teaching every agent.
• Directory — discover who's on the team, what they know, and who has capacity right now. Collaborators are chosen by expertise, not a hardcoded org chart.
• Memory — a per-engagement history of the interactions between two or more participants, available to agents on a per-thread basis (sv.memory.*), plus a persistent local volume per agent. (A richer, self-organizing per-agent memory is on the roadmap.)
• Isolated agent runtimes — each agent runs in its own container. The "brain" can be Claude Code, Codex, Gemini, Ollama, a Dapr Agent, or any custom A2A agent (bring-your-own-image). Every agent is an A2A server and each turn is dispatched over A2A. Runtimes can host their own orchestration frameworks — LangGraph, Microsoft Agent Framework, CrewAI, Google ADK, OpenAI Agents SDK, Ruflo, Gas Town, and more.
• Initiative — agents can act with one of four levels of initiative (passive, attentive, proactive, autonomous), so they can reach out, not only be reached.
• Humans as first-class members — a real HumanActor on the same members: grammar as agents, plus the Hat model: one operator can wear different Hats across teams, each with its own per-team name and role.
• Connectors — pluggable integration with external systems. This release ships GitHub (deep) and Slack (personal workspace) connectors. Each translates external events into typed messages and surfaces actions as tools.
• Observability & cost tracking — every reasoning step, decision, and cost emitted as a structured ActivityEvent, streamed to the portal (with an Interactions view) and to other agents; per-conversation cost and per-agent budgets enforced by the platform.
• Secrets — a three-tier (platform / tenant / unit) model with AES-GCM at-rest encryption.
• CLI & Web Portal — manage the platform, configure teams, monitor budgets, and watch operations. The portal's new-unit wizard walks you through everything — LLM credentials, GitHub/Slack integration, and the rest — with no CLI required to get going.

Ready-made teams (packages)

Spring Voyage ships installable team packages — the clearest proof that the same substrate carries very different shapes of collaboration. Install from the portal's New Unit wizard or spring package install <name>:

• spring-voyage-oss — a working dev team (team-leader, software engineers, program managers, plus a human lead) that picks up work from a GitHub repository. Delegation-shaped: parallel, webhook- or request-driven, no central pipeline.
• magazine — a daily online-magazine team (editor-in-chief, writers, fact-checker, copy/audience/production editors, plus a human publisher). Workflow-shaped: sequential, human-initiated, with a final human approval gate — yet the "workflow" lives entirely in the agents' instructions, not in platform code.
• Plus software-engineering, product-management, and research domain packages, and minimal starter packages (hello-world, example-*) to fork from.

The platform never told the OSS team to be delegation-shaped or the Magazine team to be workflow-shaped — their instructions did. Read them, change them, or fork them.

One moment captures why that matters. Asked to produce the magazine's first edition — and to make it about Spring Voyage itself — the editor-in-chief came back with a proposed lineup and then offered to interview the founder, a nice touch nobody had requested. Minutes later the staff writer reached out directly with questions. Nothing in the package scripted that sequence; the team simply had a goal and a substrate to coordinate on, and the rest emerged.

Install

Spring Voyage runs on Linux or macOS with Podman 4+.

curl -fSL https://github.com/cvoya-com/spring-voyage/releases/latest/download/install.sh | bash

Two prompts — DEPLOY_HOSTNAME (default localhost) and an optional GitHub App registration; press Enter to accept both defaults. When it finishes, open http://localhost — the portal guides you through the rest. For flags, TLS, troubleshooting, and updates, see the operator deployment guide.

CLI only (no platform)

If you already have the .NET 10 runtime and just want the spring CLI to talk to an existing instance:

dotnet tool install -g Cvoya.Spring.Cli
export SPRING_API_URL=https://your-spring-voyage-host
spring --help

Getting started

• Your first unit and agent — create a unit, send it a message, add an agent member.
• Spring Voyage OSS — a ready-made dev team — install the built-in spring-voyage-oss package.

Open core & license

Spring Voyage follows an open-core model. This repository is the complete, fully functional platform — agents, units, messaging, routing, execution, connectors, CLI, web portal, the package system, observability, cost tracking, A2A, and secrets. Multi-tenancy infrastructure is included, configured as a single-operator identity model.

It is licensed under the Business Source License 1.1 — free for personal, development, testing, and internal/production use (except offering it as a competing managed service), converting to Apache 2.0 on 2030-04-10.

Status, feedback & what's next

A lot already works; some things don't yet, and that's why it's an alpha. The open question we most want to explore with you: how does a human actually team with a fleet of agents over time? Tell us what broke, what felt good, and which mental model the docs failed to deliver.

• File issues: github.com/cvoya-com/spring-voyage/issues
• Share ideas: Discussions
• Roadmap & live progress: milestones
• Contribute: CONTRIBUTING.md · Security: SECURITY.md (please don't open public issues for vulnerabilities)

Links

• Website: spring.voyage · From: CVOYA
• Repository: cvoya-com/spring-voyage
• **...

Spring Voyage v1.0.0-alpha.20260603

Spring Voyage v1.0.0-alpha — first public release

Spring Voyage is an open-source collaboration platform for humans and the teams of AI agents they work with — developed by CVOYA and led by Savas Parastatidis. For news, examples, and the wider project, visit spring.voyage.

This is the first public release. Built because we needed it; now it's yours to run.

Warning

This is an alpha — on purpose. The substrate is solid and in daily use, but not every feature is fully wired or tested, the collaboration experience today is a chat interface, and the docs may lag the code. Expect rough edges and breaking changes between pre-releases (including database-schema resets). Feedback is very welcome — open an issue or join the Discussions.

What Spring Voyage is — and deliberately isn't

Spring Voyage lets humans and AI agents work together toward a goal in a domain, as members of the same team — each with their own roles, responsibilities, and expertise. Agents organize into composable units, connect to external systems through pluggable connectors, and communicate via messages.

The platform deliberately does not orchestrate. There are no predefined workflows or built-in routing logic; how a team communicates, collaborates, and organizes to solve a problem is left to the instructions and tools given to its agents. Most agent platforms lead with a workflow engine — Spring Voyage leads with the substrate and makes orchestration an optional choice a team makes (in plain instructions, in code, or in a framework like LangGraph reached over A2A), not a platform requirement. The platform delivers messages and records what happened; it doesn't own the routing policy.

What's in this release

• Messaging & typed addresses — communication between addressable members (agent:, human:, connector:), each with a partitioned mailbox, on a Dapr virtual-actor concurrency model with reliable delivery. The platform delivers; it doesn't interpret.
• Units — composable, nestable teams. A unit is itself just an agent that has children, so composition is recursive: a team can contain other teams. Agents can belong to multiple units.
• Tools, not workflows — every agent has a built-in sv.* toolset: sv.messaging.send / sv.messaging.multicast for delivery, sv.directory.list_members / sv.directory.get_status and sv.expertise.lookup for discovery, sv.runtime.report_decision to record why a decision was made, and sv.progress.report for the per-turn summary the operator sees. The platform exposes many more sv.* tools; agents discover the rest at runtime via sv.tools.list (and sv.tools.list_categories for what's available), so new capabilities surface without re-teaching every agent.
• Directory — discover who's on the team, what they know, and who has capacity right now. Collaborators are chosen by expertise, not a hardcoded org chart.
• Memory — a per-engagement history of the interactions between two or more participants, available to agents on a per-thread basis (sv.memory.*), plus a persistent local volume per agent. (A richer, self-organizing per-agent memory is on the roadmap.)
• Isolated agent runtimes — each agent runs in its own container. The "brain" can be Claude Code, Codex, Gemini, Ollama, a Dapr Agent, or any custom A2A agent (bring-your-own-image). Every agent is an A2A server and each turn is dispatched over A2A. Runtimes can host their own orchestration frameworks — LangGraph, Microsoft Agent Framework, CrewAI, Google ADK, OpenAI Agents SDK, Ruflo, Gas Town, and more.
• Initiative — agents can act with one of four levels of initiative (passive, attentive, proactive, autonomous), so they can reach out, not only be reached.
• Humans as first-class members — a real HumanActor on the same members: grammar as agents, plus the Hat model: one operator can wear different Hats across teams, each with its own per-team name and role.
• Connectors — pluggable integration with external systems. This release ships GitHub (deep) and Slack (personal workspace) connectors. Each translates external events into typed messages and surfaces actions as tools.
• Observability & cost tracking — every reasoning step, decision, and cost emitted as a structured ActivityEvent, streamed to the portal (with an Interactions view) and to other agents; per-conversation cost and per-agent budgets enforced by the platform.
• Secrets — a three-tier (platform / tenant / unit) model with AES-GCM at-rest encryption.
• CLI & Web Portal — manage the platform, configure teams, monitor budgets, and watch operations. The portal's new-unit wizard walks you through everything — LLM credentials, GitHub/Slack integration, and the rest — with no CLI required to get going.

Ready-made teams (packages)

Spring Voyage ships installable team packages — the clearest proof that the same substrate carries very different shapes of collaboration. Install from the portal's New Unit wizard or spring package install <name>:

• spring-voyage-oss — a working dev team (team-leader, software engineers, program managers, plus a human lead) that picks up work from a GitHub repository. Delegation-shaped: parallel, webhook- or request-driven, no central pipeline.
• magazine — a daily online-magazine team (editor-in-chief, writers, fact-checker, copy/audience/production editors, plus a human publisher). Workflow-shaped: sequential, human-initiated, with a final human approval gate — yet the "workflow" lives entirely in the agents' instructions, not in platform code.
• Plus software-engineering, product-management, and research domain packages, and minimal starter packages (hello-world, example-*) to fork from.

The platform never told the OSS team to be delegation-shaped or the Magazine team to be workflow-shaped — their instructions did. Read them, change them, or fork them.

One moment captures why that matters. Asked to produce the magazine's first edition — and to make it about Spring Voyage itself — the editor-in-chief came back with a proposed lineup and then offered to interview the founder, a nice touch nobody had requested. Minutes later the staff writer reached out directly with questions. Nothing in the package scripted that sequence; the team simply had a goal and a substrate to coordinate on, and the rest emerged.

Install

Spring Voyage runs on Linux or macOS with Podman 4+.

curl -fSL https://github.com/cvoya-com/spring-voyage/releases/latest/download/install.sh | bash

Two prompts — DEPLOY_HOSTNAME (default localhost) and an optional GitHub App registration; press Enter to accept both defaults. When it finishes, open http://localhost — the portal guides you through the rest. For flags, TLS, troubleshooting, and updates, see the operator deployment guide.

CLI only (no platform)

If you already have the .NET 10 runtime and just want the spring CLI to talk to an existing instance:

dotnet tool install -g Cvoya.Spring.Cli
export SPRING_API_URL=https://your-spring-voyage-host
spring --help

Getting started

• Your first unit and agent — create a unit, send it a message, add an agent member.
• Spring Voyage OSS — a ready-made dev team — install the built-in spring-voyage-oss package.

Open core & license

Spring Voyage follows an open-core model. This repository is the complete, fully functional platform — agents, units, messaging, routing, execution, connectors, CLI, web portal, the package system, observability, cost tracking, A2A, and secrets. Multi-tenancy infrastructure is included, configured as a single-operator identity model.

It is licensed under the Business Source License 1.1 — free for personal, development, testing, and internal/production use (except offering it as a competing managed service), converting to Apache 2.0 on 2030-04-10.

Status, feedback & what's next

A lot already works; some things don't yet, and that's why it's an alpha. The open question we most want to explore with you: how does a human actually team with a fleet of agents over time? Tell us what broke, what felt good, and which mental model the docs failed to deliver.

• File issues: github.com/cvoya-com/spring-voyage/issues
• Share ideas: Discussions
• Roadmap & live progress: milestones
• Contribute: CONTRIBUTING.md · Security: SECURITY.md (please don't open public issues for vulnerabilities)

Links

• Website: spring.voyage · From: CVOYA
• Repository: cvoya-com/spring-voyage
• **...

Spring Voyage v1.0.0-alpha.20260601

Spring Voyage v1.0.0-alpha — first public release

Spring Voyage is an open-source collaboration platform for humans and the teams of AI agents they work with — developed by CVOYA and led by Savas Parastatidis. For news, examples, and the wider project, visit spring.voyage.

This is the first public release. Built because we needed it; now it's yours to run.

Warning

This is an alpha — on purpose. The substrate is solid and in daily use, but not every feature is fully wired or tested, the collaboration experience today is a chat interface, and the docs may lag the code. Expect rough edges and breaking changes between pre-releases (including database-schema resets). Feedback is very welcome — open an issue or join the Discussions.

What Spring Voyage is — and deliberately isn't

Spring Voyage lets humans and AI agents work together toward a goal in a domain, as members of the same team — each with their own roles, responsibilities, and expertise. Agents organize into composable units, connect to external systems through pluggable connectors, and communicate via messages.

The platform deliberately does not orchestrate. There are no predefined workflows or built-in routing logic; how a team communicates, collaborates, and organizes to solve a problem is left to the instructions and tools given to its agents. Most agent platforms lead with a workflow engine — Spring Voyage leads with the substrate and makes orchestration an optional choice a team makes (in plain instructions, in code, or in a framework like LangGraph reached over A2A), not a platform requirement. The platform delivers messages and records what happened; it doesn't own the routing policy.

What's in this release

• Messaging & typed addresses — communication between addressable members (agent:, human:, connector:), each with a partitioned mailbox, on a Dapr virtual-actor concurrency model with reliable delivery. The platform delivers; it doesn't interpret.
• Units — composable, nestable teams. A unit is itself just an agent that has children, so composition is recursive: a team can contain other teams. Agents can belong to multiple units.
• Tools, not workflows — every agent has a built-in sv.* toolset: sv.messaging.send / sv.messaging.multicast for delivery, sv.directory.list_members / sv.directory.get_status and sv.expertise.lookup for discovery, sv.runtime.report_decision to record why a decision was made, and sv.progress.report for the per-turn summary the operator sees. The platform exposes many more sv.* tools; agents discover the rest at runtime via sv.tools.list (and sv.tools.list_categories for what's available), so new capabilities surface without re-teaching every agent.
• Directory — discover who's on the team, what they know, and who has capacity right now. Collaborators are chosen by expertise, not a hardcoded org chart.
• Memory — a per-engagement history of the interactions between two or more participants, available to agents on a per-thread basis (sv.memory.*), plus a persistent local volume per agent. (A richer, self-organizing per-agent memory is on the roadmap.)
• Isolated agent runtimes — each agent runs in its own container. The "brain" can be Claude Code, Codex, Gemini, Ollama, a Dapr Agent, or any custom A2A agent (bring-your-own-image). Every agent is an A2A server and each turn is dispatched over A2A. Runtimes can host their own orchestration frameworks — LangGraph, Microsoft Agent Framework, CrewAI, Google ADK, OpenAI Agents SDK, Ruflo, Gas Town, and more.
• Initiative — agents can act with one of four levels of initiative (passive, attentive, proactive, autonomous), so they can reach out, not only be reached.
• Humans as first-class members — a real HumanActor on the same members: grammar as agents, plus the Hat model: one operator can wear different Hats across teams, each with its own per-team name and role.
• Connectors — pluggable integration with external systems. This release ships GitHub (deep) and Slack (personal workspace) connectors. Each translates external events into typed messages and surfaces actions as tools.
• Observability & cost tracking — every reasoning step, decision, and cost emitted as a structured ActivityEvent, streamed to the portal (with an Interactions view) and to other agents; per-conversation cost and per-agent budgets enforced by the platform.
• Secrets — a three-tier (platform / tenant / unit) model with AES-GCM at-rest encryption.
• CLI & Web Portal — manage the platform, configure teams, monitor budgets, and watch operations. The portal's new-unit wizard walks you through everything — LLM credentials, GitHub/Slack integration, and the rest — with no CLI required to get going.

Ready-made teams (packages)

Spring Voyage ships installable team packages — the clearest proof that the same substrate carries very different shapes of collaboration. Install from the portal's New Unit wizard or spring package install <name>:

• spring-voyage-oss — a working dev team (team-leader, software engineers, program managers, plus a human lead) that picks up work from a GitHub repository. Delegation-shaped: parallel, webhook- or request-driven, no central pipeline.
• magazine — a daily online-magazine team (editor-in-chief, writers, fact-checker, copy/audience/production editors, plus a human publisher). Workflow-shaped: sequential, human-initiated, with a final human approval gate — yet the "workflow" lives entirely in the agents' instructions, not in platform code.
• Plus software-engineering, product-management, and research domain packages, and minimal starter packages (hello-world, example-*) to fork from.

The platform never told the OSS team to be delegation-shaped or the Magazine team to be workflow-shaped — their instructions did. Read them, change them, or fork them.

One moment captures why that matters. Asked to produce the magazine's first edition — and to make it about Spring Voyage itself — the editor-in-chief came back with a proposed lineup and then offered to interview the founder, a nice touch nobody had requested. Minutes later the staff writer reached out directly with questions. Nothing in the package scripted that sequence; the team simply had a goal and a substrate to coordinate on, and the rest emerged.

Install

Spring Voyage runs on Linux or macOS with Podman 4+.

curl -fSL https://github.com/cvoya-com/spring-voyage/releases/latest/download/install.sh | bash

Two prompts — DEPLOY_HOSTNAME (default localhost) and an optional GitHub App registration; press Enter to accept both defaults. When it finishes, open http://localhost — the portal guides you through the rest. For flags, TLS, troubleshooting, and updates, see the operator deployment guide.

CLI only (no platform)

If you already have the .NET 10 runtime and just want the spring CLI to talk to an existing instance:

dotnet tool install -g Cvoya.Spring.Cli
export SPRING_API_URL=https://your-spring-voyage-host
spring --help

Getting started

• Your first unit and agent — create a unit, send it a message, add an agent member.
• Spring Voyage OSS — a ready-made dev team — install the built-in spring-voyage-oss package.

Open core & license

Spring Voyage follows an open-core model. This repository is the complete, fully functional platform — agents, units, messaging, routing, execution, connectors, CLI, web portal, the package system, observability, cost tracking, A2A, and secrets. Multi-tenancy infrastructure is included, configured as a single-operator identity model.

It is licensed under the Business Source License 1.1 — free for personal, development, testing, and internal/production use (except offering it as a competing managed service), converting to Apache 2.0 on 2030-04-10.

Status, feedback & what's next

A lot already works; some things don't yet, and that's why it's an alpha. The open question we most want to explore with you: how does a human actually team with a fleet of agents over time? Tell us what broke, what felt good, and which mental model the docs failed to deliver.

• File issues: github.com/cvoya-com/spring-voyage/issues
• Share ideas: Discussions
• Roadmap & live progress: milestones
• Contribute: CONTRIBUTING.md · Security: SECURITY.md (please don't open public issues for vulnerabilities)

Links

• Website: spring.voyage · From: CVOYA
• Repository: cvoya-com/spring-voyage
• **...