Available Now /agent-runners

Managed AI Agents for MSP Operations

Agent Runners are saved, reusable AI workers that run against your connected MSP stack — on demand, on a schedule, or from webhook events. With explicit tool scoping, dry-run rollout, and real run history, they turn recurring work into managed AI workflows your team can actually trust.

3
trigger modes — on-demand, scheduled, webhook
9
MSP connectors with per-agent tool scoping
$0
platform fee — pay only for credits consumed
BYOK
bring your own Anthropic key for enterprise
What is an Agent Runner?

A saved AI worker, not a chat session

An Agent Runner is a persistent automation object. You configure it once — prompt, model, trigger, tools, guardrails, knowledge — and then it runs repeatedly against your MSP stack. Closer to a managed workflow asset than a disposable AI conversation.

It’s a saved definition

Name, description, model, system prompt, trigger mode, scoped tools, runtime caps, and optional reusable knowledge — all versioned on every save.

It runs on its own schedule

Fire it on demand, on a cron schedule with timezone support, or from webhook payloads. Each run is tracked with a full execution record.

It’s bounded by design

Explicit tool allow-list, per-agent max runtime, per-run credit cap, dry-run mode, and server-side tenant validation — no implicit trust surface.

Every run is visible

Status, summary, token counts, tool-call count, credits consumed, duration, trigger payload, and full transcript — all retrievable after the fact.

Architecture

From one-off chat to managed automation

StackJack already gives your AI clients scoped MCP access to your MSP stack. Agent Runners add the missing layer — triggers, guardrails, credits, and a run record — that turns a single tool call into a repeatable workflow.

interactive session
mcp.stackjack.io
list_tools
AI client Claude Cursor Agents CI / CD trigger Operator Run Now Scheduler 0 6 * * * Webhook signed · rate-limited Event (planned) StackJack MCP proxy Agent Runner credit-aware · versioned 1 · Pre-flight & reserve credits consent · sync · capacity 2 · Compose prompt & policy knowledge + tool allow-list 3 · Scoped MCP session per-agent credential 4 · Stream · cap · summarize max runtime / credits dry-run · guardrails · transcript MSP stack HaloPSA Autotask ConnectWise NinjaRMM Datto RMM CW Automate CIPP Hudu IT Glue
claude · list_tools
discovering available MCP tools
— per-agent
Scoped MCP client credential
— per-tenant
Plan-aware tool validation
— per-run
Reserved credits & runtime cap
— always-on
Sync state & drift tracking
How it works

From authoring to execution

Every Agent Runner moves through two phases: author & deploy, then execute & record. Both phases are inspectable end-to-end.

Phase 1

Author & deploy

1
Validate configuration
Trigger type and config are checked. Tool list must be non-empty, and requested tools must match your connector subscriptions and plan entitlements.
2
Scope tool access
Each agent gets its own MCP client credential limited to exactly the tools you picked — not a shared super-user.
3
Provision remote runtime
A matching Anthropic agent, execution environment, and credential vault are provisioned in one atomic flow.
4
Compose system prompt
Your prompt is programmatically extended with knowledge, tool policy (allowed / denied / required), and tool chains.
5
Snapshot version & register trigger
A version record is saved. Scheduled agents get a recurring job; webhook agents get a signed URL with a per-agent secret.
Phase 2

Execute & record

