Six Intelligence Daemons, One Very Busy Mac

Tahoe can light up a small fleet of “intelligence” processes after an update. Here is what each one actually does, how I separate useful background work from a stuck loop, and why deleting its database usually buys you more work.

By CoreGuard · Jul 11, 2026 · 11 min read

What is intelligenceplatformd?

intelligenceplatformd is an Apple system daemon that builds and serves a general-purpose knowledge graph representing the device and user. On macOS Tahoe it works with knowledgeconstructiond; high CPU usually means content analysis or graph maintenance, although a sustained workload that never trends down can indicate a stuck job.

That definition comes from Apple’s own intelligenceplatformd(8) man page shipped inside macOS, not from a utility vendor reverse-engineering a process name. The same page is dated June 6, 2022, which matters: this machinery predates the public Apple Intelligence brand.

So the first correction is simple. Seeing intelligenceplatformd does not mean Siri is secretly running a large language model at full throttle. It means a long-standing macOS knowledge service is alive. Tahoe has connected more “intelligence” features to that plumbing, but Activity Monitor is showing implementation names rather than a tidy product diagram.

The six daemons are related, not interchangeable

Apple ships local man pages for all six processes in this family. Tahoe 26.5.2’s launch manifests add useful detail about the services each daemon exposes.

| Process | What Apple documents | What that means in practice | |---|---|---| | intelligenceplatformd | Builds and queries a general-purpose knowledge graph representing the device and user | It is the graph’s service layer: other operating-system components ask it for structured knowledge | | knowledgeconstructiond | Performs heavier content processing with intelligenceplatformd to generate the graph | This is the bulk builder; Tahoe’s manifest labels its full pipeline resource-intensive and schedules it for external power | | intelligenceflowd | Manages sessions, communication, and state between clients and backend intelligence services | It orchestrates sessions rather than building the database; its Tahoe services include orchestration, tools, snippets, and transcript-entity queries | | intelligencecontextd | Retrieves contextual information about the user and device state from multiple sources | It brokers context for intelligence sessions, including UI context according to its Tahoe manifest | | generativeexperiencesd | Powers on-device generative experiences such as summarization and text composition | Tahoe exposes services for summarization, classification, composition, availability, and generative sessions | | naturallanguaged | Handles post-editing requests from applications that need user text checked | It is a text-service daemon, not proof that Apple Intelligence itself is active |

The distinction prevents a lot of bad troubleshooting. Killing intelligenceflowd because Graph.db is growing targets the session broker rather than the graph builder. Blaming naturallanguaged for every language-related task confuses one documented post-editing service with Apple’s entire Natural Language stack.

It also explains why several names can appear together. A client requests an intelligence operation; the flow daemon coordinates it, the context daemon supplies relevant state, generative services handle supported composition or summary work, and the knowledge-graph pair maintains queryable context. That is a plausible pipeline, not six copies of one rogue program.

Apple does not publish a complete request-by-request architecture for these private frameworks. The table reflects the shipped man pages and launch manifests; it does not claim that every internal call or data source has been publicly documented.

Why Tahoe gets busy after an update

Apple Support’s July 7, 2026 “How to get Apple Intelligence” article says on-device models begin downloading after a software update and lists a reported 7 GB device-storage requirement. That figure is a free-storage requirement; Apple never promises that every update downloads exactly 7 GB.

Tahoe’s own manifests show more moving parts. generativeexperiencesd has post-install availability tasks. knowledgeconstructiond has a resource-intensive full pipeline, while intelligenceplatformd subscribes to changes involving contacts, Photos feedback, locations, media activity, and other system events on the Tahoe 26.5.2 test installation.

My inference is that an update can invalidate or refresh several layers at once: model availability, feature eligibility, framework data, and parts of the local knowledge graph. That makes a burst of CPU, disk reads, and database writes plausible. It does not prove that every multi-hour spike is healthy.

“Post-update indexing” is useful shorthand, but it can hide different jobs. Spotlight, Photos analysis, model downloads, and IntelligencePlatform graph construction may overlap. The process name tells you who is consuming resources now; it does not tell you which upstream change started the work.

Settling versus stuck: watch the shape, not one number

I do not use a magic CPU threshold. A process can use a full core briefly and be behaving perfectly. It can also sit at a modest percentage for hours, wake the Mac repeatedly, and cost more battery than the dramatic burst.

I look for a trend.

A settling workload has a reason to exist: a recent Tahoe update, a large account sync, a restored Mac, or a substantial change to Photos, Mail, Contacts, or other indexed data. CPU and Energy Impact rise, useful work appears to progress, and both decline across later observation windows. The Mac remains usable, and the same peak does not immediately return after every idle period.

A probably stuck workload has a different shape: the same daemon repeatedly climbs without any new input; CPU or disk activity fails to trend down across multiple plugged-in, idle observations; the Mac stays hot or loses meaningful battery; or Activity Monitor samples repeatedly show the same tight call path. Crashes, repeated relaunches, or an ever-returning error are stronger evidence than a scary percentage.

My practical window is two observations of at least 30 minutes each. That is a diagnostic heuristic, not an Apple threshold. I record the process, CPU, elapsed runtime, Energy Impact, and whether the number is falling. If the second window looks like the first, I keep investigating. If it is clearly tapering, I leave the system alone.

Start with read-only evidence:

sw_vers

ps -Ao pid,%cpu,%mem,etime,comm | \
  grep -E '(intelligenceplatformd|intelligenceflowd|intelligencecontextd|generativeexperiencesd|naturallanguaged|knowledgeconstructiond)$'

Then use Activity Monitor’s CPU pane and search for the exact process. Apple documents a CPU History window (under the Window menu) and a three-second Sample Process report under Activity Monitor’s More button. A sample is not a verdict, but repeated samples can distinguish changing work from one loop doing the same thing forever.

