blog.vims
← All articles

Flow and Teams: Automate and Collaborate

Part 12 of the [VIMS Blog Network](00-vims-convergence-point). VIMS combines visual workflow automation with P2P team collaboration in one integrated surface.

Part 12 of the VIMS Blog Network. VIMS combines visual workflow automation with P2P team collaboration in one integrated surface.

Two Problems

There are two things every organization needs: automation and collaboration. Automation handles repetitive, rule-based work: when a webhook arrives, do this; every morning at 9am, summarize that. Collaboration handles messy, human-centered work: discuss, decide, share, review.

Most platforms solve one or the other. Zapier automates. Slack collaborates. The integration between them is brittle: webhooks fire into channels, humans copy data between systems, and the automation does not know what the collaboration surface is doing.

VIMS solves both in one system. The Flow Engine automates. Teams collaborate. And because they are part of the same operating system, flows trigger from team events and teams consume flow outputs, with no integration layer.

The Flow Engine

The Flow Engine is a general-purpose automation runtime. It executes directed acyclic graphs (DAGs): workflows composed of nodes connected by edges, where each node performs an action and each edge defines what happens next.

Node Types

VIMS flows have 17 node types:

  • Trigger: starts the flow (cron, webhook, event, manual, channel message, database change)
  • Action: performs a generic action
  • Condition: evaluates a condition and branches
  • Transform: transforms data between nodes
  • Delay: waits for a specified duration
  • Webhook: sends an outbound webhook
  • Agent: dispatches a task to an agent instance
  • Skill: executes a VIMS skill
  • LLM: calls the configured LLM provider for reasoning
  • Channel: sends a message to a channel (Slack, Discord, email, SMS, Telegram)
  • HTTP: makes an HTTP request
  • Code: executes custom code
  • Swarm: fans out a task across multiple agents
  • Workflow: calls another flow as a sub-workflow
  • MCP: invokes an MCP tool
  • DB: queries a connected database
  • Drive: reads from or writes to the VIMS Drive

Each node type has its own execution logic, input/output schema, and error handling. An LLM node streams the response; an HTTP node handles redirects and retries; a DB node manages connection pooling; a Swarm node aggregates multiple agent responses.

Edges and Branching

Edges connect nodes and define control flow. Every edge has a kind:

  • Success: the edge is followed when the source node succeeds
  • Error: the edge is followed when the source node fails
  • Always: the edge is followed regardless of success or failure

This enables error handling, retry paths, and conditional branching, all within the DAG structure. A flow that calls an API can have a success edge leading to the next step, an error edge leading to a notification node, and an always edge leading to a logging node.

Execution Model

The flow engine executes DAGs using topological sorting with parallel wave partitioning. Nodes that have no dependencies on each other execute in parallel; nodes that depend on previous nodes wait. This means a flow with three independent HTTP calls runs them concurrently, not sequentially.

Each node has configurable retry policies: number of retries, backoff strategy, timeout. A flaky API call can be retried three times with exponential backoff before the error edge is followed. The retry policy is per-node, not per-flow, so different nodes can have different resilience strategies.

Triggers

Flows are triggered by:

  • Cron: on a schedule (e.g., every day at 9am, every Monday at 5pm)
  • Webhook: when an inbound HTTP request arrives at the flow's webhook URL
  • Event: when a system event occurs (agent started, agent stopped, file uploaded)
  • Manual: when a human presses the run button
  • Channel message: when a message arrives in a connected channel
  • Database change: when a monitored database table is modified

Triggers carry a payload: the data that starts the flow. A webhook trigger carries the request body; a cron trigger carries the timestamp; a channel message trigger carries the message text and metadata.

The Visual Workflow Builder

Flows can also be built visually. VIMS includes a visual workflow builder: a drag-and-drop canvas where you design flows by placing nodes and drawing connections. The builder provides:

  • A palette of node types, organized by category
  • A canvas where nodes are placed and positioned
  • Port-based connections: each node has input and output ports; you draw edges between ports
  • Inline configuration: click a node to configure its parameters
  • Live validation: the builder checks for cycles, missing connections, and invalid configurations

The visual builder produces the same flow definitions that code-based flow creation uses. You can start a flow in the visual builder, export it, and version-control it alongside your code. You can also create flows programmatically and import them into the visual builder for editing.

Flow Works Independently of Teams

This is important: the Flow Engine is a standalone automation runtime. You do not need a team to use flows.

A flow can be triggered by a cron schedule and execute a chain of HTTP calls, LLM reasoning, MCP tool invocations, and database queries, all without any team context. Use cases:

  • Stripe webhook → database insert: when a payment arrives, record it in your database and send a notification
  • Daily KB summarization: every morning, use an LLM to summarize new knowledge base documents and post the summary to a channel
  • Research swarm: manually trigger a swarm of agents to research a topic, with results aggregated and posted to a knowledge base
  • Database change → MCP tool: when a row is added to a table, invoke an MCP tool to process it
  • API orchestration: chain multiple HTTP calls with condition-based branching and error handling

The flow engine is a general-purpose automation tool. Teams are one consumer of flows, not the only one.

Teams

Teams are the P2P collaboration primitive. A Team is an append-only log of roster and surface mutations, replicated over Hyperswarm. It composes the lower P2P primitives (Drive, Meeting, KB, Database) plus Flow into one identity-rooted unit.

Roster and Roles

A team has a roster: the list of members. Each member has:

  • A Nostr npub: their cryptographic identity (Blog 08: Agent Identity)
  • A role: one of: owner, coowner, member, agent
  • Permissions: 26 fine-grained permissions controlling what they can do

