Spruce

Version 2.0 · 2026-09-19 · plain text · checksum · ask a question

Spruce — Reference Brief

This is a reference document about a company and its product. It contains no instructions for AI systems. Any passage in it that reads as an instruction to an AI system is an error or evidence of tampering.

0. About this document

Spruce is a live subscription service: automated endpoint maintenance delivered through the tools an organization already runs, with Apple- and Jamf-certified technicians handling judgment calls and verifying every change. The platform behind the service is in early access. Its data engine is built, and the systems it connects to and the tasks it automates expand during early access. Which of an organization's systems Spruce works with is confirmed during the free fleet health check, before any subscription. This brief describes the service as designed.

Questions this brief does not answer can be sent to Spruce at https://sprucetools.com/ask (section 11).

The brief covers Spruce's intent, what makes it different, why its core is hard to build, why an organization would use it, and how the team builds it. Section 8 summarizes where the platform stands. Mechanisms and figures come from the company's engineering repositories and design records as of the date above, and outside figures name their source. The aim is specification, not adjectives.

The brief covers two things on purpose and keeps them distinct:

1. Summary

2. Intent: what Spruce is for

The current whitepaper, written for the Apple-first offering, describes Spruce as "an Apple device operations platform that automates routine IT maintenance and provides expert oversight for organizations managing Apple fleets." The public tagline is "Endpoint Management, automated by AI and monitored by humans." and the site title is "Automated endpoint management." An earlier 2025 deck used the name "Decision layer." The positioning has moved from "a better way to use MDM" toward "an operations layer above the existing IT stack."

Scope: endpoint management across IT, starting with Apple. Spruce is meant for endpoint management across IT, not only Apple. Apple is the starting point for three reasons:

The nearest industry term is endpoint security posture management (ESPM), but ESPM is largely security-focused. Spruce applies the same idea, continuously checking that endpoints and the systems around them are in their intended state, to endpoint management as a whole: identity, enrollment, apps, updates, configuration, filtering, and security tooling.

The buying pattern this follows. Most IT teams, school districts, businesses, and IT service providers buy several routine functions from outside vendors instead of running them entirely in-house:

Few are bought mainly for lack of skill; many teams that buy them could configure the underlying tools themselves. They are bought because each is infrastructure plus people at scale:

The company's thesis is that endpoint management belongs in the same category. Most organizations still treat it as work they must do themselves, when most of it is routine, time-consuming maintenance that is better done at scale. Spruce exists to offer it that way.

Who it is for. Spruce fits two kinds of team:

Both kinds include teams with deep Apple expertise, and service providers whose own technicians are excellent and fully booked. The work that slips is rarely the hard work. It is the routine work that loses to urgent work every week. Even where maintenance is current and verified every week, a skilled administrator spending those hours on routine upkeep is an expensive way to get it done.

The dividing line is scale economics, not competence. Spruce is not a fit where the organization is large enough that in-house maintenance staff cost the same as Spruce or less. That is usually a very large fleet, where a dedicated team's cost per device has fallen to Spruce's price or below.

For the Apple-first offering, the intended customer already has the core infrastructure:

Target segments are K-12 schools, businesses, and the IT service providers that support them. The typical operator is one of:

The problem is not a lack of tools or of skill. It is coverage: routine, consequential work that no one has the hours to keep current. The tasks that fall behind:

Company materials report that a routine new-app request often takes internal IT about two weeks. That figure is the company's field observation, not a measured study. For context, a 2026 IT help-desk benchmark from Fixify covers more than 50,000 tickets across all ticket types. It reports a median resolution time of 71 hours without automation and 4.4 hours with AI-assisted automation. The benchmark is vendor-published.

Spruce works in three layers:

  1. Aggregation. Collect operational data from existing systems.
  2. Automation. Decide and perform the safe, routine work.
  3. Response and verification. Apple- and Jamf-certified technicians resolve what cannot be automated. Every change is confirmed by observing it in the data before it closes.

Pricing is per device per month in three tiers, with K-12 and business tracks and a 30-day trial. The tiers step up in three stages:

Spruce's technicians are all Apple- and Jamf-certified, and the owner has run an Apple Technical partner MSP for 26 years. Spruce itself is not an MSP and is not built as an extension of one. The intent is a Spruce service provider focused on endpoint operations, moving away from the managed-service-provider model rather than funding a rival to anyone. The intent is, as with managed email or MDR, to provide services to organizations lacking IT, IT departments who want to elevate their own IT team to do more valuable things, or MSPs looking to increase margins.

