Agent Runners

The Agents page is where an Administrator manages two kinds of agent. QuantumOps runners are governed AI jobs that run inside QuantumOps on a schedule, on an event or on demand. StackJack automations are StackJack's own agents, which you build and change with Qubit. Open the page from Agent Runners in the sidebar.

A runner has a goal, a trigger, a model, a tool allowlist, budgets and an approval policy. Every tool call it makes is checked by Tool Governance, counted against its budgets and written to a transcript.

Create a runner

1. On QuantumOps runners, choose New runner. The Create runner card opens.
2. Fill in the fields in the table below.
3. Choose Save. The page confirms "Runner saved."
4. Give the runner permission to act. A runner can only call a tool that Tool Governance allows for AgentRunner. See "Tools a runner can use".

Choose a trigger

The three event triggers behave the same way: Webhook event, Q-Notice event and Alert Engine event (legacy). The runner starts when QuantumOps publishes an event with one of your event keys. Pick the label that describes where your events come from. Alert Engine event (legacy) is kept for runners that already use it.

Cron holds five fields: minute, hour, day of month, month and day of week. QuantumOps checks the schedule every minute and reads the times as UTC. For example, 0 9 * * 1-5 starts the runner at 09:00 UTC on weekdays.

Event key(s) takes event names separated by commas, for example TicketClosed,TriageComplete. Capital letters do not matter. They are the same event names that your Q-Notice rules listen for, so see Q-Notice auto-rules.

• When the same event is delivered more than once for the same item in a short time, the runner starts once. "Short" is about five minutes, or the Debounce (s) time if you set one.
• Debounce (s) also keeps one runner from starting more often than that.
• Events that come from a historical import or from a catch-up sweep never start a runner.

Choose an approval policy

A tool that Tool Governance denies never runs under any policy. The transcript records it as denied, and the runner carries on with other tools or finishes.

When a runner queues a step for approval, the run pauses with the status AwaitingApproval. An Administrator decides the step in the browser extension's Approvals tab. See Approvals tab. There is no approvals page in the portal. QuantumOps checks for decisions every minute. When the step is approved, the tool runs once and the run continues. When it is denied, or when nobody answers within 24 hours by default, the run ends.

Set the limits

A run stops as soon as it passes any limit, with the status BudgetExceeded and a budget step in its transcript. The limits are what make it safe to leave a runner on a schedule, so set them on purpose.

• Max iterations is the number of turns the model may take.
• Max tool calls and Max tokens cap the work in one run.
• A 0 in a count field means the default (8, 20 or 200,000), never "no limit".
• A blank Max cost (USD) means the run has no cost limit; the other three limits still apply. The cost is an estimate.

Tools a runner can use

Tool allowlist takes one pattern per line. A * stands for any run of characters. The list decides which tools the runner is shown, at most 40. It does not give permission by itself.

Tool Governance gives permission. The AgentRunner surface denies everything until a rule allows it. A starter set of rules covers QuantumOps's own read tools. For anything else, open Tool Governance and use Generate Allow rules on the runner, or write the rules yourself.

A runner can use:

• QuantumOps's own tools, such as the HaloPSA lookups, whose names start with halo_.
• The tools of MCP sources that belong to the whole organisation and do not need a person to sign in, which means a key, a client ID and secret, or no sign-in at all. See MCP sources.

A runner cannot use per-user sources, which include the StackJack preset, or sources that use OAuth sign-in. A runner has no signed-in person, so there is no account to use. Tools whose names start with sj_ belong to a person's own StackJack connection, so they are skipped on scheduled, event and manual runs. The editor warns about this when the allowlist holds StackJack tools. The warning appears for any pattern that does not start with halo_ or azure_. A pattern for an MCP source or a built-in tool also shows it, but those tools run when Tool Governance allows them.

A skipped tool is not an error. A runner whose goal depends on skipped tools can finish having done nothing, so read its transcript before you trust the result. To automate with StackJack, build a StackJack automation instead (see below).

Run a runner now, switch it off or change it

The QuantumOps runners list shows each runner's Name, Trigger, Approval policy and whether it is Enabled, with icons in Actions:

• Run now starts a real governed run, not a dry run. It works whether or not the runner is enabled. The page reports how the run finished and opens its history.
• Run history opens the runs of that runner.
• The toggle switches the runner on or off.
• The pencil opens the editor. Choose Save to keep your changes or Cancel to leave them.
• The bin deletes the runner after a confirmation. The confirmation notes that the run history is kept.

Read a run

Run history lists each run with when it Started, its Status, what started it (Trigger), the number of turns (Iters), Tools called, Tokens used and the Cost. Choose Transcript to open one run.

The transcript shows the runner's final answer next to Outcome, then one row per step with its #, Step, Tool, Policy, Outcome and Tokens (the tokens a model turn used). The Policy column is the decision for that tool: Allow, RequiresApproval or Deny. Steps include each model turn, each tool call, requests for approval, denials, budget stops, notes from the Notify policy and the final answer. Use it to see which tool a runner called and what came back.

A run from before transcripts were kept shows a message that no steps were recorded. That is an older run, not a failed one.

StackJack automations

The first card on the page, StackJack automations, lists the StackJack automations that your own StackJack account can see. A small tag beside the count says your StackJack account when the source signs each person in, or shared StackJack credential when it is a tenant-wide source. A tenant-wide source means everybody acts as one shared credential.

Before you start, an Administrator adds the StackJack preset under MCP Sources and you connect your own account. See StackJack. Until then the card says so and offers:

• Open MCP sources, when no StackJack source exists for you yet.
• Connect or Reconnect, when you have not signed in or your sign-in has expired. Sign in in the new tab, then choose I have signed in.
• Retry, when the list could not be read. The message says why.

When the list loads:

• Choose Active, Drafts or All to filter it. Each button shows how many automations it holds. Active shows active automations that are not drafts.
• Type in the search box to match a name, description, model, trigger or id.
• Refresh reloads the list. It is kept for about a minute, and the card says when it was last updated.
• Each row shows the Automation, its Trigger, Model, State (Draft or Live), whether it is Active, whether it is a Dry run, how many tools it has and when it was Updated.

If your StackJack catalog does not include the tools that list automations, the card says so. Check the Allowed tools and Denied tools of the source in MCP Sources.

You change an automation by asking Qubit, not by editing it on this page. New automation and Edit with Qubit open the Qubit pane in a new conversation. Three icons on each row do the same for related requests: inspect its runs, run it now and stage a copy.

Each action types an instruction for you but does not send it. Add what you want, then send it. Any change then goes through the normal approvals in Qubit chat. If the page says the Qubit pane is not available, reload the page. If it persists, contact TechPulse.

Related pages

• Tool Governance: the rules a runner must have before it can act, and the audit list.
• Approvals tab: where an Administrator decides a runner's approval requests.
• StackJack: the per-user setup that the automations list uses.
• MCP sources: which sources a runner can use.
• Q-Notice auto-rules: the events a runner can listen for.
• Q-Notices and Alert Engine: the event sources behind the Q-Notice and legacy triggers.
• Chat analytics: how Qubit is used, with the tool calls of Agent Runners under Other governed surfaces.