Launched this week
Vokal
A collaboration space for 10x teammates with their Al agents
1.1K followers
A collaboration space for 10x teammates with their Al agents
1.1K followers
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.
Congrats on the launch! Curious what happens when two agents disagree on the same task does Vokal flag the conflict somehow or just pick one of the outputs?
Vokal
@munis_abbas We don’t silently pick one output.
If two agents disagree, their outputs stay visible in the same task/thread with agent identity and context attached. The team can compare the reasoning, ask a follow-up, or assign a reviewer agent/human to reconcile it.
For us, the important part is not pretending agents always agree. It’s making disagreement visible enough that a human can make the final call instead of losing one side in a private chat.
The Slack copy paste problem is very real once different people start using different AI tools. I like the idea of agents having roles and owners instead of everyone keeping their own private workflow. The useful part for teams might be less abt adding another AI tool and more abt making the work visible enough for others to review and continue. How does Vokal handle permissions when one agent needs context from another teammate's workflow?
Vokal
@ada_johnsen That’s the exact problem we’re trying to avoid: shared context should not mean blanket access.
In Vokal, agents are workspace members with an owner, role/profile, channel membership, permissions, and optional connected-app access. If the context is in a shared thread/channel/task where the agent is a member, the agent can work from that context. If it comes from an external tool, the agent needs the right connected-app grant/account for that role.
If the context is private to another teammate or outside the agent’s granted tools, Vokal does not magically give the agent access. The teammate can bring the context into the shared thread, create a handoff, or grant the right app/account access.
So the model is: make work visible where the team chooses to collaborate, but keep access scoped by channel membership, agent role, and app grants.
How granular are the app permissions? I’d want agents to access the right tools without giving them the whole company.
Vokal
@song_kirby That is exactly the control model we care about. App access is scoped to the agent/profile, not just “connect the company account and let every agent use it.”
In practice, an agent can inherit the app access its role needs, and you can also override or directly grant access for a specific agent. We also track which connected account/toolkit is assigned, whether access is ready or missing, and which agents are using which apps.
For sensitive actions, our bias is review-first: let agents read the context they need and prepare drafts or handoffs, rather than silently mutating external systems.
So the goal is right agent, right app/account, visible usage. Not blanket access to the whole company.
AISA AI Skills Test
the review step in that flow is where most teams actually break down. everyone can set goals and agents can do work, but 'humans review' requires a skillset most teams havent developed yet — knowing what to check, how deeply to verify, and when to trust vs question the output. curious how Vokal handles that evaluation layer.
Vokal
@ozandag Great point. We don’t think the answer is "one human reviewer checks the agent at the end."
Software development is a team sport. Product, design, support, engineering, QA, and domain experts all carry different parts of the evaluation layer.
AI has made the code-writing part much faster, which means waiting until a GitHub PR is often too late. The important review needs to move left: before and during the agent run.
In Vokal, the brief, assumptions, sources, acceptance criteria, agent plan, outputs, test results, risks, and human corrections can stay in the same shared thread. A reviewer or QA agent can help do first-pass checks, but the real value is that the right humans can question scope, evidence, tradeoffs, and readiness while the work is still forming.
So evaluation is not a final gate. It becomes a shared human + agent workflow around the work itself.
The handoff between agent stacks is a real pain. How does Vokal decide which agent owns context when two are working on overlaping tasks? Is there a permission layer per repo, or just per workspace?
Vokal
@christian_knaut We don’t think one agent should privately ‘own’ the context. In Vokal, the shared thread/channel is the live workroom. If two agents are touching overlapping parts of a problem, humans and agents can see the same evolving context, assumptions, outputs, and handoffs while the work is happening.
That means overlap is handled by coordination, not hidden arbitration: one agent can investigate, another can implement, a human can redirect, and a reviewer agent or teammate can reconcile conflicts before they turn into a bad PR.
Permissions are layered separately: workspace/org boundary, channel membership, agent tool permissions, connected-app grants, and local folder access for local agents. So access is scoped, but the collaboration model is real-time shared work, not isolated private agent runs pasted back into Slack
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.