Product

A technician's first twenty minutes, done before they sit down.

Digby lives in a badge on the PSA ticket page. He reads, digs, writes up, and proposes. The technician reads a note with cited evidence, clicks a card, and moves on. Everything he did is on the ticket.

34read-only diagnosticsWindows, through your RMM. All live-verified.
41approval-gated actionsEach with preview, execute, and verify steps.
16Microsoft 365 actionsIdentity, access, Exchange Online, mail security.
32read tools in the loopTickets, devices, docs, memory, runbooks, internet checks, plus a searchable catalog of every read the connected platforms offer
01 Dig

Real diagnostics, chosen by the symptoms.

Thirty-four read-only scripts run through your RMM: recent errors and crashes, disk health, services, network, printers, Office, security posture, join status, installed software, certificates, Wi-Fi and VPN profiles, local admins, startup programs, battery, activation. The first pass runs a small baseline plus whatever the ticket's words point at.

  • Bounded, read-only, never modifies the machine
  • Output cited line by line in the note
  • Digby picks the next script from what the last one showed
  • When a PC cannot reach a printer, a share, or VPN, he checks a working peer at the same client and reasons from the differences
  • Beyond the LAN: DNS, certificate, registrar and ISP lookups cross-checked with your docs
Activity · TIC0010065 tool runs
TimeScriptResult
19:27:14get-disk-spaceC: 22.4 GB free of 222 GB
19:27:22get-system-eventsDCOM warnings ×48, Secure Boot off
19:27:26get-app-crashesExplorer.EXE ×9 this week
19:27:31get-printer-statusOnly virtual printers; spooler running
19:27:48get-network-basicsWi-Fi disconnected; Ethernet 2 up
19:28:03compare_devicesPeer FRONT-DESK-02 has HP LaserJet on port 192.168.4.20
02 Propose

A card that says what will happen, measured first.

Before proposing a write, Digby runs the matching preview: the dry run for cleanup, the pending list for patching, the queue for printers. The card shows those numbers, why he thinks it will help, and the verify step that runs after.

  • 41 endpoint actions: cleanup, patching, install and removal via winget, print queue, network reset, Office and system repair, Outlook profile rebuild, printers and mapped drives, VPN and Wi-Fi profiles, temporary local admin with expiry, RDP, rename, scheduled reboot
  • 16 Microsoft 365 actions: onboard, offboard, password reset, session revoke, MFA reset, access requests, shared mailboxes, forwarding, out-of-office, distribution lists, quarantine release, sender block
  • Hybrid Active Directory onboarding: create on the domain controller, sync with Entra Connect, wait, then license and group in the cloud, as one approved card
  • Secrets for VPN and Wi-Fi resolve from your vault at run time. The model never sees a value.
  • Protected services and unknown packages refused in code, not in a prompt
Approval cardautonomy: suggest
ActionDisk cleanup on DESKTOP-6N590PK
What will happenFrees about 0.63 GB: user temp 0.56, Windows temp 0.02, update cache 0.05, recycle bin 0
WhyC: at 10% free; low disk space is a known cause of the QuickBooks crash on this host
Verifyget-disk-space after the run
Track recordDisk space at this client: 8 of 10 matched
DecisionApproved by technician · 12 min time entry posted
03 Learn

He remembers the client, and you can correct him.

A Memory tab lists what Digby knows about the client and the device, with the source of each fact. Say "that's not the patch window, it's Tuesday after 6" in chat and it sticks, and outranks anything he learned from a ticket. A fix seen three times becomes a draft runbook.

  • Seeded from ticket history and documentation in a run we do with you
  • Technician corrections always win
  • Runbooks: checks, fix, verify, approved before use
  • A learning ledger shows every behavior change and why
The full story of how Digby learns
Memory · Branum Solutions17 facts
primary_userDana Branum, Office Manager, prefers phone callbacks · hudu
installed_appQuickBooks Desktop 2024, company file on D: · hudu
known_issueC: fills from QuickBooks backups in Documents · hudu
sitePatch window Tuesdays after 6pm · corrected by J. Alvarez
resolution_patternDisk cleanup: dry run, then execute · ticket TIC001004 · seen 3×
golden_configFront-desk printer: HP LaserJet, TCP/IP port 192.168.4.20 · learned from FRONT-DESK-02
04 Prove

