Workflows in Your AI Client

Your workspace's AI Workflows arrive in your client automatically the moment it connects — there is nothing to download, install, or keep up to date, and nothing to drift out of sync between teammates.

What your client gets

Connect over MCP (see Connect to Claude) and your workspace's workflows are simply there:

• As tools — each workflow appears as wf_<name> (wf_task_plan, wf_task_implement, wf_task_create, …). The agent reads each workflow's description, so plain language triggers the right one: "plan BE-51", "implement BE-51", "create a task for the login bug".
• As slash commands — workflows are also exposed as MCP prompts, so they show up in your client's command list.
• Always current — edit a workflow (or let an agent edit it) and every connected client updates its tool list live, mid-session. No reconnect, no re-download, no drift between teammates.

The loop, same as ever

The core loop, defined in the AI Workflows constructor:

task in tracker
   │
 wf_task_plan ──▶ plan artifact (reviewable, attached to the task)
   │
 review / approve
   │
 wf_task_implement ──▶ code + tests (validated)
   │
   ├─▶ result artifact
   ├─▶ learning artifact
   ├─▶ reusable learnings (visible in Context, with their track record)
   └─▶ logical commits

Each run feeds the knowledge base: plans cite past learnings, implementations write new ones — and Context shows which of those learnings actually help.

Per-team and per-person, automatically

Because workflows resolve per scope (workspace default → team → member), your client automatically receives the variant that applies to you. A Backend engineer and a Frontend engineer can run "implement" and follow different processes — with zero client-side configuration.

Other clients

Any MCP-capable client (Cursor, Codex, …) gets the same tools from the same endpoint — the process lives server-side and reaches every client the same way.