1
Pre-flight checks
Feature enabled, consent accepted, sync state clean, capacity available — or the run is blocked before anything remote happens.
2
Reserve credits
Credits are reserved up to MaxCreditsPerRun before long-running work begins. BYOK tenants skip this.
3
Create run & session
A run row is written immediately. The agent receives purpose, current time, dry-run status, and the trigger payload.
4
Monitor to terminal state
Stream events, track tokens and tool-call count, and enforce runtime / credit ceilings. Interrupt or cap as needed.
5
Finalize & expose
Credits finalized (refund or delta). Summary, timing, transcript, and trigger payload are all surfaced in run history.
runs / morning-ticket-review / 4f3a
$ agent run morning-ticket-review --trigger schedule
[pre-flight] tenant ok · consent ok · sync=Synced · capacity ok
[credits] reserved 250 cr · cap 400 cr · balance 3,250 cr
[mcp] scope = [halo_list_tickets, halo_get_ticket, halo_list_assets, …] (7 tools)
[run] started 2026-04-19T07:00:02-05:00 · model claude-sonnet-4-5
→ halo_list_tickets(status=open, priority=≤2, limit=50)
→ halo_get_ticket(id=48231) · halo_get_ticket(id=48244) · …
→ halo_list_assets(client_id=812)
[summary] 12 priority tickets · 3 SLA risk · 1 client impact …
[tokens] in 14,204 · out 2,180 · cache-r 8,992
[tools] 9 calls · runtime 47s
[credits] finalized 212 cr · refunded 38 cr · balance 3,038 cr
Completed · run id r_01jxk2aq5 · view transcript_
Trigger modes

Three ways to fire an agent

Each mode is a real system, not a checkbox. Pick per agent based on how you want the workflow to run.

When to use it

  • •  Operator-initiated triage or investigation
  • •  One-click reporting at the moment you need it
  • •  Ad-hoc “pull context” requests
  • •  Testing a new agent before promoting out of dry-run
// One-click from the portal
POST /agents/morning-ticket-review/run
{ trigger: "manual", context: "focus on SLA risk" }
→ run created, credits reserved, execution starts

When to use it

  • •  Daily ticket review, weekly briefings, nightly hygiene
  • •  Recurring drift, backlog, or audit checks
  • •  Anything where “always at 7am” matters
Timezone-aware cron. Startup reconciliation re-registers expected jobs after deploys. Silent skip if the tenant becomes ineligible — no double-billing.
// Schedule config
schedule: "0 7 * * 1-5" // weekdays 7am
timezone: "America/Chicago"
max_runtime: 120s
max_credits_per_run: 400
→ job registered · next run Mon 07:00 CDT

When to use it

  • •  Event-driven follow-up (new ticket, alert, PagerDuty)
  • •  Kicking off context gathering right when something happens
  • •  Bridging external systems into MSP workflows
Signed secret Rate-limited Payload modes

Per-agent webhook secret, configurable payload modes (none / full / selected fields), payload size cap, and 10 hits/minute per-agent rate limit.

// Webhook URL (per-agent, signed)
POST /hooks/agt_9fx…/s_7aq…
content-type: application/json
{
  "ticket_id": "48231",
  "priority": 1,
  "client": "Acme Corp"
}
→ payload mode = selected fields
→ run starts with trigger context attached
 
On-demand
Scheduled
Webhook
Fires from
Portal or API
Timezone-aware cron
Signed HTTP POST
Input payload
Operator context
None (instructions in prompt)
None / full / selected fields
Rate limit
Human-paced
Your cron
10 / min per agent
Guardrails

Control is what makes AI deployable

MSPs don’t need more autonomy — they need more control. Agent Runners are built for supervised rollout, not magic-button hype.

Dry-run mode

The runtime filters the agent’s tool access to read-only during dry-run. Not a label — it materially changes what the agent can do.

promote-when-ready workflow

Explicit tool scoping

Agents cannot be created without a concrete tool list. Every requested tool is validated against your connector subscriptions and plan.

server-side, not cosmetic

Tool policy & chains

Beyond a simple allow-list: tri-state policy (allowed / denied / required), plus optional ordered tool chains for multi-step workflows.

allowed · denied · required

Runtime & credit caps

Max runtime and MaxCreditsPerRun are enforced at runtime, not reported after the fact.

CreditExhausted status exists

Consent & sync checks

Runs are blocked if consent isn’t accepted or the agent’s remote state drifted. Silent failure isn’t an option.

SyncNeeded · ScheduleDrift visible

Webhook hardening

Per-agent signed secret, payload size cap, 10/min rate limit, and payload mode control — full, selected fields, or none.

secret rotates per agent
Credits & pricing

Pay only for what runs. Nothing expires.

No platform fee. No seats. Agent Runners are included free for any StackJack user — you just buy credits for execution. Packs never expire.