Graph.db is an index, not a suspicious download

The knowledge graph lives under ~/Library/IntelligencePlatform/, with Graph.db as the filename people notice. Apple’s intelligenceplatformd(8) page says the graph represents the device and user, while Apple’s privacy page says Apple Intelligence is grounded in your personal context, aware of personal information via on-device processing.

Treat that directory accordingly. Do not dump the database into a forum post to prove it exists. Size and modification times are enough for this diagnosis:

du -sh "$HOME/Library/IntelligencePlatform" 2>/dev/null

stat -f '%N  %z bytes  modified %Sm' \
  "$HOME/Library/IntelligencePlatform/Graph.db" 2>/dev/null

If macOS returns Operation not permitted, stop there. That is a privacy boundary at work; it says nothing about whether the database is damaged.

Deleting the file is seductive because it produces an immediate result: the large file disappears. It does not remove the reason the graph exists. In a January 31, 2024 Apple Support Community thread, one M1 MacBook Air owner reported a database over 4 GB and said it rebuilt after deletion. Another participant in that thread reported only 3.5 MB on their Mac. Neither number is universal.

The rebuild is the catch. Apple documents knowledgeconstructiond as the component performing heavy processing to generate the graph. If the OS still needs the graph, removing its store gives that builder an empty assignment sheet. More CPU and disk activity are the predictable result; that connection is an inference from Apple’s documented roles plus the user’s rebuild report.

A genuinely corrupt database is a different case, but deletion should not be the opening move without a backup and a Tahoe-specific support procedure. As of July 2026, Apple documents no supported reset procedure for IntelligencePlatform; the supported paths are the Apple Intelligence switch and Apple Support.

Why bulk disable scripts are a bad experiment

The “Disable Tahoe Bloatware” gist is public, direct, and at least honest enough to warn readers not to use it unchanged. Its artifact says disabling System Integrity Protection is required, attempts to unload a broad collection of unrelated Apple services, and hard-codes the GUI user domain as 501.

That is not a controlled test of intelligenceplatformd. It changes dozens of variables while reducing a major macOS safeguard. If the Mac behaves differently afterward, you have learned almost nothing about which change mattered.

The gist’s own comments show the trouble. On November 9, 2025, one Tahoe VM user reported that disabling IconServices components produced high CPU in Finder and iconservicesagent, with their DTrace interpretation pointing to repeated icon regeneration. On November 10, that user reported that re-enabling related Quick Look agents had not resolved the issue. This was one VM with other configuration changes, and it was not an IntelligencePlatform test. It is still a concrete example of disabling a dependency creating more background work.

On July 6, 2026, another commenter reported that the script did not work on their Tahoe installation because the targeted services remained running. That is one machine, not proof of a universal Tahoe rule. It is enough to show that “disable the plist and the process is gone” is not dependable advice.

If you want Apple Intelligence off, Apple’s supported route is System Settings → Apple Intelligence & Siri → turn Apple Intelligence off. Apple Support reported on July 7, 2026 that doing so removes the downloaded on-device models.

That setting still does not promise the disappearance of every process with “intelligence” in its name. intelligenceplatformd has a broader operating-system role documented since 2022. A supported feature toggle and a process kill list are different things.

Measure energy before you assign blame

CPU is only one cost. For a battery complaint, I care more about sustained energy and wake behavior than the highest number in a sorted CPU column.

Apple describes Activity Monitor’s Energy Impact as a relative current measure, not watts. On Mac laptops, its “12hr Power” column is the average Energy Impact over the previous 12 hours or since startup, whichever is shorter. That longer view is more useful than catching intelligenceplatformd at the top of one refresh.

Sort the Energy pane, record the leading app or process, and compare it with the CPU view. Do not assume the daemon is the root cause just because it is visible. Photos, Mail, a browser, a sync client, and the graph service can all be working on the same changed data. The loudest process may be the last stage, not the trigger.

This is where per-app energy history earns its keep. A trend can answer “what changed after the update?” A snapshot can only answer “what is busy this second?”

What CoreGuard will show—and what it will not

This problem is exactly the kind of ambiguity I am building CoreGuard to make legible. The app observes and explains; it does not alter Apple’s databases, disable system services, or declare a daemon “stuck” from one sample.

Free includes live CPU, GPU, RAM, temperature, and fan readings; basic history of those readings; threshold alerts; menu-bar visibility; and plain-English naming of the top app or process using the Mac. Every danger warning remains free. If disk writes jump abnormally, seeing that warning and the responsible process is free too.

The word “history” needs precision. Free has basic reading history and threshold alerts. Pro adds the detailed per-app write timeline, longer trend history, CSV/JSON sensor-log export, and per-app energy analytics. Pro also includes detailed SSD endurance data such as TBW, power-on hours, raw SMART fields, and an honest wear projection; it never predicts an exact failure date.

CoreGuard does not inspect the private contents of Graph.db. It cannot prove why Apple scheduled a particular private-framework task, and it is not a substitute for an Apple engineer reading a sysdiagnose. Its useful job is narrower: show that knowledgeconstructiond rose after an update, that the workload tapered—or did not—and what happened to temperature, energy, and writes while it ran.

CoreGuard is local-only and makes zero network connections. It is pre-launch for macOS 13 and later on Apple Silicon and Intel, and will ship as a Developer-ID signed and notarized .dmg. Pro is listed at $29 one-time, not a subscription.

For now, the honest CTA is to get notified and check the pricing page. Whether you ever install CoreGuard or not, keep the diagnostic rule: observe a trend before changing the machine. A daemon name is a clue — the verdict has to come from the trend.