Enterprise Desktop Agent Knowledge Graphs 2026

See also (wiki): wiki/enterprise-knowledge-curation.md · wiki/enterprise-agent-runtime-infrastructure.md · wiki/agent-identity-permissions.md · wiki/mcp-security-governance.md · wiki/agentic-ai-governance.md · wiki/ai-platform-selection.md

Status: source-backed synthesis plus architecture inference. The current public record is uneven: Amazon Quick is explicitly reported as building a per-user knowledge graph; Microsoft Scout is reported as using Microsoft workspace context/Work IQ-style grounding; Claude Cowork is reported as a connector/plugin enterprise work layer; Codex Desktop is officially documented around code tasks, local configuration, telemetry, and audit rather than a general corporate knowledge graph. Where vendors do not publish schemas or export contracts, this page labels conclusions as architecture implications.

Executive Summary

The 2026 enterprise assistant race has moved from chat boxes to persistent work agents. Amazon Quick, Microsoft Scout, Claude Cowork, and Codex Desktop all attach large models to tools and context, but they differ sharply in where context lives and how it can be governed.

Amazon Quick is the clearest public example of a cross-application desktop assistant with an explicit per-user knowledge graph. Public reporting says it connects local files, email, calendars, Google Workspace, Microsoft 365, Slack, Zoom, Salesforce, browser workflows, and developer tools such as Kiro CLI and Claude Code.

Microsoft Scout is the Microsoft 365-native version of the always-on assistant. Public reporting says Scout reads Teams, Outlook, calendar, road-traffic, files, and transcripts in the background; starts as a desktop preview; and is intended to become a cloud always-on assistant. Its likely advantage is permission fidelity inside Microsoft 365, Purview, Defender, Agent 365, and Microsoft identity.

Claude Cowork is better understood as an enterprise agent front door with connectors and plugins. Its differentiator is extensibility through Claude, MCP, and role-specific plugins across finance, legal, sales, HR, design, and operations. Public reporting emphasizes company context and downstream app action more than an explicit graph data model.

Codex Desktop is technically different: it is a software-engineering agent. It has local and cloud task state, repository understanding, terminal/test feedback, telemetry, and audit surfaces. Its memory is a repo/session/task graph, not a general employee knowledge graph.

The enterprise conclusion: do not let each assistant build an incompatible private memory layer. Build or buy a governed firm context graph with policy-controlled retrieval, then let Quick, Scout, Cowork, Codex, and future agents act as clients of that graph.

Product Comparison

Hard Technical Differences

1. Observation Layer

Desktop agents can observe local context that browser-only agents cannot:

• file paths and selected local files;
• active applications and window context;
• local notifications and calendar state;
• local browser automation state;
• shell or developer-tool sessions when integrated;
• OS-level identity and device posture signals.

Browser agents are easier to sandbox because their observation layer is mostly DOM state, session cookies, downloads, and browser permissions. They are weaker for “know my workday” workflows because they cannot naturally see local files, non-browser apps, or background work signals without helper processes.

Cloud agents are best for persistence, scheduled work, fleet management, and centralized governance. They require connectors or desktop clients to ingest local context. The likely durable pattern is hybrid: desktop client for local observation and user approvals, cloud service for persistent memory and scheduled work, browser automation for SaaS tasks, and governed connectors for enterprise systems.

2. Memory Layer

The phrase “knowledge graph” is doing different jobs across these systems:

• Amazon Quick: reported as an explicit per-user graph over work preferences, team contacts, and business context.
• Microsoft Scout: likely grounded in Microsoft 365’s existing work graph plus Work IQ/Microsoft IQ context, but public reporting does not prove a portable user-editable graph schema.
• Claude Cowork: connector/plugin context layer; graph-like retrieval may exist internally, but public reporting does not expose it as the product’s central abstraction.
• Codex Desktop: code/task graph, not corporate memory. It learns the repo by reading files, running commands, observing failures, and patching.

This matters because “memory” can mean any of four different stores:

1. Retrieval index: chunks, vectors, permissions, citations.
2. Semantic graph: people, teams, projects, documents, systems, decisions, tasks, and edges.
3. Procedural memory: skills, workflows, prompt packs, runbooks, tool recipes.
4. Agent state: session history, goals, approvals, tool calls, failures, and local logs.

Enterprises need all four, but they should not be collapsed into one opaque vendor memory.

3. Action Layer

Quick and Scout are personal-work agents. They are designed to draft, schedule, summarize, remind, fill forms, automate browser tasks, and move across office systems.

Cowork is an agent/workflow layer. It is stronger where an enterprise can package role-specific workflows and connectors, for example finance analysis, legal review, HR workflows, design operations, or sales research.

Codex is a repair loop. It can read a codebase, change files, run tests, observe errors, and iterate. Its correctness loop is unusually strong because code has executable feedback. That gives Codex a harder verification surface than general knowledge work, where “good answer” often depends on context and human judgment.

4. Governance Layer

The governance difference is not just “who has better security.” It is where enforcement lives:

• Inside prompt or tool instructions: weakest. Prompt injection can influence the policy.
• Inside connector permissions: better. Source system ACLs constrain retrieval/action.
• At runtime gateway/policy layer: stronger. Access control sits outside the agent’s reasoning loop.
• At identity and audit layer: necessary. Each agent action needs actor, user, source, tool, target, approval, and evidence.

