Workflows, actions & skills

Chatting with the build agent covers one-off work. For everything else, a build room's rail gives you four ways to make the agent more capable and more autonomous: Workflows for recurring automations, Actions for custom tools, Skills and Knowledge for reusable instructions and reference material, and Assets for what the agent produces along the way.

Workflows

Workflows, in the room rail under Workflows, are recurring or triggered automations the agent runs. Instead of typing the same request every Monday, you define it once and let it fire on its own.

A workflow has a trigger and a target.

Triggers:

• Manual — it runs when you tell it to.
• On a schedule — either every N minutes (30 is the floor) or at a given hour UTC, optionally on one weekday. Each trigger stamps its last run before the work starts, so a slow pass cannot double-fire.
• When a pull request opens — it runs against that pull request.

Targets — what the workflow is pointed at:

• A pull request. A pull-request workflow also acts as a gate: while one exists in the room, the agent's own pull requests open as drafts and the workflow decides when they are ready.
• An integration. Pick which connected integration it runs against.
• A prompt. Describe in words what it should run against.

Each workflow runs a chain of skills, and an action policy that says whether finding a problem means fixing it or documenting it.

Activating a workflow is the validation gate. A workflow stays a draft until it passes, and activation tells you precisely what is missing — that it needs a name, that it needs at least one skill, that a skill in the chain no longer exists or has been switched off, that its target integration is missing, that its schedule has neither an interval nor an hour, that a pull-request trigger needs a pull-request target, or that you have not said what "fix" means for it. You cannot run a draft: activate it first, because activation is what checks it is complete.

A workflow run is still an agent run: it appears with live steps, counts against the token allowance in managed mode, respects the room's autonomy rules, and — if it changes code — delivers a pull request like any other run.

Workflows are where autonomy settings earn their keep. A workflow that only reads and reports is safe on a permissive mode; a workflow that posts to external systems needs auto mode for those actions to run at all, so decide deliberately whether that is what you want unattended. See Agent integrations for the autonomy ladder.

Turning a chat message into a task

Someone says something in a channel that ought to be a task. Rather than retyping it, you can point a workflow at that one message and have it draft the task for you.

Rolling out. This is behind a server setting that is off until an operator turns it on. When it is off, the channel header shows a Message workflows off pill and nothing on a message will start one.

What it produces is a proposal, and the distinction is the whole feature. A proposal is a draft: a title, a description, a priority and a checklist. It is not a card. Nothing reaches a board until a person opens the draft, reads the exact words, and presses Publish task. The agent is not even given the means to create one — the card-creation tools are never built for that run, and a board the model names is discarded, because the only destination that exists is the one you configured.

Give the workflow somewhere to put it

In the AI agent room, under Workflows, each workflow has a From a chat message section. Press Set destination, pick a Board and optionally a Column — the default is the board's backlog — and save.

Until you do, the workflow is simply not offered on messages: "Not offered on messages yet. Choose a board to turn one selected message into a reviewed task." The workflow also has to be activated, since a draft is never offered.

Run it, then review it

1. In a Chat room, hover a message and press the workflow button. Its menu is headed "Prepare a task from this message. A person reviews it before anything is created."
2. Pick a workflow. A drawer opens and the status moves from Waiting to start through Preparing a task draft to Waiting for review. You can close it — preparation carries on without you.
3. Reopen it and read the draft as shown, next to an excerpt of the message it came from.
4. Press Publish task, and the drawer confirms with the new task's reference and a link to it. Or press Discard, which is recorded as a decision in its own right.

Selecting the same message with the same workflow twice does not run it twice. You get the same request back, marked "Already requested. This is that same request."

The three careful bits

Approval applies to the words in front of you. Publishing sends the draft's exact revision and a hash of its content. If somebody edited it after you opened it, you are told and shown the new version instead of publishing the old one.

An edited source message is terminal. If the chat message the draft came from is edited or deleted, the draft can no longer be published at all, and the product says plainly that preparing a fresh draft from an edited message is a feature that does not exist yet.

An unknown outcome is not retried. If the connection drops mid-publish, you are not offered a Publish button again, because pressing it would be a guess about whether the first one landed. You get Check what happened instead.

Who may do it

You need to be able to read the conversation and to write to the AI room that owns the workflow. The workflow's owner must also still have access to both, and to the destination board — the checks are re-run at publish time, not cached from when you started.

