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

@zhen_han Excited to see more products tackling the collaboration layer of AI, not just the intelligence layer.

Congrats on the launch!

@vikramp7470 Great question Vikram. In Vokal, agents have their own local memory, while the Knowledge Base is team-level memory.

Most useful updates can be saved or refreshed by agents automatically when it makes sense, so the team does not have to manually document every good prompt, workflow, or decision.
Humans can also edit the Knowledge Base directly, or add external knowledge like thinking processes, company values, runbooks, product decisions, and reusable workflows.

@vikramp7470 It’s both manual and AI-assisted, but not an automatic dump of every thread.

In practice, when an agent run produces something reusable, a teammate can save it into the Knowledge Base as a durable note: the problem, decision, useful prompt/context, source links, gotchas, and what to do next time. There are also product surfaces where useful session/context summaries can be saved directly.

Agents can help with the curation too. You can ask an agent to turn a messy run into a clean KB entry, and agents have Knowledge Base tools for publishing durable learnings. Humans can then edit or archive the article.

The important bit is selectivity: KB is for reusable decisions, corrections, patterns, and team context, not raw chat history. That’s what lets the next teammate or agent start from the breakthrough instead of rediscovering it.

@artltvk That’s a fair question. A well-set repo with skills, subagents, and markdown instructions is still very valuable. We use that kind of context too.

But repo context mostly helps the agent execute inside the codebase. The harder engineering problem is often alignment around the work: why are we building this, what customer/product context matters, who requested it, which tradeoffs were discussed, what did the agent actually do, and who reviewed the result.

As AI makes implementation faster, the risk is not just 'bad code'. It’s fast work with missing shared context. Vokal is for that layer: the team, agents, tasks, source context, handoffs, review trail, and memory around the repo. If you’re one engineer in one repo, markdown may be enough. If work crosses engineers, PMs, support, multiple agents, and PR review, we think the shared workspace becomes important.

@thekrew Exactly. The failure mode isn’t usually that the agent did nothing, it’s invisible work. Who asked? What context was used? What changed? What still needs review before it ships?

Vokal makes that trail native: agent identity, permissions, ownership, handoffs, event history, and human review stay attached to the work. And because it’s indexed, teams (including humans and agents who have the right permission) can search and reuse that context later instead of rebuilding a manual paper trail in spreadsheets or Slack paste.

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

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

@ea_z often the important ones, message level: approvals, handoffs, request, results, etc.

@ea_z The goal is to show enough provenance for the team to review and continue the work, not to expose a raw token-by-token trace.

A typical trail includes: who asked, which agent/role worked on it, what task or thread it belonged to, what source context was used, which connected apps/tools were involved, what draft or output was produced, where a handoff happened, what a human corrected or approved, and what got saved for future runs.

So if an agent moves across something like support context -> product decision -> engineering task, the important steps stay attached instead of becoming three disconnected summaries.

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

@nikitaeverywhere Great question! you own agent memory stays where it is. Vokal just provides ACP+MCP to integrate your local agents with the team.

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