01 · reserve

Estimate up front

Before any run, credits are reserved up to the agent’s per-run cap. Complexity and expected runtime inform the estimate.

02 · track

Live as it runs

Token usage, tool calls, and duration are tracked in real time. The estimate tightens as the run progresses.

03 · finalize

Refund the difference

After the run, actual consumption is finalized. Unused reservation is refunded. Every transaction is in the ledger.

Credit packs

One-time purchase. Credits never expire. Stack as many packs as you want.

Starter
$5
Try a few runs · kick the tires
Buy
Small
$10
Regular light usage
Buy
POPULAR
Team
$25
Daily scheduled agents
Buy
Growth
$50
Multiple agents running regularly
Buy
Scale
$100
Heavy scheduled & webhook workflows
Buy
Bulk
$200
High-volume multi-agent operations
Buy
credits
Never expire · stack any number of packs
ledger
Reservation, finalize, and refund transactions are all visible
per-agent cap
Set MaxCreditsPerRun so a run can’t blow past your budget
wizard
The builder itself is credit-aware — reserved, finalized, refunded on failure
ENTERPRISE BYOK

Bring your own Anthropic key

Enterprise tenants can supply their own Anthropic API key. BYOK runs bypass managed credit billing entirely — including wizard turns — while the platform still records full audit transactions for every run. Same guardrails, your billing relationship.

Talk to us →
Run history & observability

Every run is inspectable

No “it ran” mystery. Every execution gets a persistent record with status, timing, tokens, tool calls, credits, summary, and a transcript you can pull on demand.

morning-ticket-review
sched · 0 7 * * 1-5 · America/Chicago last 7 runs
Started Status Duration Tools Tokens Credits Summary
Apr 19 07:00✓ Completed47s916,38421212 priority, 3 SLA risk
Apr 18 07:00✓ Completed52s1118,12024415 priority, 1 client impact
Apr 17 07:00! TimedOut120s1422,004304Hit max runtime — partial summary
Apr 16 07:00✓ Completed41s814,2901889 priority, clean backlog
Apr 15 07:00✓ Completed39s713,88017611 priority, 2 new escalations
Completed Running Pending TimedOut CreditExhausted Failed Interrupted
Use cases

What MSP teams actually run

Real workflows. Not hypotheticals. Each of these fits the Agent Runner shape: recurring, cross-system, judgment-heavy, too messy for a script.

SCHEDULED daily 7am

Daily priority queue review

Reviews open priority tickets, pulls cross-system context from PSA + RMM + docs, flags SLA risks, and drops a briefing in the team channel before standup.

HaloPSA NinjaRMM Hudu
WEBHOOK on new P1

High-priority ticket triage

When a P1 fires, the agent gathers recent related tickets, client contacts, known assets, and documentation in seconds — posted directly to the ticket.

Autotask Datto RMM IT Glue
SCHEDULED weekly Mon 6am

Weekly service briefing

Generates per-client weekly summaries: ticket trends, SLA hits/misses, recurring issues, and asset changes. No more manual cross-tab assembly.

CW Manage HaloPSA
SCHEDULED nightly 11pm

Documentation hygiene & drift

Checks IT Glue and Hudu for stale configs, missing passwords, expiring certs, and orphaned assets. Flags items before they become client-facing issues.

IT Glue Hudu NinjaRMM
ON-DEMAND on request

QBR prep brief

One click: the agent compiles a client’s ticket trends, asset posture, escalations, and open risks into a QBR-ready narrative with source citations.

HaloPSA Datto RMM IT Glue
WEBHOOK on M365 alert

M365 security response

On a CIPP alert, the agent looks up the affected tenant, correlates with user activity, recent mailbox changes, and admin actions — then summarizes suspected blast radius.

CIPP HaloPSA
How it compares

Chat is useful. Scripts are reliable. Agent Runners sit in the middle.

Traditional automation is great for rigid tasks. Chat is great for exploration. Agent Runners handle the recurring workflows that need context, summarization, and cross-system judgment.

  AI chat session Scripts / RPA Agent Runner
