Nine phases in, everything below runs against recorded fixtures in a test suite of about 3,500 tests. Where an item says live-verified it was also run against a real PSA, RMM, documentation tenant and Microsoft 365 tenant. Where it says fixture-tested it has not yet been, and we say so.
Connect each platform and watch its own connector test itself, match your clients to their records in each one, add your technicians and hand each a pairing code, and sign in with your Microsoft work account through one consent click. Digby starts in shadow for every client.
Six pages built around the questions a help desk manager asks: is Digby helping and what needs me; can I trust him more, with a readiness meter per client and category next to the autonomy dial; what did he do; who is using him; is everything connected, with live checks and client matching; and what he knows. Plain language throughout. Sign in with your Microsoft work account; only technicians a manager added get in.
The first pilot's ticketing platform, behind the same connector contract AlgaPSA meets, so nothing above changes when you switch. A Halo ticket type plays the part a board plays. 185 of its read endpoints are searchable, scoped to the client; invoicing, sales and stock are deliberately absent. Contracts and prepaid blocks are read so every note can say whether the work is covered.
Every platform runs behind its own connector process that only Digby's service talks to, holding only that platform's credentials. Each connector publishes a catalog of read-only endpoints, checked against the live platform at startup. When no tool covers a question, Digby searches the catalogs and runs a read that the connector scopes to the ticket's client, with every call audited and visible in the console.
Each client is matched once to its RMM group, documentation company, and security organization, suggested by Digby and confirmed by a manager on one screen. People are matched to their devices by a ladder (named in the ticket, the PSA asset, a remembered device, the RMM's last sign-in) and remembered, and Digby asks a technician when nothing fits.
A fix that worked at another client for the same symptom appears in the internal note, never in anything a customer sees. Changes made from chat act on one client and one item at a time, are restorable for 30 days, and stop after three in a conversation.
Open incidents and escalations, each device's EDR and Defender health, External Recon ports, and identity risk, in every context pack and searchable by Digby. Read only.
A second RMM. Organizations play the part groups play, the full read catalog is searchable, and device scripts run through one generic runner script the MSP pastes once. Nothing tied to any one instance.
A senior-tech method in every prompt, plus eight playbooks (network, printer, slow PC, new user, lockout, email, VPN, app crash) that pick the checks and the documentation to read. A missing fact the action needs becomes a drafted question to the requester, offered as an approval card. Each MSP tunes the playbooks from chat, and a golden set of real-sounding tickets guards the branch Digby takes on every push.
Triage, device match, docs and history, a narrated note with two confidence scores, before a technician opens it.
A draggable badge injected onto the ticket page with chat, Activity, Memory and Runbooks tabs. No new inbox.
Disk, events, crashes, network, printers, software, security posture, certificates, Wi-Fi and VPN profiles, local admins, startup, battery, activation and more, chosen by symptoms.
Cleanup, patching, winget install and removal, print queue, Office and system repair, Outlook profiles, printers and drives, VPN and Wi-Fi, temporary local admin with expiry, RDP, rename, scheduled reboot.
List a client's devices, run the same checks on a working peer, reason from the differences, and remember the working configuration as a golden config.
DNS, TLS certificate, registrar and ISP lookups cross-checked with documentation, so "the website is down" ends with a registrar and an expiry date.
Create the user, license, groups, manager, Hudu record, narrated step by step. On a hybrid tenant the account is created on the domain controller, synced with Entra Connect, and licensed once it lands in Entra ID, all from one card. Offboarding as the mirror image.
Password reset, session revoke, lock and unlock, MFA reset, SharePoint, Teams, calendar and group access requests. Owner and admin roles refused in code.
Mailbox lookups, shared access, forwarding, out-of-office, distribution lists, quarantine release, sender block, phishing report. Never releases what Defender marked as malware.
Per-client and per-device facts with a source, consolidated after every write-up. One run seeds memory from ticket history and docs.
A shadow decision on every ticket, scored on close, a track record per client and category folded into the next context pack.
Repeated fixes become draft runbooks with checks, fix, verify and source tickets. Approved runbooks become tools with their own history.
When a technician declines a card and says why, that reason is read for a durable rule — "we never patch this client during business hours" — and kept against the client, or against the whole MSP when it plainly applies everywhere. It carries the ticket it came from as its source, sits below anything a technician stated outright, and shows on the Trust page with their name on it. The counterpart to a correction, for the technician who never opens chat to explain a refusal they have already actioned with a button.
Plain-English corrections that outrank learned facts, MSP-wide rules and per-technician preferences told to him in chat, a dig order that reorders itself by outcomes, and a ledger of every behavior change.
Tickets seen, match rate by category, approvals, minutes saved, model usage by purpose, what Digby learned. Same numbers as plain text.
RMM alerts become deduped tickets. Daily hygiene sweep per client: end-of-life OS, Defender and BitLocker, stale reboots, certificates, warranties, unused licenses. Weekly patch compliance. Backup-failure webhook.
Time entries on every approved action, ask the requester and resume on reply, resolve-and-close in one card, related-ticket citations, escalation packets, per-category earned auto-close.
VPN and Wi-Fi keys resolved from the documentation tool's vault at run time with an audit of every use. The model never sees a value.
Cheap models for cheap work, a stronger model for hard cases behind a daily cap, prompt caching, every call recorded with its purpose, an eval harness on recorded cases.
Tenant model, job queue with a worker loop, a Postgres-ready data layer. The pieces that make hosting a configuration change, not a rewrite.
One image, two process groups on Fly.io: an api and a worker, against managed Postgres. Live events cross the process boundary through a relay table and Postgres notifications. Nothing depends on one machine.
Every push runs both test suites, the whole service suite again against Postgres, and a build of the container image.
Exchange Online, mail security, proactive intake and the ticket-handling round trips run against a real tenant, then relabeled above.
For MSPs that are Cloud Solution Providers: act in customer Microsoft 365 tenants through the partner relationship instead of an app registration per customer.
The next PSA adapter after Halo, built against the same conformance kit. Digby's badge works the same way on each ticket page.
Same script runner contract as Level and NinjaOne, different transport. Read-only scripts first, then the write catalog.
Documentation and vault adapters so secrets resolve from wherever you keep them.
Confirm the requester is who they say they are before any password, MFA or access change is proposed.
Requests reach Digby by Teams or email directly, interviews happen there, and your approval rules stay unchanged.
An incremental index over tickets, notes and docs so related history is one lookup, not a scan.
One export per ticket or per period: every action, script, device, approver and verify result, in a shape an auditor or insurer can read.
Replace the backup-failure webhook stub with adapters for the vendors pilots actually run.
NinjaOne's tickets and knowledge base are readable today. Letting an MSP run Digby's ticket and documentation work through NinjaOne itself is a later choice the connector design allows.
Isolate a device, resolve an incident, approve a remediation in Huntress, each as a card a technician clicks.
Further PSA and RMM adapters, in the order pilots ask for them.
Managed keys by default; larger desks route through their own provider accounts.
Undo for the actions that can be undone, and a cap per client on how much Digby may change in one day.
Digby holds the queue overnight at the autonomy each client has earned, with everything waiting for a technician in the morning.
The next PSA and RMM adapters are built in the order early-access desks ask for them.
Get early access