A page your service manager will actually open.

Tickets seen, triage overrides, shadow match rate by category, approvals and declines, minutes saved, model usage by purpose, and what Digby learned this week. Same numbers in a weekly digest you can paste into Teams.

  • Per client and per category
  • Cost per ticket from real token counts
  • Recent actions feed for audit, exportable
  • Hygiene findings the sweep could not check are reported as "not checked", never as a false zero
Intelligence · last 30 days6 clients
Tickets seen37
Shadow matched
Account access 7/9 · Hardware 5/6 · Software 4/5 · Disk space 8/10
Approved / declined14 / 3
Minutes saved412 · from per-action estimates
Model usageshown per purpose, per client
Learned this week3 facts · 1 correction · 1 runbook approved
Beyond the ticket

Work that starts before anyone writes in.

Proactive intake

RMM alerts become triaged tickets, deduped per device. A daily hygiene sweep opens one ticket per client for end-of-life Windows, Defender or BitLocker off, stale reboots, expiring certificates and warranties, and unused licenses. Weekly patch compliance proposes a window from memory.

Ticket handling

Asks the requester what is missing and resumes when they reply. Resolve-and-close in one card: reply, status, time entry, KB article. Related-ticket citations for "it's broken again". Escalation packets with what was tried, what was ruled out, and the next three things to try.

Cost you can see

Every model call is recorded with its purpose. Cheap models do the cheap work; a stronger model is used only for hard cases, behind a daily spend cap. Model usage is included in the plan.

Integrations

Built on the tools you already run.

Adapters are small and tested against recorded fixtures, so adding a platform is a bounded job, not a rewrite. The approval gate and autonomy dial live above the adapters, so they apply the same way on every stack.

FAQ

Questions we get first.

Can Digby change something on a machine without a technician?

No. Nothing on a machine, a mailbox, or an account changes without a technician's click: read-only diagnostics run on their own, and every write is a proposal card. Digby does write to the ticket itself from day one — he files it into a category and posts internal notes, and both are switches you can turn off in the console. He also opens tickets of his own from RMM alerts and the hygiene sweep. The one write he can earn is closing a ticket, per category, only once that client's scored track record passes a fixed bar (20 checked tickets, 90% right) and the requester has confirmed the fix.

How is this different from a workflow builder?

There are no flows to design. Digby reads the ticket, decides what to check, and proposes what to do. When a fix repeats, he drafts a runbook for you to approve, so the playbook builds itself from real tickets. See Why Digby.

Is model usage included?

Yes. Plans are priced per technician with a ticket allowance, and model usage is included. Digby records every call, so the Intelligence page shows exactly what was spent and on what. Larger desks that prefer to bring their own model keys can.

Which platforms are supported today?

Ticketing: AlgaPSA and HaloPSA, both running against live instances. Devices: Level, live; NinjaOne built and waiting on a live tenant. Documentation: Hudu. Microsoft 365 through Graph including Intune, plus Exchange Online. Security: Huntress, built and waiting on a live tenant. ConnectWise, Datto RMM and IT Glue are next. Tell us your stack when you sign up.

How does onboarding work?

A setup wizard walks you through it: connect each tool and watch it test itself, match your clients to their records in each platform, add your technicians, and sign in with your Microsoft work account. You create one script-runner automation in your RMM and install the extension. We then seed his memory from your ticket history and docs with you, and every client starts in shadow mode. Raise autonomy when the numbers earn it.

Where does the data live?

Per tenant, per client. Memory, outcomes, and usage are scoped so one client's facts never appear on another's ticket. Secrets are scrubbed from every note and transcript, and vault-referenced secrets are resolved at run time without passing through the model.

Early access

Start in shadow mode.

Two weeks on your real tickets, writing up every one and fixing none, a scored report at the end, then you decide what Digby gets to touch.

Get early access