Source and destination must be in the same organization, and in the same workspace with the same visibility. A restricted conversation cannot produce a task on a board more people can read.

Rate limits keep it sane: one preparation in flight per workflow, five per organization, twenty per person per hour. A message longer than 8,000 characters is refused rather than truncated.

Actions: custom HTTP tools

Actions, under Actions in the room rail, let you define your own tools when no built-in connector fits. An action is an HTTP call — a method, a URL, and parameters — and once defined it becomes a tool the agent can call like any other, filling in the parameters from the task at hand.

This is the lightest way to hook the agent up to an internal API, a deployment endpoint, or any service with an HTTP surface, without waiting for a first-class integration.

Two things an action needs, and they are the two the model actually reads:

• A name. The model calls the action by it. Anything that is not a letter, a digit or an underscore becomes an underscore, and it is capped at 60 characters.
• A description of when to use it. This is what the agent decides on, so write it as an instruction rather than a label.

An action takes up to 20 parameters, each a string, a number or a boolean. A few actions are backed by a known connector rather than a raw URL — Slack, Linear, Jira, Sentry, PagerDuty, or a generic webhook — which saves writing the request by hand.

Test each action after defining it. The panel calls it for real and records whether it succeeded, so a wrong URL or a missing header surfaces immediately rather than mid-run. The last result stays on the action.

The read/write classification is mechanical:

• GET and HEAD count as reads.
• Any other method is treated as an external mutation — and external mutations only run in auto mode.

The method you choose is a safety declaration. A POST action will never fire outside auto mode, no matter how harmless the endpoint is — and conversely, don't wrap a mutating endpoint in a GET to slip past the gate. The classification exists so that a run in a cautious mode cannot change the outside world.

Design actions the way you'd design tools for a colleague: a clear name, parameters that map to things the agent will actually know (an order id, a search term), and one action per operation rather than a single catch-all endpoint.

Skills and Knowledge

Skills and Knowledge both shape what the agent knows, from opposite directions:

• Skills are reusable instructions the agent loads — how your team writes migrations, what a good pull request description looks like here, the steps for a release. Write a skill once and the agent applies it across runs, instead of repeating the guidance in every chat. A skill has a name, a short "when to use it", and a body, which is the playbook itself.
• Knowledge is reference material the agent loads — the documents, conventions and background it should consult while working.

Seven skill templates ship with the product, as starting points: Brand review, Asset generation, Accessibility check, Writing user stories, Sprint planning, Pull requests worth reviewing, and Bug triage. A template is copied when you add it, not referenced, so editing one makes it yours and leaves the template alone.

Knowledge comes in three shapes: text you paste, a question and answer pair, and an uploaded file. Files must be readable as text — markdown, plain text, JSON, YAML, CSV, and source files. A PDF or a Word document is refused with a message telling you to paste the content instead, because extraction for those formats is not built. Retrain re-reads your text and question-and-answer sources and tells you how many it re-indexed and how many it skipped.

The distinction is practical: put how to act in Skills and what is true in Knowledge. An instruction like "always add a changelog entry" is a skill; the architecture overview it needs to do that well is knowledge.

Both live in the room rail, so each build room carries the instructions and material relevant to what it builds.

Assets

Assets, also in the room rail, collects files the agent produced — output that isn't code and therefore doesn't belong in a pull request. When a run generates a document or an image, it lands here so it isn't lost in chat scrollback. The panel keeps the 100 most recent.

Runs that come from a kanban card also attach their research documents and screenshots to the story itself (up to 10 files), keeping the evidence next to the specification. See The build agent.

Putting it together

These pieces compound. A typical mature build room might have:

1. Knowledge describing the system's architecture and domain vocabulary.
2. Skills encoding the team's engineering conventions.
3. Actions exposing the internal admin API as tools.
4. A scheduled Workflow that triages new helpdesk tickets each morning, cross-references them against the codebase, and drafts fixes as pull requests.

Each layer was set up once; every run after that benefits. Start with a skill or two — they're the cheapest to write and the fastest to pay off — and add actions and workflows as repeated patterns emerge in how you use the agent.

A scheduled workflow spends real money without anyone watching. In self hosted mode the bill arrives from your own provider and nothing caps it; in managed mode it draws on the organization owner's token allowance and will eventually be refused for being over it — at four in the morning, when nobody is reading. Set a token budget per run on the room before you enable anything scheduled: that budget is what bounds a workflow nobody is watching. See AI usage & the token allowance and AI configuration.