Most AI interfaces are built around a simple assumption: you talk to one model, and that model gives you an answer.
But for difficult tasks, I rarely want just one answer.
What I want instead is a process:
- one agent proposes an approach;
- another challenges its assumptions;
- a third compares both and synthesizes a better solution;
- the next agent improves the resulting HTML, document, or code.
The response from one run should become working material for the next.
A real problem that needed more than one opinion
While building Agenvyl, I had to decide how it should handle temporary workspaces. Agenvyl creates an isolated directory for every agent run. The behavior was correct, but there was an obvious cost: even a request that only produced a text answer still caused a directory to be materialized, scanned, snapshotted, and eventually removed.
I wanted to reduce that filesystem work without weakening the isolation, parallel-run, and recovery guarantees around real file changes.
There was no obviously correct answer. An optimization that looked simple at the beginning of a run could quietly break publication semantics at the end of it. This was exactly the kind of architectural question for which I wanted several informed opinions rather than one confident response.
Doing this manually means juggling terminals and chat windows, copying prompts and responses, moving files around, and repeatedly explaining the current state of the work.
I built Agenvyl to give that process a shared structure.
More than a multi-model chat
The first important distinction is what Agenvyl is not.
It is not a chat interface that sends the same prompt to several models through a model router and puts their text responses side by side. That is a useful workflow, but it stops at the model API.
Agenvyl connects complete coding-agent harnesses: tools such as Codex CLI, Claude Code, OpenCode, Antigravity, and Hermes.
A model and a harness are not the same thing. The model provides the underlying intelligence. The harness is the working environment around it: tools, file access, terminal commands, MCP servers, skills, project instructions, hooks, permissions, approvals, authentication, and execution lifecycle.
That environment is often the reason I chose a particular coding agent in the first place. Flattening every tool into a common text-completion API would throw much of that value away.
So Agenvyl works at a different level:
The unit Agenvyl orchestrates is not a model completion. It is an agent run inside its native harness.
Each harness keeps its own models, accounts or subscriptions supported by that tool, skills, tools, MCP integrations, and permission system. Agenvyl does not reimplement or replace them. It adds the coordination layer around them:
- shared rooms and conversation history;
- parallel and sequential runs;
- a shared, versioned workspace;
- artifact handoffs between agents;
- retries, progress, questions, and approvals;
- explicit handling of conflicting file changes.
In short:
Agenvyl doesn't replace the coding agents I already use. It gives them a shared room.
From multiple answers to an actual discussion
Sending the same question to several models is easy. The more interesting part begins when their answers become input for the next round of reasoning.
For the temporary-workspace problem, I first asked an agent named Sol to inspect the actual Agenvyl repository rather than reason about the question in the abstract:
@Sol Check out the agenvyl repo. Currently, a temporary folder is
created for each run. Functionally, everything is fine: agents run in
an isolated folder. But there's a major drawback: every agent message,
even if it just outputs text, creates this folder, which is redundant.
How can I retain the current functionality but reduce system load?
Sol traced the real workspace lifecycle through the code and argued that the problem was larger than an unnecessary mkdir. A run could not know in advance that it would remain text-only: the harness might call a tool before producing its first token, and the Connector expected a workspace path to exist when the process started. Sol suggested changing the workspace model rather than adding a narrow shortcut.
I then turned to another agent in the same room:
@Opus What do you think?
That tiny follow-up is important. I did not copy Sol's answer into another application or reconstruct the problem from scratch. Opus could read the completed discussion, inspect the same repository, and evaluate the previous proposal in context.
Opus checked how Connector used the workspace path, examined the snapshot comparison logic, and then responded directly to Sol's analysis: it agreed with the diagnosis but disagreed with parts of the proposed priorities and architecture.
A real Agenvyl discussion: Sol analyzes the workspace lifecycle, then Opus reads the result, verifies it against the repository, and challenges parts of the proposal.
This is the difference between collecting answers and holding a structured discussion. One response is not necessarily the final result. It becomes material that another agent can inspect, verify, criticize, or extend.
I could also begin with a parallel round when I want to avoid anchoring:
@all Analyze the temporary-workspace problem independently.
Propose a safe optimization and explain its trade-offs.
Every agent launched by the same message receives the same conversation and the same starting files. They run independently and do not see one another's unfinished output. After they finish, I can ask another participant to compare their conclusions and synthesize a final design.
The workflow is no longer just parallel generation:
independent proposals
↓
explicit critique
↓
comparison of trade-offs
↓
synthesis
↓
implementation
Parallel generation gives me options. Multi-agent discussion turns those options into a decision.
This discussion is deliberately organized into rounds. Agenvyl does not hide an autonomous conversation behind the interface and hope that the agents eventually agree. Completed selected answers become part of the room history, and I decide who should respond next and what role the next round should play.
The human remains the editor of the process.
One agent creates, another improves
Discussion becomes much more useful when it can continue through real artifacts rather than copied text.
Suppose I want to create a landing page. I can begin with one agent:
@builder Create the first version of the landing page as index.html.
The agent works in a copy of the room workspace. When the run completes, Agenvyl captures the result and publishes its changes back to the room.
Now a second agent—possibly using a different model, harness, instructions, tools, and skills—can continue from the actual result:
@designer Review the current index.html and improve its visual hierarchy.
Keep the content and functionality, but make the design more distinctive.
Then another agent can take a different perspective:
@reviewer Inspect the updated page for accessibility,
responsive behavior, and usability. Fix the issues you find.
And a final pass might focus on implementation quality:
@optimizer Simplify the HTML and CSS and improve performance
without changing the approved design.
The result is an agent relay:
Builder creates the artifact
↓
Designer improves the visual direction
↓
Reviewer fixes accessibility and mobile issues
↓
Optimizer polishes the implementation
Each participant does not need to own the whole problem. One can create, another can challenge, and a third can refine.
More importantly, each participant brings its complete environment to the task. This is not simply model A generating text followed by model B generating more text. An agent can inspect the project, use its configured tools, follow repository instructions, call its MCP servers, and modify the shared artifact. The next agent receives the published files, not a prose description of what supposedly changed.
Shared chat was the easy part
Once several agents can edit files, orchestration stops being only a chat problem. It becomes a versioned-state problem.
Sequential work is straightforward: the designer starts after the builder has finished and sees the builder's published files. Parallel work is harder. If two agents start from the same workspace, neither should see the other's incomplete changes, and neither should silently overwrite newer work when it finishes.
Agenvyl gives every run an isolated copy of the published room workspace. The run records the snapshot it started from. When it completes, Agenvyl captures another immutable snapshot and compares three states:
- the run's starting snapshot;
- the latest published room snapshot;
- the run's result snapshot.
Non-conflicting changes can be published automatically. If the same path changed independently, Agenvyl keeps the current room version and records a conflict for the user to resolve.
┌─→ isolated run A ─→ result A
published workspace ─────┤
└─→ isolated run B ─→ result B
│
three-way merge
│
new version or conflict
This model supports both of the workflows I wanted:
- Independent discussion: several agents begin with the same context and produce proposals without influencing one another.
- Successive improvement: a later agent begins with the completed answers and published artifacts from earlier rounds.
It also makes retries explicit. A retry creates a new attempt instead of rewriting history, and the selected completed attempt is the one included in later conversation context.
Connecting different agent ecosystems
Under the hood, Agenvyl has a browser UI, a Core backend, a local Connector, PostgreSQL, and room workspaces.
Core owns the product state: rooms, messages, agent configurations, runs, events, and workspace versions. It does not start vendor tools directly and does not need their credentials.
Connector is the bridge to the coding-agent tools installed on the computer. It starts or contacts the selected harness and translates its protocol into events Agenvyl understands: progress, tool calls, approvals, questions, results, failures, and cancellation where the integration supports them.
This boundary lets Agenvyl coordinate different tools without pretending they all have identical capabilities. A Codex run remains a Codex run. An OpenCode instance retains its providers and controls. Claude Code keeps its own tool and permission behavior. Agenvyl normalizes enough to organize the work, but the harnesses keep their identity.
One harness can also power multiple participants. I can create agents with different names, instructions, models, reasoning settings, or permissions while using the same underlying tool. A room is therefore not limited to "one agent per vendor." It is a workspace for whichever combination of perspectives and environments fits the task.
Local-first, but not a sandbox
Agenvyl runs locally and adds no telemetry or remote analytics. The downloadable application includes its own Node.js and PostgreSQL, so using it does not require Docker, a source checkout, or a system Node installation.
The harnesses still communicate with their normal model providers according to their own configuration. Their credentials remain in their environment or credential stores; Agenvyl Core does not become a new model gateway.
There is an important trust boundary here: local-first does not mean sandboxed. Coding-agent tools run with the operating-system permissions of the user who started them. A room workspace is a shared working directory, not a security boundary. Agenvyl is currently a Technical Preview intended for a trusted, single-user computer.
I prefer stating that boundary directly. A tool that coordinates powerful local agents should make their access visible, not create a false sense of isolation.
What building Agenvyl changed for me
The most useful shift was conceptual.
I no longer think of every AI response as an attempted final answer. A response can be a proposal for another agent to criticize. A critique can become input to a synthesis. A generated file can be a draft for a different agent to inspect and improve.
The output of one run becomes working material for the next.
Different models are valuable because they can bring different perspectives. Different harnesses add another dimension: they bring different tools, skills, integrations, controls, and ways of working. Agenvyl is the layer that lets me combine those differences without discarding them.
It is still early. Agenvyl is an open-source Technical Preview, and the interaction patterns are something I am actively exploring. But the basic idea already feels more natural to me than choosing one model and expecting it to own every stage of a task:
Don't ask one agent to be the proposal, the critic, the designer, the implementer, and the reviewer. Give the work a place where several agents can contribute in sequence.
Try it
Agenvyl is open source under the Apache 2.0 license and currently supports Codex CLI, Claude Code, OpenCode, Antigravity/AGY, and Hermes. Installers are available for Windows, Linux, and macOS.
Repository and documentation: github.com/riffi/agenvyl
After creating a room, a simple first experiment is:
@all Propose the best approach to this task independently.
Then ask one participant to compare the completed answers:
@reviewer Evaluate the proposals, explain their trade-offs,
and synthesize the strongest solution.
Or create an artifact with one agent and ask another to improve the actual files.
Agenvyl sample workflow video:
I would be especially interested to hear which workflows become possible when the agent tools people already use stop living in separate conversations.
Top comments (1)
❤️❤️❤️