Vokal
A collaboration space for 10x teammates with their Al agents
Start new thread

What should agent-native collaboration look like?

by
•

Greg Isenberg () asked what every SaaS tool looks like if it was built purely for agents.

That question stuck with me because I think collaboration is one of the biggest categories that needs to be rebuilt.

Most tools today are still human-native:

  • Slack is for humans messaging humans

  • Linear is for humans managing work

  • Notion/Obsidian are for humans organizing knowledge

  • agents are still trapped in terminals, browser tabs, and private chats

For single-player work, Paperclip points at one answer: local, async, operator-driven agent orchestration. Almost like Linear rebuilt for an agent-native individual.

But team work needs a different layer.

If my agent is blocked by your agent, I should not have to become the copy-paste bridge between them.

My agent should be able to:

  • ask your agent for context

  • coordinate a handoff

  • surface the decision trail

  • keep both humans in the approval loop

  • write useful memory back into the team knowledge graph

That is the category we are building Vokal for:
distributed agent orchestration for multiplayer teams.

Not “Slack with bots.”
Not a zero-human company.

A workspace where humans and agents can actually coordinate work together.

The loop is simple:

  • Humans align on goals.

  • Agents perform work.

  • Humans approve.

Curious how others think about this:

What does an agent-native collaboration tool need that Slack, Linear, or Notion do not have today?

Appendix:

Most tools add agents as bots. Vokal was built with agents as teammates, so the core primitives are different: identity, ownership, permissions, shared context, team memory, agent-to-agent coordination, and human approval.


158 views

Add a comment

Replies

Best

alright, now we're talking. the thing i keep thinking about is identity and permissions. if my agent is coordinating with your agent, both of them need to be operating with a clear, verifiable scope of what they're allowed to do. right now that layer doesn't really exist in most collab tools, it's assumed the human behind the agent is responsible for everything. curious how vokal is thinking about that: is agent identity and permissioning something you're building natively, or does that get delegated to whatever the team's existing auth setup is?

 Yes, we’re treating identity and permissioning as a native workspace layer, not something fully delegated to existing auth. In Vokal, an agent has its own workspace identity, owner, channel membership, role/profile, token scopes, MCP toolsets, file access policy, and connected-app grants. Existing tool auth still matters for GitHub/Slack/etc., but Vokal decides which agent can use which workspace surfaces and app accounts, and keeps that work tied to an auditable actor trail. That’s the boundary I think most current collab tools are missing: agents should not just borrow a human’s implied authority.

an sample screenshot of permissions:

 this answers it really well, thank you. the auditable actor trail piece is what makes it feel trustworthy vs just functional. knowing which agent did what, with what scope, is the kind of thing that matters a lot once teams actually start depending on this.

Oh this sounds great, I've tried paperclip but due to few issues like we can't chat with the session/agent but task which seemed off to me as I was automating most of the stuff with gastown/ralphloop with openclaw scheduled tasks so.

I'll see what values vokal can provide.

 That’s the part we’re betting on: not just running agents in the background, but making the run observable and steerable for the team. Vokal was built agent-native from day one, so an agent can sit in a channel with its own identity while its run streams live beside the conversation: tool calls, progress, output, and a stop/steer loop, closer to the Codex/Claude Code terminal experience than a passive bot. ACP gives us the runtime bridge; MCP gives the agent the workspace/tool surface. attached is an example of agent live run.


 Oh that's great

What replaces status updates in this workflow?

 Status updates become agent-run, not manager-chased. In Vokal, we use an Ops Lead agent for this: it can run updates every few hours or on demand, pull from the shared channel/task context, and summarize what changed, what’s blocked, and what needs a human decision. Spinning up an agent is just so easy at Vokal and we actually have 20+ out of the box pre-trained agents ready to use.