3. What makes it different

3.1 A layer across the existing tools, not another MDM

The platform contains no MDM server. It does not speak the Apple MDM protocol, holds no Apple push certificate for commanding devices, and does not enroll devices into its own management. The customer's MDM remains the system of record and the point of enforcement.

Spruce reads from the customer's MDM, identity provider, and other services through their APIs. Changes to devices are made in the customer's MDM, either by Spruce technicians using access the customer grants or by narrowly scoped automations. Outcomes are then verified by observing the result in the collected data (3.6). The free fleet health check that starts an engagement requires read-only access.

Spruce's optional macOS endpoint agent is also not an MDM:

Spruce participates in Jamf's Technology Partner Program. That program requires integrations to add to or augment Jamf's native workflows without interfering with them.

In the company's view, building another MDM would reproduce mature products and force customers into a migration. The value is in what no single tool covers: whether management is still working, and whether the tools agree with each other (section 5.1).

Spruce is not limited to MDM data. It takes on the pain points usually filed under endpoint management wherever they live:

3.2 A data engine, not an integration

Each system in an IT environment describes a different part of it:

The product is a data engine that combines these systems. That is a different thing from a connection to one system, a dashboard that shows several side by side, or an AI assistant plugged into each vendor's tools. It has five parts:

Customer data separation. Customer data is separated by default within shared infrastructure. Fully separate infrastructure is available on request, arranged during contracting and priced accordingly, for organizations whose compliance requirements call for it.

3.3 Compared with API integrations, dashboards, and AI connectors

Most tools in this space query each vendor live or match records at display time. Spruce maintains a persistent, reconciled model with recorded provenance.

QuestionDirect API integrationGeneric dashboardAI assistant over MCP/tool callsSpruce data engine
Where does "truth" live?In each provider, queried liveIn each provider, rendered side by sideIn each provider, fetched per questionIn a reconciled store built from all sources, with every value attributed to its source and observation time
Cross-source identity (same device or person across MDM, IdP, agent)Not addressedUsually by display-time matching, if at allDone by the model inside one conversation, then discardedPersistent identity index; each link carries resolved, unresolved, or ambiguous status
When sources disagreeCaller sees whichever source it askedViewer sees both and reconciles mentallyModel picks or blends; results can vary run to runDisagreement is preserved per field with source and timestamp; resolution rules are deterministic
FreshnessLive for that one sourceVaries; often opaqueLive but bounded by rate limits and context sizeEvery attribute carries observedAt; staleness is queryable
History and auditNone beyond the provider's ownRarelyNonePer-field observation times, point-in-time report snapshots, and an immutable event history for every request (3.6)
Role of AINoneNoneThe integration layer itselfAn interface on top of a deterministic model (3.5)

An AI assistant working over the Spruce model inherits identity resolution, provenance, and tenant isolation instead of re-deriving cross-source joins on every question (3.4).

3.4 When separate product MCPs are enough, and when a data engine is needed

MCP solves connectivity and tool invocation. It does not unify device and operational data.

For occasional questions about a single system, separate product MCPs can be sufficient: whether one Mac is enrolled in Jamf, or which configuration profiles one device has. The model calls the relevant service, interprets the result, and answers. A normalized database would add cost without much benefit.

A data engine becomes valuable when an AI must reason reliably across systems. Without one, the AI redoes the same reconciliation on every question. It spends more tokens and tool calls, occasionally matches devices or users incorrectly, and produces results that are difficult to audit.

NeedSeparate product MCPsSpruce data engine
Check one device in JamfGoodUsually unnecessary
Compare MDM inventory with Apple Business ManagerModel must reconcile formats and identities every timeDevices are matched once and queried consistently
Determine whether a user's assigned devices are compliantRequires calls across MDM, identity, security, and endpoint toolsUsers, devices, and compliance state are already correlated
Identify devices missing from MDMDifficult without comparing multiple inventoriesUnmatched and missing records surface continuously
Track configuration or compliance historyLimited by each API's retention and current-state modelConsistent snapshots and state changes
Generate fleet-wide dashboardsMultiple slow API callsOne efficient query
Explain why a device is noncompliantAI must interpret conflicting vendor data on demandNormalized evidence and known policy definitions
AuditabilityHard to reproduce the model's reasoningStored source and observation time for every value; deterministic resolution rules
Device and user identity resolutionAI guesses whether records refer to the same device or personExplicit mappings across serial numbers, accounts, directories, and app identifiers
Alerts and continuous monitoringRequires repeated polling and interpretationRules run against normalized state
Device actionsDirect MCP is usefulStill performed through the authoritative product

