Know when Workflows beat a long Chat thread
Contrast **Chat** with **Workflows** once: same shape of work, repeat gates, humans in the middle, and starters from outside Auxot belong on a board, not in a single endless thread.
Plus: three Admin Agent prompts that sort real work into **Chat**, **Workflows**, or **Run an agent on a schedule** before you drag steps or paste another giant prompt.
| Audience | Everyone · Admins |
|---|---|
| Time | ~5 min |
| Prerequisites | You can open **Chat** and **Workflows** from the left menu ([Find the right screen for your next question](/tutorials/find-the-right-screen-for-your-next-question)). Helpful: you already picked a day-two focus ([Choose your day-two track in Auxot](/tutorials/choose-your-day-two-track-in-auxot)) or finished a first-hour pass ([Make your first hour in Auxot count](/tutorials/make-your-first-hour-in-auxot-count)). |
| You'll end up with | A two-sentence rule you can repeat to teammates, a short list of signals that belong on a workflow board, and three Admin Agent prompts that reclassify messy real tasks without building anything yet. |
When a tutorial shows italic text in quotation marks, it usually mirrors a label or helper string inside Auxot. Product copy changes between releases — if something reads differently in your workspace, trust what you see on screen.
Callouts with a Worth knowing gold accent are meant as must-read context before you move on. Blockquotes that open with Tip are lighter, optional depth.
Why this matters
Chat is brilliant when the goal is still fuzzy: you iterate in language, you change your mind, you want the Admin Agent to riff with you. Workflows are brilliant when the goal is the same shape every time and the risk is people skip a step or nobody knows whose turn it is.
If you force repeat work to live only in Chat, you get long threads (forty messages deep) that are hard to audit and easy to lose when someone is out sick. If you force exploratory work into Workflows too early, you burn time naming steps nobody understands yet.
Today, you write one plain rule for when the board wins. The next time a teammate asks should we automate this, you have a clear answer instead of a hunch.
Workflows still need something to start each task (New task, a webhook, or another pattern you wire deliberately). This lesson does not build that wiring. It only names when the board is the right home.
Quick start
- Open Workflows: click Workflows in the left menu. Read the empty state or skim an existing board without editing anything yet.
- Open Chat in a second tab: pick any agent you already use. Notice how history reads top to bottom as one conversation, without a column or owner per stage.
- Write two examples in your notes: one task that should stay in Chat because the goal is still moving, and one task that should become a Workflow because the same gates repeat with different customers or tickets.
- Paste prompt 1 below into Chat → Admin Agent and keep the reply next to your two examples.
- Bookmark the build tutorial: open Run a workflow in a new tab, read only the Why this matters section, then close the tab until you are ready to build.
Done? You can finish this sentence aloud: We keep this in Chat until ____; we move it to Workflows once ____.
The agent can do that?
You already wrote two examples. These prompts ask the Admin Agent to sort messy reality without pretending a board exists yet. Paste into Chat → Admin Agent.
1. Sort three real tasks into Chat, Workflow, or schedule
Here are three real tasks we do in my org (one sentence each): [paste]. For each, answer only one label: Chat, Workflow, or Scheduled single-agent job. One-line justification each. If you need more detail to decide, ask one clarifying question per task, not six.
Why it’s non-obvious: Teams default to everything in Chat because it is always open. A forced triage surfaces where repeatability already exists.
2. Stress-test your two-sentence rule
Our draft rule is: [paste your Chat versus Workflow sentence]. Give three counterexamples where the rule would misfire and how to tighten the wording without turning it into a policy manual.
Why it’s non-obvious: Simple rules survive adoption. The leverage is tightening the edge cases you would actually hit this quarter, not inventing imaginary departments.
3. List what an admin must wire before a workflow is honest
Assume we agreed a workflow is correct for [task]. List the minimum admin-side wiring checklist (steps, agents, human reviewers, API keys, webhooks) in order. Mark each item I can do as a normal user versus needs org admin. Keep to eight bullets.
Why it’s non-obvious: Members stop mid-build when they discover missing agents or keys. Naming the dependency list early prevents half-built boards that embarrass the project.
Go deeper
When intake webhooks are the missing starter
If the repeating work arrives from another system (form, queue, CI), the board often still wins, but the starter is usually a webhook or integration path, not a human clicking New task each time. Read Trigger a workflow with an intake webhook when that is the shape of the work.
When a scheduled agent is enough
If one agent with one prompt on a clock covers the job without a stage-by-stage owner, compare Run an agent on a schedule before you take on the extra setup a workflow requires. Workflows are the right home when multiple roles or agents touch the same item in order.
When handoffs are the real product
If the pain is agent A did work agent B cannot find, you are closer to Chain steps so agents hand off cleanly than to more prompts in one thread. Workflows make those handoffs visible as columns.
Walkthrough
Step 1: Treat each column as a named owner
Open Workflows. If a board exists, treat the column titles as the names of who owns each stage of the work. If nothing exists yet, imagine three columns you wish you had last week when a task stalled.
Step 2: Read Chat as a thinking room
Switch to Chat. Scroll a thread you already have. Notice where you asked clarifying questions that would not fit a single workflow card without rewriting history.
Step 3: Write the rule in one breath
Finish this template in your notes: Chat until the question is answered; Workflow once the same three things happen every time for different inputs.
Step 4: Run the triage prompt
Paste The agent can do that? → 1 with three honest tasks from your week. Save the answer where your team looks for norms (wiki, Notion, pinned Slack).
Step 5: Decide who builds the first board
If the triage says Workflow and you are not an admin, send The agent can do that? → 3 output to whoever owns Settings → Agents and keys. If you are the admin, open Run a workflow when you have forty-five quiet minutes.
What’s next
- → Run a workflow. When you are ready to name steps, agents, and human gates on a real board.
- → Chain steps so agents hand off cleanly. When the pain is invisible handoffs between agents more than missing UI.
- → Trigger a workflow with an intake webhook. When the work arrives from another system on a wire.
- → Run an agent on a schedule. When one prompt on a clock is enough without columns.
- → Require human approval before risky actions. When approvals need policy text, timeouts, and reviewer packets beyond a single column.
- → Understand Credentials, OAuth, and API keys in Auxot. Once boards and cron are in the picture, Settings → API Keys versus Credentials versus OAuth stops being guesswork.
Reference
- Primary pages: Workflows, Chat, Audit Logs (for receipts after boards run)
- Starters mentioned elsewhere: New task button, intake webhooks, scheduled agents (see linked tutorials)
- See also: Choose your day-two track in Auxot, Know what the Escalations bell is for, Understand Credentials, OAuth, and API keys in Auxot, Create an agent from scratch