Building a workflow

A job that runs the same way every time

A workflow is a job written down as steps, each done by an agent, that runs on a schedule, on an event, or when somebody in a team room asks. A brief is one request; a workflow is the same request every Monday, or every time a lead replies, with the result posted in the room.

Workflows live in two places:

• Workflows, at nagent.ai/admin/ai-team/workflows, lists every workflow in your workspace. The same list is the Workflows tab of the Agent Workbench. Open one and you are in its editor, where the steps, the triggers and the run panel are.
• A team room runs them. The prebuilt rooms arrive with their own set, and every room runs the workflows on its list from cards in its member list, with Run now, Test run, free model and a Keep running switch. That side is on workflows in a room.

The link between the two is the team: a workflow is put on a team, and from then on that team's room can start it and receives what it makes. This page is about the first place, building one.

1. Build one from a sentence

On the Workflows page, the New workflow box asks for one thing: "Describe the job in one sentence", with the example "Every Monday, research our competitors and email me a brief". Type it and press Build it. Creating or deleting a workflow needs permission to change AI teams, which a workspace admin holds; without it the page says Read-only.

The name comes from your sentence: the job without its "every Monday" lead-in, cut to eight words, and you can change it later. The editor opens with the conductor on the left, which reads the sentence before it asks anything:

• What the sentence settles is not asked. "Every Monday", "every weekday", "daily", "on demand", a time such as "9am", "email" or "Slack" as the destination, and a team named in the sentence are each read and said back: "From your sentence: ...". A schedule with no time in the sentence is drafted for 09:00.
• What it leaves open is asked, as a few multiple-choice questions with a recommended answer each. If the intake model is unavailable, the conductor asks the three core questions instead: how often, where the result goes, and what needs a person's approval.

Then it drafts. The rail shows "Drafting the plan, N s so far. A plan with parallel steps usually takes two to three minutes; it lands on the canvas by itself." When it lands, the conductor says how many steps it drafted and whether a schedule and a room start were set: "The schedule and the Sales room start are set and switch on when you publish", or "No schedule: you start this one yourself."

The canvas

The drafted steps appear on the canvas marked staged, with a count in the header. Review them in the Pipeline view (an ordered list of steps) or the Graph view (the branches and joins). Each step names the agent that does it; a step the conductor could not give an agent has to be bound to one, or discarded, before you can publish: Publish stays off and says "A drafted step has no agent. Bind or create one, or discard the step, before publishing".

If you started from a room (Build a new one for this team under the room's workflow cards), the editor already knows the team: the drafted plan reports to that room and is put on that team when you publish.

2. Publish

Publish opens a readback headed Publish and the workflow's name. It shows what the workflow will be able to reach once it is live ("after publishing, this workflow can", followed by each new reach, or "Publishing adds nothing to what this workflow can reach") and what changed in the graph. Press Publish again to confirm, or Cancel.

Publishing takes the drafted steps with it, and three things happen:

1. The triggers start. The schedule and the room start the conductor drafted sit paused with the reason "Starts when the workflow is published" until now. Publish resumes them. A trigger you paused or resumed yourself is left as you set it.
2. The workflow goes on its team. If the drafted room start reports to a room you are on, and you hold the permission to set up that room, the workflow is added to the room's list. The editor says so: "Published. 2 triggers are live. Sales can run it." Without the permission or the membership, the triggers still start and the editor says why the room was not set up.
3. A new trigger lists at once on the Triggers panel below the canvas.

Nothing runs until you publish, and the Run and Test run, free model buttons stay off until then ("Publish first").

Triggers: what starts a workflow

The panel headed Triggers · what can start this on the workflow's page holds every way it starts. Each trigger has a label, a limit per hour (10 unless you change it; 0 drops every fire) and Report to, the room the run posts its result into. Choose Nowhere and the workflow does the work and tells nobody.

Schedules and events are checked about every five minutes, so a run can start a few minutes after its time, and never runs twice for the same time. Each schedule, event or webhook on the panel has its own Keep running switch, the same switch as the room's card; one that is off says "switched off, so the evaluator skips it. Turn it on with the switch on this row". Only a published workflow's schedule can be switched on. The room's card and a sentence in the room switch the same schedule; see workflows in a room.

A team thread trigger does not by itself give any team the right to start the workflow: an administrator still adds the workflow to the team, in the room's member list.

Test runs on a free model

Test run, free model sits in the run panel on the workflow's page, and on the room's cards. It runs every step on a free model, so you can check the steps, the card in the room and the result reaching the room at no cost. Two limits keep it free:

• Single-agent steps only. A workflow with a manager, action, sub-workflow or pipeline step refuses a test run, because those would spend outside the pinned model. Every prebuilt team workflow qualifies.
• Reads only. A test run may read your Knowledge Hub, brand voice, leads, memory and visibility findings. Web search, research, enrichment and connected apps are left out, because a free model is not a free run when it searches the web. A real run keeps every tool.

What a run costs and what needs approval

A start from a room goes through the same door as every agent action: the allowlist, the rate limit and the approval gate. If a start is held, the room's card says "Waiting for approval before it starts." Approving a start approves everything downstream of it, which is why the readback at publish time shows what the workflow can reach.

Inside a run, a step whose action needs a person shows needs approval on the room's live card. On the workflow's page the run panel counts them ("2 actions waiting on you") with Approve + resume and Dismiss + resume.

Each run has a spending ceiling. The run panel's cost meter shows what the run has spent against its cap, or no cap with "This run has no ceiling. Click to set one." The prebuilt team workflows are capped at 3 USD per run. Stop on the panel stops further steps from being scheduled; work already in flight finishes and is still billed. The Blast radius panel on the same page says what the workflow can reach, which third parties are in reach, who runs it and what it bills against.

Our logic: a workflow keeps acting after you have stopped looking at it. So nothing runs until it is published, every installed schedule starts switched off, a test run cannot spend, and a start from a room is gated like any other action.

Where to go next

• Workflows in a room: running, testing and scheduling a workflow from the room.
• Triggers and webhooks: signed webhooks and the events your pipeline raises.
• Approvals and the Inbox: where a held start waits.
• Agent Workbench: the Workflows list and the agents a step is bound to.