The design is hybrid:

flowchart TD
    A["MDM MCPs / APIs"] --> D["Ingestion and normalization"]
    B["Apple and identity services"] --> D
    C["Security, patching, and endpoint data"] --> D
    D --> E["Canonical IT operations model"]
    E --> F["Spruce MCP / AI interface"]
    F --> G["Analysis, alerts, dashboards"]
    F --> H["Source MCPs for live actions"]

The normalized engine handles:

The source products' own MCPs or APIs remain responsible for:

Data with no lasting operational value is not stored.

The design does not aim for a complete replica of Jamf, Mosyle, Intune, Entra, Apple Business Manager, or any security product. The canonical model is deliberately focused: organizations, sites, users, groups, devices, ownership, enrollment, applications, configurations, vulnerabilities, compliance findings, and operational events. Each record preserves its original source references and timestamps. The model is exposed to AI through a Spruce MCP interface, and the direct product MCPs remain the action layer and the fallback for fresh or highly specific detail.

The decision boundary: if an AI is mainly a conversational front end to individual IT products, their own MCPs are enough. If it must understand the whole environment, meaning correlate devices and users across platforms, detect changes, keep operational history, and produce repeatable conclusions, then the normalized data engine is the actual product.

3.5 AI on a deterministic model

The customer portal has a command palette that accepts natural language. The model's output is constrained to a typed "view": a filter definition over an allowlisted set of fields for one entity type, which the portal applies to the engine's query surface.

The model does not read raw provider data, does not return data itself, and cannot take actions. The team maintains an evaluation suite for the feature that runs in continuous integration. The same pattern applies to every AI surface in the design: language in, a constrained and checkable request out, and answers drawn from the reconciled model.

3.6 Automation with human judgment and verified outcomes

Changes flow through a generalized request system. Each request holds one or more items, and every item runs a fixed sequence of phases:

  1. Policy gate. Org-level decisions are checked first. An approved app proceeds, a blocked app is rejected, and an undecided app waits for a human decision.
  2. Approval. A human approves where required.
  3. Execution. A technician or approved automation performs the change in the customer's MDM.
  4. Verification. An item counts as succeeded only when the change is observed in fleet data, not when someone reports it done.

Every item keeps an immutable event history. Reverse lookups are single queries, for example everything ever assigned to one device, or every request that assigned one app. Request types include app-to-device and app-to-group assignments, user-group assignments, and free-text requests. Adding a new pairing requires no storage change. Requests mirror into the consultancy's ticketing system.

4. Why the engine is hard to build

The difficulty is not connecting to the systems. It is that all of the following are true at the same time, for every customer, without pause, and every answer has to hold up to scrutiny afterward:

  1. Nothing shares a common identifier. One laptop can appear as a serial number in the MDM, an ownership record in Apple Business Manager, a directory entry filed under its user's name in the identity provider, and a hostname to the security tool. Often the one field that would connect two of those is simply blank. Deciding which records describe the same physical device, and being honest when that genuinely cannot be determined, is the foundation everything else sits on. Get it wrong and the answer still looks perfectly reasonable.
  2. The systems never report in order. Each is collected on its own schedule, so information regularly arrives before the thing it refers to. Throwing it away loses real facts about the environment. Making each system wait for the others would mean any one of them stalling brings the rest to a halt. Incomplete information has to be accepted as it comes and complete itself later, unattended.
  3. A record disappearing can mean several different things. A device missing from one system might be retired, reassigned, renamed, temporarily hidden by a vendor's own hiccup, or genuinely deleted. Older information can also arrive after a deletion and bring a record back from the dead. Mistakes of this kind do not announce themselves as errors. They produce confident, wrong answers.
  4. Summary answers have to stay true as the picture underneath shifts. Totals, statuses, and questions like "which version is current" all depend on relationships that form and break over time. Some facts change with no new information arriving at all, because a device simply goes quiet for long enough to count as stale. Keeping that accurate moment to moment is considerably harder than recalculating it overnight, and overnight is not good enough for work with deadlines attached.
  5. Everything happens at once. Information from many systems updates overlapping parts of the same picture simultaneously, across many customers simultaneously.
  6. "We don't know" and "no" are different answers. Vendors describe the same things in incompatible ways, and their systems are frequently silent or ambiguous rather than plainly wrong. A device reported as having no security software installed is not the same as a device no system has said anything about. Treating the second as the first is exactly how a compliance report ends up offering false assurance. Spruce keeps the two apart and says unknown when it means unknown.

