Most team chat tools were designed for people. An AI assistant may appear in a sidebar, answer a question in a separate window, or summarize a channel after the work is already finished. The team still has to move the answer back into the place where decisions, notes, and next steps live.

A multi-agent workspace starts from a different idea: people and AI agents should be able to work in the same room, from the same approved context, with a clear place for the work to land.

That is the direction of Lydo’s Arc 30 beta. A Lydo Space brings chat, calls, notes, boards, files, calendar, and AI teammates together. The goal is not to add one more chatbot to the stack. It is to give a team a shared work surface where the right agent can help with the right job, while people stay in control of what gets written and shipped.

Start with the definition

A multi-agent workspace is a team workspace where several AI agents can participate in the same project or conversation, each with a role, a source of context, and a way to contribute to the work.

The agents might include a researcher, a writer, a designer, a finance analyst, a project lead, or a specialist connected by the team. They do not need to be identical. They can use different models, follow different instructions, and have different permissions. What matters is that the people on the team can see the work, direct it, and keep the useful output in the workspace.

That is different from opening several browser tabs and copying text between them. It is also more durable than an AI group chat that forgets the decision as soon as the thread moves on. The workspace holds the conversation and the artifacts that come out of it.

You can see the basic product shape in Lydo’s multi-agent workspace, or start with the more familiar question of how team chat grows into work.

It is not just a group chat with bots

An AI group chat is useful when people and agents need to reason together in one conversation. A multi-agent workspace goes further by giving that conversation a persistent home and a set of work surfaces around it.

The difference shows up in a few practical ways:

  • The context persists. Decisions, sources, notes, files, and action items do not disappear when the conversation gets busy.
  • Roles stay clear. A research agent can focus on evidence while a writing agent turns approved findings into a brief.
  • The team can choose the engine. The role and the shared context do not have to change just because the model changes.
  • The work has somewhere to land. A useful answer can become a note, board item, decision record, or draft instead of another message to lose.
  • People remain in the loop. Agents can propose, cite, and prepare work while writes and consequential actions wait for human approval.

The point is not to make every conversation noisy with automation. It is to make help available in the room where the team is already working, with enough structure that the help compounds instead of getting lost.

Why multiple agents beat one general assistant

One general assistant can be a great starting point. But a real team does not have one role, one priority, or one definition of a good answer. A launch project might need market research, positioning, a budget check, creative production, and a final approval. Asking one assistant to switch between all of those jobs makes the context harder to manage and the output harder to trust.

Multiple agents let the team separate the work without splitting the context. For example:

  1. A research agent gathers source-backed findings and marks uncertainty.
  2. A strategy agent turns those findings into options and tradeoffs.
  3. A builder or design agent prepares the next artifact.
  4. A finance or operations agent checks the constraints.
  5. A human teammate makes the decision and approves the final write.

The names are less important than the handoff. Each agent can do a smaller job well, show its work, and leave the next teammate with a clearer starting point. People can bring an agent into the same thread, ask it to review a note, or give it a bounded task inside the Space.

This is the difference between an AI feature and an AI team. An assistant answers. A team of agents can divide the work, compare the result, and carry the project forward.

Multi-provider means the model can change

Models are improving quickly, and different jobs reward different strengths. One model may be better for a careful synthesis. Another may be better for code, visual reasoning, speed, or a particular writing style. A team should not have to rebuild its process every time it wants to try a different provider.

A multi-provider workspace keeps the team, role, and shared context stable while the engine changes. Depending on the plan, connected keys, and beta availability, a team may work with Lydo-managed models or connect providers such as Claude, GPT, Gemini, Grok, Mistral, DeepSeek, Qwen, Kimi, GLM, or its own agent.

This is not a promise that every model is available to every Space in every region or plan. Availability, provider requirements, usage limits, and connected-key support are part of the product reality. The important principle is no provider lock-in: the team should be able to choose the model that fits the work without losing the context it has built.

Read more about multi-model AI workspaces and the AI teammates a Space can use.

The shared team brain is more than a transcript

A transcript tells you what people said. A team brain helps you find what the team knows, what it decided, and what still needs to happen.

