Magic LibraryStart from the library, not a blank box
The Magic Library is full of jobs already written for this. Anything tagged Agent was written to run unattended and carries a Running as a Flow section telling the agent how to behave when nobody’s watching. Filter to the Agent entries, pick the one closest to your workflow, and adjust the board names, status names and tone to match your desk. That’s the whole job most of the time. Two other ways in:- Ask Super Magic to build it. Describe the outcome in plain language and ask it to create the flow and the agent together. Usually the fastest route — review what it produced before you enable it.
- Write it yourself. Fine, but read the three rules first.
Before you start
- Super Magic enabled for your workspace, and Super Magic Agents enabled on top of it
- A test board and a test ticket — don’t point a new agent at a live board on its first run
- The person creating the agent needs full write access
What an agent is made of
Build it
1
Set the trigger
Admin → Flows → New flow. The conditions decide which tickets the agent sees, and they’re
the biggest lever you have. Start narrow — one board, one status, or a single test client —
then widen once you trust the output.Two things to know:
- It fires once per ticket, permanently — not once per status change. See the once-per-ticket rule.
- It fires on the ticket as it is at that moment. If your agent needs a field another flow writes, ordering matters.
2
Add the agent and choose how it gets its instructions
Add an action, pick the Super Magic agent action, and choose between:
- A prompt written into the flow — best when only this flow needs it. There’s an Improve prompt button that tightens a draft.
- A shared skill (beta) — best when a technician also triggers the same job by hand from chat, so the instructions live in one place.
3
Approve the tools
Tick the write tools you’re comfortable with it using unattended. Read tools are always on and
never need approval.The two modes have opposite defaults, which is the single most common source of confusion:
So an agent that reads correctly but never changes anything is almost always an empty tool
list. And a skill-based action you want tightly scoped needs its tools ticked explicitly. Each
library entry lists the tools it needs in its header — tick those.
4
Test it
Leave the flow disabled, create a test ticket that matches, then enable it and watch.
Three places to look: the ticket itself, Super Magic → Flow Chats for the agent’s
reasoning, and Flows → Logs for whether it fired at all.
Who the agent runs as
Not a service account. Every run acts as a real member of your workspace:- A prompt-based agent runs as whoever last saved the flow.
- A skill-based agent runs as whoever created the skill.
Three rules that fix most failures
1. Load the ticket first. The agent starts knowing only which thread it’s on — not the body, not the client, not the contact. Every prompt that works starts by fetching it:Load the ticket. Call2. One tool call at a time. Agents fail most often when they try to do several things at once.search_ticketswith the currentinternal_ticket_idandinclude_messages=true. Read the result before doing anything else.
Make one tool call at a time. Read the full result before deciding the next call. Never batch or parallelise calls.3. Say what to do when it can’t finish. Without a stop condition, it guesses.
If you cannot confidently identify the company, add an internal note explaining what you checked, and stop. Do not assign anything.Two smaller ones: name the actual tool rather than the outcome (
assign_contact, not “move it
to the right company”), and if you want the client to see a message say is_internal=false
explicitly, because the agent defaults to internal notes.
Shorter prompts perform better. Cutting a long dispatch prompt from around 12,000 characters
to 3,000 makes it more consistent and far easier to troubleshoot. Aim under 3,000 — which is also
the saved-skill limit. If you’re over, don’t delete requirements: ask Super Magic to make it
shorter without changing what it does.
What doesn’t work in a flow yet
Documentation search does work. IT Glue and Hudu are built into the agent directly, so those searches are available in a flow exactly as they are in chat. Your documentation layer is not the gap. What isn’t available in a flow run: NinjaOne, ConnectWise Automate, ImmyBot, TimeZest, PSA Configurations, and anything reached over a connector — including Liongard, Notion and Linear. If a job works when you run it from chat but does nothing in a flow, this is almost always why. Check the entry’s Connectors line before you build: one that needs nothing, or needs only IT Glue and Hudu, works today. Anything else will still run, but the agent has no such tool to call — and rather than stopping it works with what it has and gives you a confident answer that is wrong, such as reporting a device can’t be found when it exists. Run those from Super Magic chat instead.A flow only runs once per ticket
De-duplication is on flow plus ticket, permanently. A QA agent that runs on Complete won’t run again when the technician fixes the ticket and sets Complete a second time. The workaround is two flows, which de-duplicate independently:- QA Agent 1 triggers on
Status = Completeon your main board. On failure it sets Re-open and moves the ticket to a QA board. - QA Agent 2 triggers on
Status = Completeon the QA board. On failure it sets Re-open and leaves it there.
Setting a company
There’s no company field the agent can set. Assign the right contact withassign_contact and the
ticket follows that contact onto their company — which means “company but no contact” isn’t
reachable. If the agent can’t find a contact, have it stop rather than half-route the ticket.
Destructive actions are blocked
Rebooting a device, running a maintenance session, executing a runbook — these are blocked in any unattended run. They need a person to confirm.Plan level
On a plan below AI Pro, Super Magic runs with a much smaller set of tools. If something is missing entirely, check your plan on Plans & Licenses.When it goes wrong
Flows → Logs answers did it fire? Filter Type to agent runs, and open a row for the condition tree showing what each rule expected against what actually arrived on the ticket. One catch: agent actions reportDispatched, not Success. The agent runs in the background,
so when the flow finishes the outcome isn’t known yet. Dispatched means the handoff worked,
nothing more.
Super Magic → Flow Chats answers what did it actually do? — every tool call, every result,
its reasoning at each step. This is where you troubleshoot the agent itself.
Raising a ticket
Raise it as a normal Thread support ticket, mention it’s a Super Magic Agent in a flow, and include:- The prompt, in full
- The flow conditions
- The ticket ID where it went wrong
- The link to the Flow Chat, which carries the whole tool-by-tool trace
Contribute back
Built something good? The library is crowdsourced. Fork Thread-Magic/super-magic-skills, add aSKILL.md, and open a pull request — once merged it goes live on this site. The bar: one real
workflow, guardrails inside the prompt, and no client or partner data.