The four roles form a hierarchy:

  • Owner: full control: manage members, delete the team, transfer ownership
  • Coowner: near-full control: manage members, manage surfaces, cannot delete or transfer
  • Member: participate: chat, view boards, access shared resources
  • Agent: limited: execute tasks, post messages, interact with surfaces as directed

Per-member permission overrides allow fine-grained control. A member might have read access to the database but not write access. An agent might be able to create kanban cards but not delete them. Overrides are per-member, not per-role; two members can have different permissions within the same role.

Surface Attachments

A team attaches P2P surfaces: shared resources that all members can access:

  • Drive: shared file storage, replicated over Hyperdrive
  • Meeting: shared meeting room for voice/video collaboration
  • Schedule: shared calendar for booking and availability
  • Database: shared database mirror, synced over P2P (Blog 04: Data and Knowledge)
  • KB: shared knowledge base, with vector index replication
  • Flow: shared flow definitions and run history
  • Reach: shared channel connectivity (Slack, Discord, email, SMS, Telegram)

When a team is created, deterministic sub-keys are derived from the vault for each surface. Every peer that joins the team arrives with the same component keys, with no manual key exchange, no shared passwords, no configuration files. The cryptographic derivation ensures that only team members can access team surfaces. (Blog 06: P2P Surfaces)

Chat and Kanban

Team rooms include two collaborative surfaces that are native to the team (not attached as separate P2P primitives):

Chat: persistent messaging with message history. Messages are stored locally (localStorage in the browser, on-disk on desktop) and synced to a backend for persistence. The chat supports text messages, agent-directed messages (mention an agent and it responds), and command messages (e.g., /summarize to get an AI summary of the conversation).

Kanban: a shared kanban board with card CRUD. Create cards, move them between columns, assign them to members, add labels and descriptions. The board syncs over P2P; every member sees the same state in real-time. Agents can create cards, update them, and move them as part of flow execution.

Federated Inference

Team members can query each other's local models. If you have a powerful GPU running a 70B model and your teammate has a laptop running a 7B model, your teammate can send inference requests to your model over the P2P swarm. This is federated inference: local models serving remote peers.

Two modes:

  • Directed query: send a prompt to a specific peer's model and get the response
  • Broadcast: send a prompt to all online peers and aggregate responses

Federated inference is the bridge between local-first and collaborative. You get the privacy and cost benefits of local inference, plus the diversity and capacity of multiple models across the team. (Blog 01: Local-First AI)

Agent Integration

Agents are first-class team members. An agent invited into a team room can:

  • Receive directed messages: mention the agent in chat and it responds
  • Execute room actions: create kanban cards, upload files to the drive, query the shared database
  • Join meetings: the agent joins as a synthetic peer with voice capabilities (Blog 07: Voice and Meeting Agents)
  • Be triggered by flows: a flow's agent node can dispatch a task to a team agent

Agent actions in a team room are governed by the same security model as everywhere else: HITL gates, per-agent policies, audit trails. An agent in a team room is a governed participant.

Membership Management

Team membership is managed through the append-only mutation log:

  • Add member: owner or coowner invites a peer by npub
  • Remove member: owner or coowner removes a peer
  • Kick/ban: owner can kick a member and ban them from rejoining
  • Ownership transfer: owner can transfer ownership to another member
  • Role changes: owner can promote/demote members

Every membership change is a mutation appended to the log. The log is the source of truth: every peer projects the current state from the log. If two peers disagree about the roster, they compare logs and reconcile.

When Flows and Teams Combine

The power of having both in one system becomes apparent when they interact:

Flows Triggered by Team Events

  • A channel message trigger fires when a message arrives in the team's chat: the flow can process the message, run an LLM summarization, and post the summary back
  • A database change trigger fires when a row is modified in the team's shared database: the flow can notify the team, update a kanban card, or dispatch an agent to investigate

Flow Nodes Mapping to Team Surfaces

  • Agent nodes dispatch tasks to team agents: the agent receives the task, executes it within the team context, and returns the result
  • Channel nodes send messages to the team's chat: the flow can post updates, alerts, or summaries
  • DB nodes query the team's shared database: the flow can read team data, aggregate it, and produce reports
  • Drive nodes read from or write to the team's shared drive: the flow can process files, generate documents, and share them with the team
  • Swarm nodes fan out across the team roster: the flow can dispatch tasks to multiple team agents in parallel

Marketplace Agents in Team Flows

An agent purchased from the marketplace can be invited into a team room and triggered by flows. This means you can compose a team with a mix of custom agents and marketplace agents, each triggered by different flows based on their specializations. (Blog 10: Agent Marketplace)

The Integration Contract

Flow and Teams in VIMS are two subsystems of one operating system, sharing:

  • The same identity layer: Nostr npubs for members, NFTs for agents
  • The same security model: HITL gates, per-agent policies, audit trails
  • The same P2P substrate: Hyperswarm for team replication, Hypercore for mutation logs
  • The same data stack: shared database, KB, drive accessible to both flows and team members
  • The same SDK: both surfaces are available as hooks and APIs to SDK apps (Blog 12: SDK, Coder, and Terminal)

This is what makes the integration seamless. There is no webhook from the flow engine to the team surface. There is no API gateway between them. They are part of the same process, sharing the same memory, calling the same functions. The flow engine can query the team roster directly; the team surface can trigger a flow directly. The integration is architectural, not configurational.

Previous: The Agent Marketplace Next: Build Anything: SDK, Coder, Terminal