Persists between uses No — one session Yes Yes — versioned definition
Handles context + summarization Yes No Yes
Runs on schedule / webhook No Yes Yes
Tool access is scoped & audited Session-level Script-specific Per-agent MCP credential
Handles messy / judgment-heavy work Yes Brittle Yes
Safe rollout / dry-run Ad hoc Staging envs Built-in, read-only
Run history & spend caps Chat log Logs, if you build them First-class, with credit ledger
Templates & marketplace

Start from a template. Publish your own.

Built-in templates, tenant-shared agents, and a moderated marketplace with versioning, risk badges, and safety scanning. Templates are parameterized, reviewable automation blueprints — not chaotic snippets.

read-only write-scoped destructive credential-sensitive webhook-input community-shared curated
daily-ticket-review
Daily Priority Review · 428 installs
qbr-prep-brief
QBR Prep Narrative · 212 installs
doc-hygiene-sweep
Doc Hygiene Sweep · 175 installs
FAQ

Questions

Do I need to pay for Agent Runners separately from my connector subscription?

No. Agent Runners are included free for any StackJack user — including Free-tier connector users. You only pay for credits, which cover the actual AI execution and tool calls. Credit packs never expire.

How do credits relate to actual usage?

Before every run, credits are reserved based on the agent’s complexity and expected runtime, up to the agent’s MaxCreditsPerRun cap. As the run executes, real token and tool-call usage is tracked. At the end the run finalizes: unused reservation is refunded, and every transaction shows in your ledger.

Which tools can an agent access?

Only the tools you explicitly pick when authoring the agent — and only if those tools are available via your connector subscriptions and plan. Each agent gets its own scoped MCP credential, so one agent cannot “borrow” another agent’s access surface.

What does dry-run mode actually do?

Dry-run is not a label — the runtime filters the agent’s tool access to read-only operations. That lets you verify behavior, review transcripts, and build trust before promoting an agent to live execution with write access.

How are scheduled agents rate-limited?

Scheduled agents run on your configured cron with timezone awareness. If the tenant becomes ineligible (e.g. insufficient credits) or capacity is unavailable, runs are silently skipped rather than piling up failures or double-billing. Startup reconciliation re-registers expected jobs after deploys.

How are webhook endpoints secured?

Each webhook-triggered agent gets its own signed secret baked into the URL. There’s a per-agent rate limit (10 / minute), a payload size cap, and three payload modes: none (prompt-driven), full payload, or selected fields. You control exactly what context the agent sees.

Can I bring my own Anthropic API key?

Yes. Enterprise BYOK is supported: runs and wizard turns bypass managed credit billing entirely. The platform still records audit transactions for every BYOK run so you have full operational traceability. Talk to us to set it up.

What knowledge sources can an agent use?

Today, Agent Runners support reusable text snippets and URL-fetched content as knowledge sources. File-based knowledge is on the schema for legacy reasons but is not currently supported as a live runtime feature.

What happens if a run blows past its credit cap?

Runs have a MaxCreditsPerRun setting and the runtime enforces it — the run is marked CreditExhausted with whatever summary was produced to that point. If actual consumption exceeds reservation within the cap, the delta is recorded in the ledger rather than hidden. This preserves billing truth.

Can I see what an agent did during a run?

Yes. Every run has a record with status, timing, token counts, tool-call count, credits consumed, a summary, trigger payload, and a full transcript you can fetch on demand.

Can I share or publish agents?

Agents can be saved as templates (private, tenant-shared, or submitted to the marketplace). Templates are versioned, parameterized, and go through scanning + admin moderation with risk badges before publishing. So the marketplace is moderated, not a free-for-all.

Does StackJack see or store my data?

StackJack is a proxy — your business data passes through during runs and is not stored, cached, or retained. Run records store metadata (status, timing, token counts, summary) and transcripts so you can review what happened, but the underlying MSP data is never retained outside that. See the full security brief.

Turn recurring work into managed AI workflows

Agent Runners are available today for every StackJack user. Buy a credit pack to start — packs never expire, and you’ll see real-time usage against your balance as your agents run.