Launched this week
Vokal
A collaboration space for 10x teammates with their Al agents
1K followers
A collaboration space for 10x teammates with their Al agents
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.
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.
SocialEcho 2.0
How would a support team use this when a customer issue needs to become an engineering task?
Vokal
@eexlkuang_se A common flow is: support drops the customer issue into a Vokal channel, then asks a support agent (bringing up an agent into vokal is just one click, a lot of product development agent profiles are already pre-trained and ready to use) to summarize the symptoms, customer impact, repro steps, relevant screenshots/logs, and open questions.
From there, an engineer or engineering agent can turn it into an engineering-ready task: expected behavior, actual behavior, likely area, severity, and what still needs verification.
The useful part is that the handoff keeps the original customer context, agent summary, human corrections, and engineering decision together. So support is not just forwarding a messy thread; they are handing engineering a reviewed problem statement with context attached.
Vokal
@eexlkuang_se A practical flow is: support brings the customer issue into a Vokal thread with the relevant context — customer impact, screenshots/logs, repro notes, and any support conversation details.
Then a support or triage agent can turn that messy context into an engineering-ready brief: what happened, expected vs actual behavior, affected customer/user segment, severity, repro steps, open questions, and links to evidence.
From there, an engineer or engineering agent can create/update the task and continue in the same thread. The main value is that the customer context, support judgment, agent summary, engineering follow-up, and final decision stay together instead of getting reduced to a vague ticket like “customer says X is broken.”
Mapify
Does Vokal read all company data by default, or can teams scope what each agent sees?
Vokal
@xeasonchan there are permission and access control on both sides (company data, as well as agent permissions), but by default, the system encourages sharing (especially for read access) so that agents automatically get team context and be smart at what they do.
Vokal
@xeasonchan No, Vokal is not meant to give every agent blanket access to all company data by default.
Each agent has its own identity, owner, channel/DM membership, behavior settings, permissions, toolsets, local folder grants, and connected-app grants. So teams can keep an agent in a specific support or engineering channel, give it only the app/file access it needs, and use private channels when the context should stay limited.
There is baseline access so an agent can function inside Vokal, like reading messages delivered to it, replying, and resolving workspace context. But the design is explicit, reviewable scope rather than “everything unless you opt out.”
Is this more like a peer programming where coworkers can prompt / work with AI agent within the same context ?
Vokal
@vitan_baddam Yes, that’s a good way to think about one part of it. For engineering, it can feel like peer programming with AI agents: teammates can work in the same channel/task context, add missing context, redirect the agent, and review the output together.
But Vokal is broader than coding. The same shared context can be used for product specs, support handoffs, launch work, research, ops, and follow-ups.
The key difference from a private AI chat is that the prompt, sources, agent run, decisions, corrections, and review trail stay visible to the team instead of living on one person’s laptop.
@zhen_han While working with claude over the past few months, I always wondered if someone could pick up where I left off or someone could review and test the product I am developing. Sounds like Vokal is addressing this problem, will be exploring more !
Vokal
@vitan_baddam Great, feel free to book a demo session with me on vokal website https://vokal.team/
What does human review look like before an agent output ships?
Vokal
@joe_0417 For us, human review should happen before the final output, not only after an agent has produced a PR or finished artifact.
In Vokal, review starts in the shared thread: humans can check the goal, source context, assumptions, acceptance criteria, agent plan, intermediate output, tool actions, risks, and open questions while the work is still moving.
A reviewer or QA agent can do a first pass, like checking against criteria or listing missing evidence. But the human/team still makes the judgment call: approve, redirect, ask for more proof, narrow scope, or stop the work.
The key is that review becomes part of the live human + agent workflow, instead of a late-stage Slack paste or GitHub PR surprise.