Task chat

Every task has a chat. It’s where you talk to the agent, and where you talk to teammates about the work. The two conversations live in one timeline so the agent can read the whole context when you ask it to act, and so reviewers don’t have to context-switch between a chat tab and a comments tab.

The same chat box drives three different things depending on what you type.

The three things a chat post can do

1. A plain note. No mention, no slash command. The message goes into the timeline. Everyone on the project sees it. The agent does not react.

Anyone know why the staging env keeps OOMing?

This is what most chat messages are. Use them for design discussion, status updates, questions the agent can’t help with, anything where you don’t want the agent to start working.

2. An @agent dispatch. Mention @agent (the literal word) and the message goes to the task’s currently-assigned agent as a turn. The agent reads the whole conversation slice with author labels (so it sees who said what, including the message you just sent) and acts on it.

@agent the deploy_user table was renamed to users last week,
please update the integration test fixtures

@agent is “do work now.” Use it when you want the agent to start, continue, or change course on the task.

3. A slash command. Start with / and the parser routes the rest to the agent’s lifecycle (/start, /stop, /interrupt, /restart, /new-conversation) or to the agent’s own command parser (/skills, /agents, …).

/interrupt focus on the auth refactor first, the perf work can wait

Slash commands the agent itself understands are passed through verbatim; Vibetight’s parser only owns the lifecycle ones.

Picking an agent by name

If you start typing @ in the composer, you’ll get a popup of users and agents you can mention. Picking a teammate inserts a @user:<uuid> marker; they’re just tagged in the conversation, nothing else happens.

Picking an agent by name does the same dispatch as @agent, with two differences:

• It targets that specific agent, not whoever happens to be assigned. If a different agent is already on the task, picking one by name re-assigns the task to the one you picked.
• It checks whether you’re allowed to drive that agent (see “Who can drive agents” below). If you can, it dispatches immediately. If you can’t, the task is parked in Action required and routed to the agent’s owner. Your message is kept in the transcript, and the owner can approve or decline by replying themselves.

That last part is the team-friendly bit: you don’t have to find out who owns laptop2 and ask them on Slack. You just @laptop2 on the task, and the agent’s owner gets pinged inside Vibetight.

Who can drive agents

Each tenant has an agent authority policy under Settings → Teams:

• Only owners (default): only the human who paired the agent’s device can dispatch it. Safe default; nobody can accidentally rack up someone else’s Claude bill or drive their machine while it’s in the middle of a meeting.
• Everyone on this team: any tenant member can dispatch any agent shared with the project.

The policy applies to @agent, agent-by-name mentions, and slash commands that touch the agent (/start, /stop, /restart). Read-only chat (plain notes) is never gated this way. Anyone with project access can comment.

There’s also a runtime-level rule on top: agents whose device is configured for a personal Claude subscription seat can only be driven by that device’s owner, even if the tenant policy says “everyone.” That’s an Anthropic terms-of-service thing, not a Vibetight preference. API-key devices have no such restriction.

What the agent actually sees

When you @agent on a task with other people in the conversation, the agent receives the slice of chat from the last agent turn (or task start, if there hasn’t been one) up to your trigger message. Each message is labeled with the author so the agent can tell who’s saying what:

@vibetight (owner): the rename happened last week, fixtures need updating
@laptop1 (agent): I'll start by listing the fixtures that reference deploy_user
@vibetight (owner): @agent the deploy_user table was renamed to users last week,
  please update the integration test fixtures

This is what makes “the owner overrides the member” work. If a member writes one thing and the owner replies with the opposite, the agent reads both and follows the owner, because it can see the role labels.

When a task lands in “Action required”

A task moves to Action required when:

• An agent needs you to answer a permission prompt (the agent paused mid-turn).
• Someone mentioned an agent you can’t drive, and the agent’s owner needs to approve.
• The agent ran into a problem that requires human input.

The kanban shows action-required tasks in red so they don’t get buried. Reply in chat to clear it; the task transitions back to In progress automatically when the dispatch lands.

What’s not in v1

A few capabilities that are common in Slack-style chats but aren’t here yet:

• No threading. Replies are linear within a conversation.
• No read receipts.
• No “X is typing” presence.
• No mention notifications for @user:<uuid>. Tagging a teammate doesn’t ping them outside Vibetight; they see the mention next time they open the task. We expect this to land alongside email/push notifications.
• No cross-task chat rooms. Chat is per-task only. If you want a project-level conversation, use a task whose only job is to host that discussion.

These are deliberate omissions, not technical debt. Once enough teams use Vibetight day-to-day we’ll know which ones are worth adding.