Today I’m pushing Spring Voyage out of the harbor. You can track its journey on GitHub – Spring Voyage, supported by CVOYA LLC.

This is an early “alpha” release. The substrate is in a good state; I’ve been playing with it for weeks. But I wouldn’t call it “ready.” It needs to be exercised by users other than me. Not all the features are quite wired or even functioning. Development continues.

Spring Voyage is an open-source collaboration platform for humans and the teams of AI agents they work with. Before I say what it does, I want to say why it exists, because the why is the whole design.

Why I built it

I didn’t set out to build an agent platform. I set out to ship CVOYA‘s personal intelligence (alwyse) product faster.

I’m the solo founder and employee of CVOYA. The constraint that shapes everything is that there’s one of me. So back in February I wrote about a small team I’d stood up instead of hiring — Ada and Dijkstra on the backend, Kay on the frontend, Hopper on infrastructure, and a “team leader” watching a GitHub project board, handing out work, collecting PRs. It was held together by Python modules, git worktrees, and a handful of conventions. It worked better than I had any right to expect. You can see the effect on the repo at the time: once that private version of Spring Voyage started helping me with my tasks for the alwyse project, my weekly commits (PRs with squash+merge) jumped almost fivefold — while keeping my work hours the same. Not because the agents took over everything, but because the typing was parallelized while the judgment stayed with me. (The commits taper off afterwards — that’s when I turned my attention to building this new version of Spring Voyage.)

But that first version was, underneath, an orchestration engine. It encoded one particular way of doing software engineering — a workflow I’d custom-built for my own needs and hard-wired into a Python team leader. That leader handed out work; the agents on the receiving end had no idea they were part of a team at all. They were workers at the end of a delegation, not collaborators who could see each other. It worked, but the shape of the work was baked into the machinery. It helped with parallelizing work but it was not generalizable to other ways of doing software engineering or even other application domains.

That experience changed the question I was asking. The thing that was working wasn’t really about code — and the part with the most potential wasn’t the orchestration I’d hard-coded. It was the idea of a group of collaborators with different expertise, a shared sense of what was happening, and a human in the loop where it mattered. GitHub was scaffolding. The hard-wired workflow was scaffolding too. The pattern underneath was domain-agnostic and it was hinting at human-agent collaboration.

So I rewrote the whole thing — the twelve-day rebuild — and generalized it. Not a tool for managing coding agents. Not yet-another agent workflow or orchestration engine. I set out to build a substrate for any team of humans and agents to work together, whatever the work is. The bet was that if software engineering benefited this much from giving agents and humans a shared place to collaborate, the other functions of a company would too. Operations. Research. Writing. Support.

I’m not alone in seeing this. Over the past year the big labs have been racing to give their agents team-shaped features — Anthropic shipped an experimental Agent Teams mode for Claude Code where instances share a task list and message each other directly; OpenAI launched Workspace Agents that run continuously and plug into the tools a team already uses. The direction is clear: agents are becoming teammates, not just tools. Spring Voyage is a bet in that same space — with a particular insistence that humans are teammates too. Part of the roadmap (not implemented yet) is that agents have their own long-term memory beyond what AI tools offer today, they gather experiences, they accumulate knowledge, they learn and evolve through their engagements and collaboration with other agents and humans as they all perform their domain-specific tasks.

That’s where we are now. Spring Voyage ships with the ability to host teams that you create from the pre-packaged ones or the ones you build from scratch across any domain. One of the pre-packaged ones is a software-engineering team that helps with the development of Spring Voyage itself. Another one is a daily online magazine team. Same platform, same primitives, two completely different shapes of human-agent collaboration for two completely different domains. More on both below.

What Spring Voyage is — and what it deliberately isn’t

Here’s the line from the project’s own Vision that everything hangs on:

The Spring Voyage platform does not prescribe a particular way of working. It does not have predefined workflows or orchestration logic for teams of agents. Instead, it offers the necessary primitives for teams of agents and humans to be defined by users. How they communicate, how they collaborate, how they organize to solve problems is left to the instructions and tools that are given to the agents.

It’s worth separating three things the field tends to collapse into one.

