How Digby learns

He starts in shadow. He keeps score. You turn the dial.

Most tools ask you to trust a resolution rate from someone else's help desk. Digby builds a track record on yours, one client and one category at a time, and shows you every number before you give him anything to touch.

01 Shadow mode

Every ticket, Digby writes down what he would have done.

Whether or not he is allowed to act, he records a private shadow decision: the action he would have proposed and a one-line plan. When your technician closes the ticket, a background sweep compares that guess with what actually happened and scores it.

  • Matched. His guess, including "nothing to do", was right.
  • Partial. On the right track, incomplete or needed correction.
  • Wrong. A different action was needed.
  • Unknown. Not enough evidence to tell. Never counted as a win.

Each ticket is scored once and never rescored. Scoring runs on the same cadence as the ticket poller, so there is nothing extra to babysit.

Shadow outcomes · Retail Corner Comicslast 30 days
TIC001005Disk space · would have proposed disk cleanup · scored 4 min after closematched
TIC001006Printer · would have cleared the queue and re-addedmatched
TIC001009Account access · would have reset the password; tech also revoked sessionspartial
TIC001012Software · would have reinstalled Office; the add-in was the causewrong
TIC001014Hardware · would have asked for the modelmatched
TIC001015Disk space · would have proposed disk cleanupmatched
TIC001018Software · would have run Office repairunknown
02 The trust ladder

Autonomy is a dial per client and per category, moved on evidence.

Once a category at a client has enough scored outcomes, Digby shows the track record in every note and folds it into his own confidence. A poor record makes him more cautious automatically. A good one is your evidence for the next rung.

1level

Shadow

Reads the ticket, looks things up the way a technician would, runs read-only diagnostics on the machine, and posts the write-up with cited evidence and both confidence scores. Nothing on the machine, the mailbox or the account changes. On the ticket itself he files a category and posts internal notes, both switchable off. This is where every pilot starts.

Digby digs
2level

Suggest

Suggests fixes as approval cards with a measured preview. A technician clicks Approve or Decline. This is where most desks run.

You approve
3level

Earned auto-close

For a category whose scored track record at that client clears the bar — 20 checked tickets, 90% of them right — Digby can close the ticket himself, and only after the requester confirms the fix. Every other write still needs the click.

Track record decides
Shadow decisions are recorded at every level, so the score keeps building whether or not Digby is allowed to act. A client you want left alone entirely is marked out of scope, which is its own switch rather than a rung on this ladder.
03 Memory

Four kinds of memory, each with a source on every fact.

After every write-up a cheap model consolidates what was new into structured memory. The next ticket reads memory first and only pulls raw history when memory has no answer. Nothing crosses a client boundary.

Client and device

Primary users, installed apps, known issues, patch windows, resolution patterns, golden configurations learned from working peers. Seeded from your docs and ticket history in one learning-mode run.

How this MSP works

Process rules that apply everywhere: "check the switch before the PC on printer tickets", "never patch accounting firms during the first week of the month". Promoted from a client fact when a technician says so.

Per person at the client

Who sits at which machine, who prefers a phone callback, who has asked about this before. Kept against the requester, so the next ticket from them starts where the last one ended.

Per technician

Who wants the long version of the note, who never wants a scheduled reboot proposed after 4pm. Told to him in chat, and it shapes how he talks to that technician from then on.

04 Corrections

Tell him he was wrong, or just decline and say why.

"That's not the patch window." "This client doesn't use QuickBooks anymore." "Check the switch first on printer tickets." Digby retires the contradicted fact, records yours as technician-sourced, and replies with one sentence saying what changed.

  • A technician's correction always outranks a fact learned from a ticket or a document.
  • A correction can be scoped to the client, to the whole MSP, or to the technician's own preference.
  • A correction on a category lowers Digby's confidence in that category for a while, so a recent wrong assumption makes him double-check before trusting the next guess.
  • Declining a card and saying why teaches him too: if the reason states a standing rule, he keeps it against that client — or the whole MSP — with the ticket it came from as the source.
  • Forget a client or device fact with one click on the Memory tab, and it is gone.
Chat · Branum SolutionsMemory tab open
that's not the patch window, it's tuesday after 6 now. and for all printer tickets check the switch before the PC
correct · client fact site.patch_window retired → technician fact recorded
correct · tenant rule added: printer tickets, switch before PC
Updated. Patch window for Branum Solutions is now Tuesdays after 6pm, and on printer tickets at every client I'll check the switch before the PC. Both show in the ledger with your name on them.
Learned from you · 2 changes
Runbook · Disk cleanup when C: is lowapproved
Drafted fromresolution_pattern seen 3× · TIC001004, TIC001005, TIC001015
Checksget-disk-space · get-app-crashes
Fixdisk-cleanup, dry run then execute, behind approval
Verifyget-disk-space shows more than 15% free
Historyused 4 · succeeded 4 · approved by J. Alvarez
05 Runbooks

The playbook writes itself from your closed tickets.

When the same fix closes the same kind of ticket repeatedly, Digby drafts a runbook: the checks, the fix, the verify step, and the tickets it came from. A technician approves it. From then on it is a tool he can reach for, with its own used-and-succeeded history.

  • Nothing is encoded by hand. No Jinja, no flow canvas, no PowerShell pack to maintain.
  • Every runbook cites the tickets it was learned from.
  • A runbook that stops working shows it in its own numbers, and can be retired in one click.
  • The dig order itself learns: checks that led to matched outcomes move earlier.
06 The learning ledger

Not just what Digby did. Why he now does it that way.

Every behavior change is listed with its source: a fact added or retired, a fact promoted to the whole MSP, a runbook drafted or approved, a dig-order pattern learned, a technician's correction. Grouped by client on the Intelligence page, and available as plain text for the weekly digest.

This is the answer to the question every service manager asks about an AI: "why did it do that?" With Digby the answer is a line in the ledger with a name and a ticket number on it.

What Digby learned · this week6 clients
Tenant rule: on printer tickets, check the switch before the PCcorrection · J. Alvarez · Thu 14:02
Branum Solutions: patch window is now Tuesdays after 6pmcorrection · J. Alvarez · Thu 14:02 · retired fact from hudu
Runbook approved: Disk cleanup when C: is lowdrafted from 3 tickets · approved by M. Chen · Wed
Retail Corner Comics: golden config for the front-desk printerlearned from peer FRONT-DESK-02 · TIC001006
Dig order: on "slow PC" tickets, get-app-crashes now runs before get-system-events7 of 8 matched outcomes cited it first
Software at Northside Dental: confidence lowered for 30 daysshadow outcome wrong on TIC001012
07 Day one

He starts knowing your clients, not from zero.

Read the history

Digby pages through a client's ticket history and documentation and seeds environment memory with sourced facts.

Draft the runbooks

Repeated fixes in the history become draft runbooks, waiting for approval, each citing its tickets.

Set the house rules

Tell him in plain English how your desk works — "check the switch before the PC on printer tickets" — and it becomes an MSP-wide rule with your name on it.

Start in shadow

Two weeks on live tickets, writing up every one and fixing none, a scored report at the end, then you set the dial.

Early access

See your own numbers, not ours.

A shadow-mode pilot costs you nothing but a script-runner automation in your RMM. At the end you get a scored report per client and category.

Get early access