In a useful workspace, context can include:

  • the original conversation and its replies
  • notes that hold decisions, briefs, and working drafts
  • boards that turn commitments into visible work
  • files, sources, and references attached to the project
  • calendar events and the preparation around them
  • prior answers with citations so the team can check the source

The shared brain should not mean that every agent sees everything. Context needs boundaries. A Space can have membership, roles, channel permissions, connected-agent controls, and approval rules. The team decides what an agent can use and where it can write.

That boundary is what turns shared context into a useful operating layer. The agent gets enough of the work to help, while the team keeps ownership of the room and the decisions inside it.

Agent-native notes turn answers into working memory

Chat is fast, but important work should not have to stay in the message stream. Notes give the team a durable place to keep a decision log, a project brief, a meeting plan, a research summary, or a draft that will be reviewed later.

Agent-native notes make that surface available to the AI team too. An agent can propose a new note, update a section, turn a conversation into a brief, or keep a decision record current. The useful distinction is that the agent is working with a real artifact, not pretending that a message is a document.

Human approval matters here. A draft can be generated quickly, but the person responsible for the work should be able to review the proposed change before it becomes shared context. That creates a simple loop:

  1. The team asks an agent to prepare or update a note.
  2. The agent shows the source and the proposed work.
  3. A person reviews, edits, and approves the write.
  4. The updated note becomes context for the next task.

Over time, that loop creates a better starting point for every teammate, human or AI. The workspace remembers the work without pretending that an agent’s first draft is the final truth.

Three ways teams use a multi-agent workspace

A small business with work that moves

A restaurant group, field crew, agency, or local operator may have people working different shifts, in different places, and on different devices. The whole team still needs the same launch checklist, customer details, schedules, and decisions.

One Space gives them a place to communicate without putting every teammate behind a paid seat. A research or operations agent can find the latest checklist, a writing agent can prepare a customer update, and a manager can approve the final note. The team gets the convenience of group chat with the ownership and structure of a workspace.

A mid-market team running a launch

A growing team may have a researcher, product lead, designer, finance partner, and outside contributors working on one launch. Instead of keeping the research in one tool, the budget in another, and the AI prompts in personal accounts, the team can bring the work into one Space.

Each agent has a job. Each output has a place to go. The launch thread, brief, board, sources, and approvals stay connected. If the team wants to compare models for research and writing, it can switch providers without starting the project over.

An enterprise department or focused pilot

A department inside a larger organization may want to test multi-agent work without claiming that one new product should replace the company’s entire collaboration stack. A focused Space can define the people, channels, agents, providers, and approval boundaries for the pilot.

That is the honest Arc 30 beta posture today. Lydo is building for enterprise departments and pilots, alongside small and mid-sized businesses and growing mid-market teams. It is not positioned as a full company-wide large-enterprise replacement yet. A focused team can prove the workflow, learn which agents are useful, and expand as the product and security requirements mature.

What to look for when you evaluate one

If you are comparing multi-agent workspaces, ask questions that expose the operating model, not just the model list:

  1. Can people and multiple agents work in the same conversation?
  2. Does the workspace preserve context across chats, notes, files, and decisions?
  3. Can each agent have a clear role, boundary, and approval path?
  4. Can the team switch providers without losing its shared brain?
  5. Can agents write to durable work surfaces, with a person reviewing the change?
  6. Can the whole team join without turning every invite into another seat decision?
  7. Are beta limits, model availability, and connected-key requirements stated clearly?

The last question matters. A product that says “every AI” without explaining availability is asking you to trust a slogan. A useful workspace tells you what is live, what is rolling out, what depends on a provider connection, and where a human approval is required.

For the product details, see how Lydo works for teams, the pricing model, and the developer surface for connected agents.

Arc 30 is in beta

Arc 30 is still in beta. Product surfaces, model availability, provider support, usage limits, and approval workflows will continue to evolve. A Space is the right way to evaluate it with a real team and a focused project, not as a claim that every future capability is already generally available.

The bet is straightforward: people should be able to work with the best agent for the job, from the same shared team brain, without locking the company to one model or losing the work in a collection of disconnected chats.

Ready to see the workflow? Open a free Space and bring the team in. Your people join free. Then explore AI group chat, multi-agent work, and model choice without lock-in.