• The substrate is the bottom layer: the capabilities and communications every collaborator needs — reliable messaging between addressable members, discovery of who knows what and who has capacity, shared memory of the interaction history between 2-N participants, private memory, observability, isolated hosting environment, boundary policies, configuration, integration with third-party services, protocol-based APIs, a core set of tools to act with, and more. This is what Spring Voyage provides.
• Collaboration is what emerges on top of the substrate. It isn’t something the platform scripts — it’s the actual back-and-forth: what agents and humans say to one another, what they exchange, what they accomplish together by leveraging the building blocks the substrate offers and the tools available in their own containers. The platform doesn’t author the collaboration; it makes it possible and then gets out of the way.
• Orchestration (or workflow) management is approached differently by Spring Voyage. It is a way to encode how work should be sequenced and routed — who does what, in what order, with which hand-offs. That’s a perfectly reasonable thing to want, and Spring Voyage lets you have it — as a choice a team makes, not a platform requirement for when a team of agents and humans is formed. A team’s routing can live in plain code, in a workflow system like LangGraph, in another agent framework reached over A2A, or in nothing more than the natural-language instructions you give the agents. Want a rigid pipeline? Define one. Prefer to let the agents reason based on the messages and data they receive before making a decision? That’s ok too. The Spring Voyage OSS and Magazine teams discussed in this post follow the latter approach… collaboration flows through instructions, not workflows.

That’s the inversion. Most agent platforms lead with orchestration — they hand you a workflow engine and a graph to fill in. Spring Voyage leads with the substrate and makes orchestration optional and configurable. You select which technology to use. Spring Voyage is not an orchestration platform. Orchestration is one of the many roles an agent can play. The platform delivers messages and records what happened; it doesn’t manage the routing policy.

Concretely, here’s what the substrate gives every team:

• Communication. Messaging between addressable members — agent:, human:, connector: — each with a partitioned mailbox. The platform ensures the delivery of the messages; it doesn’t interpret them for the purposes of routing or workflow state management. Messaging primitives are available as MCP tools.
• Discovery of expertise. A directory every agent can call: who’s on the team, what do they know, who has capacity right now? Collaborators are picked by what they know, not by a hardcoded org chart. Also available as MCP tools.
• Memory. Different memory tools, all available as MCP tools:
  • Each agent may maintain memories across all the conversations in which it participants.
  • Each interaction thread between 2-N participants (humans and agents) is stored by the platform and is available to agents.
  • Each agent may also choose to store interaction-specific memories (e.g. “bob said the draft was ready”). Such memories are attached to the specific set of participants.
  • (Upcoming) A per-agent memory system that self-organizes, correlates memories, creates abstractions, supports fast recall, and much more. It will help each agent acquire experiences, build up knowledge, and evolve in the context of the domain in which it is operating. This is related to Alwyse.
• Agent hosting. The platform manages a docker/podman container for each agent so that it can have its own isolated workspace. The platform manages the propagation of secrets, implements tenant-based security, API authorization, secrets rotation, token renewal and invalidation, etc. The agent’s “brain” can be Claude Code, Codex, Gemini, Ollama, an A2A peer, or anything else that fits the platform-agent A2A-based contract. Users can push their own container images with the tools needed by the agents they create.
• Engagements and collaborations. Durable shared threads, keyed by who’s participating — the place work accrues over time, with humans and agents on the same footing. Engagement-oriented user experience. Today, it’s just a chat interface but there is thinking to expand that area to an intelligence-driven collaboration surface.
• Observability. Every reasoning step, decision, and cost emitted as a structured ActivityEvent — streamed to a portal, to subscribers, and to other agents, so one agent can watch another’s work, learning through observation.

The platform tells members how to communicate. It doesn’t tell them how to organize and how to work.

Two teams, one substrate

The cleanest way to feel what “the platform delivers messages; the team decides what to do with them” means is to look at the two teams that ship in the repository. They use the same messaging substrate, the same directory services, the same memory primitives, the same activity stream, the same human-member grammar. The platform is the same in both cases. Yet, they perform completely different functions.

Team one: Spring Voyage OSS

A working organization that helps with the development of Spring Voyage OSS itself. Install it via the SV Web portal by initiating the “New Unit” wizard or via the CLI with spring package install spring-voyage-oss. Follow the instructions and you are ready to go. You can check how the team is defined and the instructions given to each agent at the the repo’s packages/ folder.

• 1 team-leader agent — receives GitHub-webhook-derived events or instructions via the chat interfaces, then decides how to dispatch work to the right member.
• 5 engineer agents stamped from a software-engineer template — Ada, Hopper, Knuth, Ritchie, Turing. They are responsible for implementation, code review, and the build/test/lint loop. Five instances let independent work run in parallel. When the team is configured to use Claude Code, each software engineer benefits from Claude’s agent profiles saved in the Spring Voyage repo.
• 2 program-manager agents — Drucker and Deming. They own triage, milestone hygiene, and dependency tracking.
• 1 human overall-lead — the escalation target when the team leader genuinely can’t decide where something belongs.

Unlike my previous, private version of Spring Voyage, there’s no intermediate orchestration logic encoded in code. The team leader reads the inbound event (GitHub event or user message), calls the relevant platform tools to find team members, their roles, their expertise, and their status, and then sends them a message. Its behavior is described using natural language in its instructions. You can go view and edit them. All the agents in the team communicate through the exchange of messages. Each agent can now reason about the messages and events it receives and make calls about what should happen next, even dealing with situations that might not have been described to it before. Of course, if you prefer to have a deterministic workflow/orchestration execution engine, you can absolutely build such a team.

