What should agent-native collaboration look like?
Greg Isenberg (https://x.com/gregisenberg/status/2062330678490882434?s=20) 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.
Replies
How do approvals scale as teams grow?
Vokal
@ethan_gabriel Approvals scale by ownership. Each human should be the manager of their own agents: they configure the agent’s permissions, tool/app access, channel scope, and escalation rules. Routine work stays inside that scope; anything risky or unclear routes back to the agent owner or the relevant work owner. That avoids one giant approval queue as the team grows.
There is also agent memory and institutional knowledge base that keep agents sane and smarter every day.
What replaces status updates in this workflow?
Vokal
@skylar_henderson 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.
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?
Vokal
@riya_pariyar 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:
@zhen_han 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.
What becomes the new inbox in this model?
Vokal
Great question! The new inbox is a personalized summary over the audit trail. Vokal keeps the raw record of agent runs, handoffs, tool calls, decisions, and approvals, but humans should not have to read that stream all day. Your personal agents should turn it into: what changed, what they handled, what needs your decision, and what is waiting on you. So the inbox becomes “what matters to me now,” with the source trail attached.
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.
Vokal
@siddharth9903 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.
@zhen_han Oh that's great
How do agents know when to ask for help?
Vokal
@clara_isabelle I don’t think “ask for help” can rely on personality or better prompting alone. It needs explicit boundaries. The agent should escalate when it lacks required context, sees conflicting instructions, hits a permission/tool boundary, fails verification, or reaches a judgment call outside its role. In Vokal, those boundaries come from the agent’s role/profile, owner, permissions, connected-app access, and channel context, so the help request can route to the right human with the actual blocker attached.