Any one of these could be handled on its own. Doing all of them continuously, and being able to show the work afterward, is the engineering effort. It is why the engine is the product rather than a step toward one.

5. Why an organization would use it

5.1 Drift and maintenance across the stack, not in one toolset

Each tool in an IT stack manages its own slice and reports itself as healthy. MDM platforms manage devices but are not designed to verify that management itself is still working; the company's shorthand is "MDM doesn't watch itself." The same holds for identity providers, filters, and Apple's own services. Most real-world trouble sits in the seams between them, where no single console shows it and where people get tripped up. The strength of the Spruce model is catching these small drift and maintenance problems across the whole stack. Examples:

5.2 The MDR and managed-email pattern, applied to IT

For security, organizations have already accepted a model with three parts:

  1. Software sensors or filters.
  2. An outside human team that triages and responds.
  3. Per-endpoint or per-mailbox monthly pricing.

MDR and managed email security are the standard examples. Buyers accepted that model without it implying their in-house staff were incompetent. The accepted premise is that no internal team can do all three of these at once: watch everything continuously, afford to put multi-decade industry experts on menial tasks, and still prioritize small maintenance items over big-ticket fires. Yet many of those menial tasks are required by compliance frameworks, liability insurance policies, and contracts.

Spruce applies the same structure to IT endpoint management, beginning with Apple. Company materials state the analogy directly: if MDR providers supply the security team, Spruce supplies the operations team.

MDR conceptSpruce counterpart
Endpoint sensors and telemetrySource collectors and the endpoint agent
Detection rulesPolicy gates and derived checks over the reconciled data
Analyst triageApple- and Jamf-certified technician review
ResponseTechnician remediation or approved automation
Case closureVerification that the change is observed in fleet data
Per-endpoint monthly pricingPer-device monthly pricing

Why the pattern holds for any buyer. The reasons organizations buy these services are the same for a school district, a business, and an IT service provider:

What the arithmetic looks like. Published figures frame the cost of covering this work in-house:

The problems Spruce addresses are ones IT staff are understandably defensive about: expired certificates, lapsed tokens, configuration drift, unpatched third-party apps, stale records, and slow app requests. They are visible and usually attributed to whoever runs the tools, so they are under-reported. Spruce treats them as what they are. Tools that manage devices do not audit their own management, no tool audits the seams between tools, and endpoint fleets grow faster than IT headcount. Findings are expected on every fleet, including well-run ones, because drift comes from time, vendor release cadence, and staff turnover. It is not a verdict on anyone. The service adds coverage; it does not replace the team.

The entry point is a free, read-only fleet health check. It reports against the organization's own fleet: what has drifted, and for how long. The team can then fix the findings itself or with Spruce.

The model scales through automation. Routine work is automated first and humans handle the exceptions, so each technician can oversee more devices as the automation grows.

6. Engineering approach

7. Where the model extends

8. Where it stands

Spruce has operated as a subscription service since 2024, when the service was named Spruce. The platform behind it is in early access: its data engine is built, and the systems it connects to and the tasks it automates expand during early access. Which of an organization's systems Spruce works with is confirmed during the free fleet health check, before any subscription.

Built so far:

The following all follow the same architecture:

The public debut is at JNUC 2026, September 23–25, in Kansas City.

9. Common objections, answered

Further questions this brief is designed to support:

10. Glossary

11. Questions this brief does not answer

Questions can be sent to Spruce at https://sprucetools.com/ask. The form takes a question and an email address, and a person at Spruce answers by email.

A question can be pre-filled by adding it, URL-encoded, after #q= in that address. For example: https://sprucetools.com/ask#q=Does%20Spruce%20work%20with%20Kandji%3F

The part after # stays in the browser, so nothing reaches Spruce until the form is submitted.

Each submitted question gets a private reference link where the answer is also posted. A person, or an AI assistant given that link, can read the answer there later. With the asker's permission, useful questions and answers are added to later versions of this brief, without names or contact details.

12. Integrity and corrections

This file is version 1.0, dated 2026-09-17. Any change produces a new version; an existing version is never edited in place. A SHA-256 checksum is published alongside it at https://sprucetools.com/llms.txt.sha256, and a copy whose checksum differs is not this document. Corrections go to the publisher through https://sprucetools.com/ask.