The Spring Voyage OSS team represents a delegation-shaped team: parallel work, webhook-driven or human request-driven, no central pipeline.

Team two: Magazine

A daily online magazine. Install via the Web portal’s “New Unit” flow or using the CLI: spring package install magazine. Open a conversation with the Magazine Director, and the team produces an edition. The team roster:

• 1 Magazine Director (Editor-in-chief). Plans the edition, sets editorial direction, signs off before publication.
• 6 specialist roles — Managing Editor (runs the floor, assigns stories, routes drafts), Staff Writer (reports and drafts), Fact-Checker (verifies every checkable claim), Copy Editor (polishes without reshaping), Audience Editor (writes the headline and promo line), Production Editor (assembles the running order and walks it through approval).
• 1 human publisher with role approver — receives the assembled edition and either signs off or returns notes.

The work moves through a pipeline: writer → fact-checker → copy-editor → audience-editor → production-editor → editor approval → publisher approval → publish. However, as it is the case with any such team, members of the team are allowed to communicate directly with one another or even in subgroups. Each assignment carries four things: what to do, the deadline, anything non-negotiable from the editor, and where the finished work goes next. The default route is the pipeline; the editor can override it any time, and the managing editor honors the override. Context flows by two rules: each member keeps private local memory, and sharing happens through messages.

This is a workflow-shaped team: sequential, human-initiated, with a hard human approval gate at the end. But an actual workflow isn’t predefined in code. The platform doesn’t manage the execution of the workflow. It all happens through natural language-based instructions and communication. This allows for flexibility but also comes with coordination challenges, especially in the presence of delayed responses to requests from the Managing Editor who is responsible for the edition’s pipeline. In testing, I communication getting crossed, the Managing Editor and other members repeating each other, forgetfulness, etc. I think it’s a fascinating space that involves a completely separate discussion about the relationship of cross-agent coordination and how to achieve consensus when using just natural language like humans do vs employing a formal coordination protocol.

Story time

One moment from working with this team, during one of the tests, has stuck with me. I asked the Magazine Director to produce the magazine’s first edition, and to make it about Spring Voyage and the company behind it. It came back with a proposal — the lead articles, the angle — and then asked whether I’d be open to being interviewed for the issue, since it thought a founder interview would be a nice touch. I agreed, both to the direction and to the interview. A few minutes later the staff writer messaged me directly, introduced itself, and sent over its interview questions.

Nothing scripted that. There was no workflow step that said “offer the founder an interview,” no instruction telling the Director to have the writer reach out to me, no prescribed sequence at all. The team had a goal, a substrate to coordinate on, and the latitude to decide together how to pursue it. That small, slightly uncanny moment is the whole thesis in miniature: the interesting behavior wasn’t orchestrated — it emerged.

Same primitives, different shapes

Spring Voyage didn’t tell the OSS team to be delegation-shaped or the Magazine team to be workflow-shaped. The author of the instructions told them using natural language; whoever installs the packages can change those instructions or create their own teams from scratch. The orchestration — the workflow, the routing, the gates — is a function of the agents’ instructions, not a feature of the platform. If your team needs a third shape nobody’s tried, that shape comes from the prompts and tools you give your agents, not from a registration step or a configuration option in the platform.

Humans as first-class members

The part I most want to flag, because I think the field, IMHO, has generally under-emphasized it: humans aren’t observers or escalation tickets. They’re on the team.

A human is declared as part of a team’s members: list with the same grammar as an agent. In fact, in the current version of the platform, there is a rule that if there is no human in the team, the user cannot communicate with any of that team’s members.

members:
  - agent: managing-editor
  - agent: staff-writer
  - human:
      roles: [approver]
      notifications: [escalation, completion]

When an agent decides a piece of work needs the human, it initiates an interaction with them if the required capabilities for the human match the requirements for the task or the agent’s instructions for escalation — the same way the decision is made to interact with another agent. The human could be described as a peer of any other agent in the team with a specific expertise or as the ultimate authority on a decision. In the case of the Magazine, the human is described as the “publisher”, suggesting that their expertise is “final editorial judgment.” The Spring Voyage OSS human, as an overall lead, is described as having the expertise to help “when the agent team leader can’t decide what to do.”

The Hat abstraction makes it possible for one operator, one real user of the Spring Voyage OSS platform, to act as a different member of a team through the same Web portal or CLI. The inbox view in the portal shows the Hat; replies stay on the Hat the thread came in on. I am one person playing many roles is supported by the platform.

Why open source

A platform is only as good as the ecosystem around it. Spring Voyage is infrastructure — the kind of thing that gets better when other people run it, extend it, write packages and connectors for it, and tell me where it breaks. I built it for myself, but it’s worth more to me, and to everyone else, as something a community can build on than as a private tool I maintain alone.

