Skip to main content
A long prompt that tries to do everything gets less consistent and harder to troubleshoot. Chaining skills fixes that. You save each job as its own skill, then write one orchestrator skill that runs the others by name, in order. A Flow runs the orchestrator with Agent Builder, so each skill stays short, does one thing, and can be fixed on its own.

​
How a chain works

  • One job per skill. Each skill does a single thing, such as set the category or check for duplicates, and reports its result back to the orchestrator.
  • The orchestrator runs them by name. It lists the skills in the order they should run, says when to skip one, and says what to do when a skill fails or can’t decide. Names must match the saved skills exactly.
  • A Flow starts it. Add the Agent Builder action to a Flow, choose Run a Skill and select the orchestrator. The orchestrator must be shared, because a Flow only runs shared skills. The run can load only the skills its creator can see, so share the other skills in the chain too.
  • One output. The orchestrator collects every skill’s result and writes one internal note, so the ticket isn’t buried in notes from each step.
  • Chains can feed each other. A second Flow can run a different skill that edits a saved skill the first chain reads. That’s how the example below learns.

​
Example: a self-learning triage agent

As an example, this guide chains skills together for the self-learning triage agent in the Magic Library. The skills in it are optional: use the ones your desk needs, or swap in your own. The point is to show how skills chain together. Two Flows run it:
  • On a new ticket, the orchestrator sets the category and priority a person hasn’t already set, recommends a ticket type, checks for duplicates, and finds how the issue was fixed before. Everything comes back as one internal note.
  • On a closed ticket, a closure review compares what triage set or recommended with what the technician left. When the same real miss keeps happening, it writes a rule into a learnings skill that the orchestrator reads on every new ticket.

​
The skills in the chain

​
Before you start

  • Super Magic is enabled for your workspace, with Agent Builder available.
  • An admin is available to share the skills. A Flow only runs shared skills.
  • You have a test board, or a single test client, to point the Flows at first.

​
Set it up

1

Save each skill as a shared skill

Open each skill in the table above, copy its prompt and save it in Super Magic under the exact name shown. The orchestrator calls the other skills by name, so a renamed skill is skipped. Have an admin set every one of them to shared.Adapt three of them to your desk before you save:
  • Triage Category: replace the example desk rules with the category lines your technicians actually disagree about. Use category names exactly as they appear on your board.
  • Triage Priority: replace the priority definitions with your own, and use your PSA’s priority names.
  • Self-Learning Triage Orchestrator and Triage Ticket Type: replace the default ticket type placeholder (for example Incident) with the type your PSA puts on new tickets. If you don’t use ticket types, delete Triage Ticket Type from the orchestrator’s list and its Type lines from the note.
Save Triage Learnings exactly as written, with its rule lists empty. The closure review fills it in over time.
2

Stop Magic AI writing the same fields

On the boards this agent will cover, turn off Magic AI auto-categorization and auto-prioritization, including any Flow that runs the Auto-Categorize or Auto-Prioritize action. If both are on, they overwrite each other and you can’t tell which one made a pick. Auto-categorization can run on a ticket through more than one path, so check each one in Assistive AI client access and run paths.
3

Build the new-ticket Flow

In Thread Admin, go to Flows and select Create Flow. Name it, for example Self-learning triage: new tickets.
  1. Add a filter for the board or boards to cover. Start with your test board.
  2. Add the Agent Builder action and choose Run a Skill.
  3. Select Self-Learning Triage Orchestrator.
  4. Tick the write tools the chained skills need: setting the ticket classification or category (Triage Category), updating the ticket (Triage Priority), adding an internal note, and merging tickets (Duplicate Hunter). Each skill’s library page lists its tools. In Run a Skill mode, ticking nothing gives the agent every automation-safe write tool, so tick these explicitly.
A Flow runs once per ticket, the first time the ticket matches its filters. So a board-only filter runs this when a ticket arrives.
4

Build the closed-ticket Flow

Create a second Flow, for example Self-learning triage: closed tickets.
  1. Use the same board filter, and add a filter for the status your PSA uses for closed or resolved tickets.
  2. Add the Agent Builder action, choose Run a Skill and select Triage Closure Review.
  3. Tick the write tools for adding an internal note and editing a skill. Don’t tick updating the ticket: the review should never change a closed ticket’s fields.
5

Test it on one ticket

Leave both Flows off and create a test ticket on the test board. Then turn the new-ticket Flow on and update the ticket so it matches.
  • Check the ticket for one internal note headed TRIAGE RESULTS: the category and priority set, the recommended ticket type, confidence for each, any learned rules used, similar tickets, duplicates and prior resolution.
  • Change one of the fields the way a technician would, then close the ticket with the closed-ticket Flow on.
  • Check for an internal note headed CLOSURE REVIEW. A real miss goes on the watchlist; a single miss never becomes a rule.
To see an agent’s reasoning, open Super Magic → Flow Chats. To check whether a Flow fired at all, open Flows → Logs. When the output looks right, widen the board filter.

​
How the agent learns

The orchestrator leaves one internal note, headed TRIAGE RESULTS, that records what it set or recommended and how confident it was. When the ticket closes, Triage Closure Review compares that note with the final values:
  1. It throws out debatable misses. These include issues that changed during the work, picks that also fit the ticket text, changes made by automations, and priority changes caused by the issue getting worse.
  2. A real miss goes on the watchlist in Triage Learnings, described as product plus problem, for example accounting app error on a single laptop.
  3. A watchlist item becomes a learned rule after three matching corrections, or after two when the agent was highly confident both times.
  4. Learned rules come first. On every new ticket, Triage Category, Triage Ticket Type and Triage Priority check the learned rules before their own rules.
The only skill the review edits is Triage Learnings, and every rule is one line with its evidence tickets. Open it once a week and delete any rule that looks wrong. That rolls it back.

​
Keep client exceptions in Client Intelligence

Some corrections are true for one client only, such as a client whose line-of-business app always goes to a specific category. A desk-wide rule would misfile everyone else’s tickets. Super Magic can read and add to a client’s Client Intelligence notes, so those exceptions can live there instead. To add this, put the following line in Triage Closure Review under STEP 3:
Then put this line in Self-Learning Triage Orchestrator under STEP 1:
In the closed-ticket Flow, also tick the write tool for updating client notes. Both prompts stay under the 3,000-character skill limit with these lines added.

​
When a chain goes wrong

  • The note never appears. Check Flows → Logs to see whether the Flow fired. Agent actions report Dispatched, which only means the handoff worked. Then check that every skill is shared and saved under its exact name.
  • A skill is skipped or reported as missing. Its saved name doesn’t match the name in the orchestrator. Rename the skill or edit the orchestrator so the two match.
  • It stops running after someone leaves. A Run a Skill agent runs as whoever created the skill, and the action stops silently if that person is deactivated.
For trigger, tool and run-as details that apply to every agent, see Build an agent with Agent Builder.