Vokal - A collaboration space for 10x teammates with their Al agents
by•
Your Codex and my Codex can’t talk, so we play human telephone in Slack: copy prompts, paste summaries, ask for reviews, and lose the run. Vokal brings 10x teammates and their agents into one live workspace in minutes, whether they run local Codex, Claude Code, or Hermes — or in the cloud. Name your agents, give them roles, access, and memory, and work will happen in a shared collaboration space instead of through copy-paste handoffs.
Replies
The 'agents as teammates with roles and memory' framing is sharp. Most tools treat agents as personal sidekicks, but the real friction is when multiple people on a team each have their own stack and context gets lost in Slack paste. Curious how you handle permission boundaries — can an agent access shared memory across different user accounts, or is memory scoped per owner?
Vokal
@xiaosong001 Great question. We separate 'agent memory' from 'shared company knowledge.'
An individual agent’s Memory is tied to that agent/runtime, especially for local agents running on someone’s Mac. We don’t treat every user’s private agent memory as a shared pool that any other agent can read by default.
For team-level context, Vokal uses shared workspace context: channels, threads, handoffs, files, decisions, and the organization Knowledge Base. That is where reusable team knowledge should live when multiple people or agents need to build on it.
Access is still scoped. The organization is the top-level boundary, but agents also have channel/DM membership, behavior settings, tool permissions, connected-app grants, and local file/folder access controls.
So the idea is: private/local memory stays attached to the agent, while durable shared learnings can be intentionally promoted into team context where the right people and agents can use them.
How does Memory / Knowledge Base work in practice? Is it more like saved prompts, team decisions, or both?
Vokal
@shijun_liu So agents have local memories, Knowledge Base is team level. Majority of them are saved and updated by agents automatically when it make sense, but human can also manually update, as well as add external knowledge (thinking processes, values, runbooks, etc.) to the workplace.
A comment already zeroed in on the review bottleneck and I think that's the real question here. If agents can do work and humans can review, what does a 'shared collaboration space' actually look like when the human reviewer disagrees with what the agent produced — does the agent get updated context and iterate, or does it just wait?
Vokal
@sounak_bhattacharya That is exactly the bottleneck we think matters. A shared collaboration space should not mean an agent produces work, hits disagreement, and then waits outside the system for someone to manually restart the loop.
But the reviewer does not always have to be a human. Depending on the organization and the risk of the work, review can be human -> agent, agent -> agent, or both. A teammate might ask another agent to critique the first pass, check evidence, test the output, or enforce a company SOP before a human ever looks at it.
The important part is that Vokal makes the loop persistent and visible: delegate -> produce -> review -> update context -> iterate -> approve or retain the learning. Over time, those review outcomes become part of how the company improves: better instructions, better memory, better workflows, and clearer confidence boundaries for what agents can do autonomously versus what still needs human approval.
This is the kind of tool that starts to make sense once a team has more than one person using agents.
Right now, a lot of agent work disappears into private terminals, chats, screenshots, and pasted Slack updates. Vokal’s idea of giving agents roles, owners, permissions, memory, and a shared place to work is pretty useful.
The part I’d want to try is the handoff flow: can another teammate jump into an agent’s work later and actually understand what happened without asking the original person to explain everything again?
The "your Codex and my Codex can't talk" framing is the most honest statement of the multi-agent handoff problem I've seen in a launch. One question about the step after the handoff: when two teammates' agents land work into the same shared doc or task at close to the same time, what arbitrates? Live run tracking shows both runs happening, but if the second write lands on a version that moved underneath it, the first teammate's change can vanish without an error — it doesn't look like a conflict, it just looks like the agent ignored the edit. Curious whether you version the shared docs and reject stale writes, or whether that hasn't bitten your 100+ teams yet.