There’s a practical side too. This is software you run yourself — on a workstation or your own VPS. Self-hosting a platform you can’t see into is a hard sell. Reading the code, changing the team prompts, swapping a component, forking it if you need to — that’s just part of what it means to actually own your deployment.

So the core is open. Spring Voyage is licensed under the Business Source License 1.1: free for personal, development, internal, and most production use, restricted only against repackaging it as a competing managed service. It converts to Apache 2.0 on 2030-04-10 — guardrails for the company for four years, then fully open.

The collaboration UX is an open experiment

The agents work. The CLI works. The portal works. The cost tracking, the streaming activity feed, the connector loop, the directory, the Hat model — they work (for the most part).

What I don’t think anyone has solved yet, me included, is how a human actually teams with a fleet of agents over time. When should an agent interrupt me, and when should it keep going? What is the unit of collaboration? Is it a message? Is it a note? Is it a UI card or a document? Perhaps a video? Is it the same across domains? When two agents disagree, do they wake me or settle it and tell me later?

This initial alpha version of Spring Voyage doesn’t attempt to explore these questions. There is only the chat interface. I am open to ideas. These are questions I am exploring as part of my Alwyse “personal intelligence” project as well.

The state of this alpha

A few things genuinely work today, and they’re the parts the rest of this post leans on:

• Humans and agents in one team definition. Both are actors in the system; a team — what Spring Voyage calls a unit — is itself just an agent that has children, so composition is recursive: a team can contain other teams.
• Tools, not workflows. The platform provides MCP tools to the agents for messaging, agent/human discovery, tools discovery, memory, etc.
• A2A throughout. Every agent is an A2A server in its own container, and the platform dispatches each turn over A2A. The Spring Voyage agent runtime is just one such image — bring your own, and what it does on a turn, including delegating to an external orchestrator like LangGraph, is your call.
• Observability and cost tracking. Every reasoning step, decision, and cost is captured as an activity, streamed to a portal with an Interactions view (graph, matrix, timeline, live) and rolled up into per-conversation costs and per-agent budgets.

And, just as honestly, plenty isn’t ready — hence “alpha.” Of the connectors, GitHub and Slack work; web search and arxiv aren’t implemented yet. Some of the budget and analytics work isn’t wired. The policies work isn’t in place. Codex and Gemini are coded but untested. Initiative is implemented but hasn’t been exercised end-to-end. The documentation may be out of sync with reality.

Check out the open issues and add new ones, or use the Discussions forum for feedback and ideas. File issues. Send PRs. Tell me what broke, what felt good, and which mental model the docs failed to deliver.

A hosted service might be coming

For people who’d rather not operate a Postgres and a Dapr sidecar, a hosted Spring Voyage Cloud might eventually add multi-tenancy, SSO/SAML, billing, and a few advanced features on top of the open-source core. I will decide whether to invest time/effort depending on the interest I receive. So yes… if you are interested in a hosted service, drop me a line or share your thoughts in the Discussions forum.

But the OSS project is the main story. The BSL takes no feature away from you — self-host and you have the entire platform.

What you can do today

• Install the Spring Voyage OSS platform

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

• If you prefer to build through source: Clone the repo: github.com/cvoya-com/spring-voyage.
• Run it locally with the getting-started guide.
• Install a team — Use the Web Portal for guided instructions (if you accepted the defaults on your local machine, just point your browser to http://localhost).
• File an issue for anything that breaks, confuses, or that you wish existed.
• Star the repo if you’d like to help the effort.
• Send a PR — CONTRIBUTING.md covers the workflow.

If you’re in the AI-agent community and want to compare notes on how the rest of you are solving the human-team UX problem, please reach out. That’s the conversation I most want to have.

A small note to close

I named this Spring Voyage because the metaphor felt right to me. Spring for renewal — a fresh start on what a platform for human-agent collaboration should be. Voyage for the exploration into what this kind of collaboration can be: a long crossing, with weather and instruments and a crew, under a sky you can read. The platform doesn’t tell the crew how to sail. It gives them a working ship, instruments they can read, and a way to talk to each other. The rest is theirs.

And also… “Spring Voyage” is part of the CVOYA family. The “voya” in CVOYA stands for “voyage”.

The boat is in the water. There’s a fleet to build. Welcome aboard.

---

Spring Voyage (v1.0.0) is licensed under the Business Source License 1.1 and converts to Apache 2.0 on 2030-04-10. Repository: github.com/cvoya-com/spring-voyage. Project home: spring.voyage. License: LICENSE.md. Contributing: CONTRIBUTING.md. Code of Conduct: CODE_OF_CONDUCT.md. Security: SECURITY.md.