Vokal - A collaboration space for 10x teammates with their Al agents

@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

@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.

@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.”

@min_zhou Exactly. Looking forward to seeing how your team will use it.

@min_zhou Thank you. That’s exactly the shift we’re designing for.

Once agents become part of real work, the problem is no longer just “which AI tool should I use?” It becomes: where does the work live, who owns it, what context was used, who reviewed it, and what should the team remember next time?

That operating layer is what we think teams will need as agent usage moves beyond private experiments.

@alina_tyslenok_ Thank you! That scattered context problem is exactly what pushed us to build Vokal.

Agents are becoming part of real work, but too much of that work still lives in private chats, local terminals, docs, and screenshots. We want the goal, context, agent run, output, and review to live in the same shared place so teammates can actually understand and continue the work.

@hanzhizhang0405 Exactly. Once agents move from 'personal assistant' to doing real team work, visibility becomes part of the workflow, not a nice-to-have.

For each meaningful agent run, the team should be able to answer: what was the goal, what context was used, what changed, where is it blocked, who reviewed it, and what should be remembered for next time.

That is the layer we’re building Vokal around.

@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.

@madalina_barbu Thank you!

@tina_chhabra Exactly. The screenshot-in-Slack workflow loses the important parts: the prompt, source context, intermediate reasoning, tool actions, corrections, and why the final output changed.

Our goal with Vokal is to make the agent run itself part of the team thread, not something that happens elsewhere and gets summarized afterward.

So humans can ask, agents can work, teammates can add context, and the handoff/review stays in one place.

@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.

@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.