Microsoft’s public Scout reporting emphasizes sandboxing, treating OpenClaw as untrusted, and wrapping with Agent 365, Purview, and Defender. Codex official docs expose telemetry and audit surfaces. Quick public reporting emphasizes cross-app reach and personal graph, but the public record is thinner on graph export, graph correction, and admin audit contracts.

How A Real Enterprise Knowledge Graph Should Work

An enterprise assistant graph should not be a hidden chat-memory blob. It should be a typed, evidence-backed graph.

Core Entity Types

Core Edge Types

Provenance Fields

Every graph edge that can influence an agent action should carry:

• source system and source URL/path;
• timestamp observed;
• connector or ingestion job;
• permission scope inherited from the source;
• confidence score;
• owner;
• expiry or review date;
• last user correction;
• whether it is explicit evidence or model-inferred.

Without provenance, the graph becomes a hallucination amplifier.

How It Learns

Enterprise assistants learn from five loops:

1. Connector ingestion: documents, emails, chats, meetings, tickets, CRM records, repos, dashboards.
2. Interaction feedback: accepted drafts, rejected suggestions, edited emails, ignored reminders, approved tool calls.
3. Workflow repetition: recurring sequences of tools and documents become procedural memory.
4. Correction events: users merge entities, delete stale facts, mark canonical pages, or correct ownership.
5. Outcome validation: tasks completed, tests passed, customers answered, incidents avoided, tickets resolved.

The safe design is structured memory updates, not silent per-user fine-tuning. The assistant should propose memory patches and let users or admins approve the patches when they affect shared knowledge.

How It Fixes Knowledge

Knowledge correction needs to be a first-class workflow:

1. Detect conflict: two pages name different owners, two systems disagree on deadline, or a user rejects a recurring suggestion.
2. Classify the issue: stale fact, duplicate entity, wrong edge, missing owner, superseded decision, bad source, privacy problem.
3. Create a graph patch: add, delete, merge, supersede, or lower confidence.
4. Route for approval when the fact is shared beyond the individual.
5. Re-run retrieval golden questions that depend on the changed fact.
6. Write an audit record: who changed what, why, based on which evidence.

This is the difference between “memory” and enterprise knowledge management. A memory can update silently. A firm graph needs versioning and review.

Sharing Knowledge Across The Firm

Do not share every user’s personal graph. Use layered graphs:

The promotion rule is critical. “I prefer concise emails” should stay personal. “The finance close workflow owner is Alice” can become team or firm knowledge only if backed by source evidence and owner review.

Reference Architecture

Desktop / Browser / Cloud Agents
        |
        v
Policy-controlled Context API
        |
        +-- permission resolver (identity, group, source ACLs)
        +-- retrieval router (vector, lexical, graph, structured DB)
        +-- provenance filter (source, timestamp, confidence, owner)
        +-- action gateway (tool scope, approvals, rate limits)
        |
        v
Firm Context Layer
        |
        +-- personal graph store
        +-- team graph store
        +-- firm canonical graph
        +-- vector indexes
        +-- document/raw source vault
        +-- workflow/skill registry
        +-- audit/event warehouse

This architecture makes vendor agents replaceable. Quick, Scout, Cowork, Codex, and future tools can request context through the same policy boundary instead of each accumulating private, unreviewable memory.

Procurement Questions

Ask vendors:

1. What is the graph schema, and can customers export it?
2. Can users view and correct facts the agent has learned?
3. Are personal memories separated from team and firm memory?
4. Does every retrieved fact preserve source permissions?
5. Can admins set retention, deletion, and legal-hold policies?
6. Can graph updates be versioned and audited?
7. Can the assistant abstain when graph evidence is weak or conflicting?
8. Can corrections trigger retrieval regression tests?
9. Can the product use an external firm context graph instead of only its own memory?
10. Are tool/action permissions enforced outside the model prompt?

Implications For The State Of AI Corpus

This topic should be tracked as an ingestion lane under agent frameworks and enterprise knowledge curation:

• product launches and public docs for Quick, Scout, Cowork, Codex Desktop, Gemini Spark, Perplexity/Comet-style browser agents, and enterprise AI browsers;
• graph/memory export and correction contracts;
• desktop vs browser vs cloud action surfaces;
• MCP/tool security and supply-chain risks;
• runtime policy enforcement and audit logging;
• GraphRAG and distributed graph retrieval patterns for permissioned enterprise knowledge.

Supporting Research

• sources/19-agent-frameworks/enterprise-desktop-agent-knowledge-graphs-2026-raw.md — source ledger for Quick, Scout, Cowork, Codex Desktop, MCP risk, and graph-agent research.
• research/19-agent-frameworks/desktop-agent-observability-2026.md — local state, telemetry, and export gaps for desktop agents.
• research/19-agent-frameworks/aws-graphrag-evaluation-toolkit-2026.md — AWS GraphRAG and evaluation tooling for graph-backed retrieval and regression tests.
• research/19-agent-frameworks/aws-agentcore-enterprise-runtime-2026.md — managed agent runtime, policy gateway, identity, memory, tools, observability, and evaluation.
• wiki/enterprise-knowledge-curation.md — distinction between search, memory, curation, canonical knowledge, and golden retrieval tests.
• wiki/mcp-security-governance.md — MCP governance and tool-risk boundary.