Executive Summary
Amazon Quick, Microsoft Scout, Claude Cowork, and Codex Desktop point to the same next platform fight: who owns the working memory of the firm?
The shift is larger than “AI assistant in an app.” These systems are moving toward persistent work agents that can observe context, retrieve internal knowledge, automate tasks, and remember enough about a user or workflow to act again tomorrow. That makes the knowledge graph boundary a procurement issue, a security issue, and an operating-model issue.
The wrong answer is letting every assistant build its own private memory silo. The right answer is a governed enterprise context layer: personal memory stays personal, team knowledge is promoted with review, firm knowledge is canonical and source-backed, and every agent retrieves through policy-controlled APIs.
Technical appendix: Enterprise Desktop Agent Knowledge Graphs 2026. Source ledger: enterprise-desktop-agent-knowledge-graphs-2026-raw.md.
Four Products, Four Memory Shapes
| Product | What it is becoming | Memory shape |
|---|---|---|
| Amazon Quick | Cross-vendor desktop work assistant | Reported per-user knowledge graph over work context, preferences, people, and connected apps |
| Microsoft Scout | Microsoft 365-native always-on assistant | Microsoft work context through Teams, Outlook, calendar, files, transcripts, and Work IQ-style grounding |
| Claude Cowork | Enterprise workflow and connector layer | Company context assembled through connectors, plugins, MCP tools, and role-specific workflows |
| Codex Desktop | Software engineering repair loop | Repo, session, task, shell, test, approval, and local telemetry state |
The products overlap, but they do not solve the same problem.
Quick and Scout are aimed at personal work orchestration. Cowork is aimed at role-specific enterprise workflows. Codex is aimed at codebase change and verification. The technical mistake is evaluating them as interchangeable chatbots. The harder question is what memory each one accumulates, who can correct it, and whether the firm can reuse that knowledge outside the vendor’s product.
Desktop Is Different From Browser
Browser agents are easier to sandbox. They see pages, cookies, DOM state, downloads, and the web apps they are allowed to touch.
Desktop agents can see more of the work surface:
- local files;
- app focus and window context;
- notifications and calendars;
- browser state plus native app state;
- shell sessions and developer tools;
- device and local identity signals.
That makes desktop agents more useful for “know my workday” workflows. It also makes them more dangerous. The access boundary is no longer just a SaaS connector. It is the employee’s working environment.
The Knowledge Graph Should Not Be A Hidden Chat Memory
A firm-grade agent graph needs typed entities, typed relationships, provenance, and review.
Core entities should include people, teams, projects, customers, documents, meetings, decisions, systems, tasks, policies, and preferences.
Core relationships should include ownership, dependencies, approvals, supersession, mentions, blockers, evidence links, entity merges, and review dates.
Every important edge needs provenance:
- where it came from;
- when it was observed;
- which connector or ingestion job found it;
- which permissions apply;
- how confident the system is;
- who owns it;
- when it expires or needs review;
- whether it was explicit evidence or model inference.
Without this, “memory” becomes an authority laundering mechanism. The agent starts repeating stale or inferred facts as if they were corporate truth.
How It Should Learn
Enterprise assistants should learn through structured memory patches, not silent model personalization.
Useful learning signals include:
- documents, chats, meetings, tickets, CRM records, dashboards, and repos;
- accepted drafts and rejected suggestions;
- edits users make to generated work;
- repeated workflows;
- explicit corrections;
- task outcomes such as tests passed, tickets resolved, or approvals completed.
The system should turn those signals into proposed updates: merge these two entities, lower confidence on this owner, mark this decision superseded, promote this workflow to the team graph, add a review date to this policy.
Some updates can stay personal. Shared knowledge should require source evidence and review.
How It Should Fix Knowledge
The correction loop is the part most vendors under-explain.
A real firm graph needs to detect conflicts, classify the problem, create a patch, route shared changes for approval, re-run retrieval tests, and preserve an audit record.
Examples:
- Two pages name different owners for the same system.
- A sales deck says one pricing rule, but the contract template says another.
- A project moved teams, but the assistant still routes questions to the old owner.
- A user repeatedly rewrites the same kind of draft, signaling a preference the assistant has not captured.
- An agent cites an obsolete policy because the graph has no supersession edge.
This is not just “better search.” It is knowledge operations.
How To Share It Across The Firm
Do not share every user’s personal graph. Split the graph into layers.
| Layer | What belongs there | Rule |
|---|---|---|
| Personal graph | preferences, routines, private drafts, local habits | Private by default |
| Team graph | project ownership, team workflows, shared decisions | Promote with team visibility and source ACLs |
| Firm graph | canonical policies, systems, org structure, approved processes | Govern centrally with evidence and owners |
| Derived graph | inferred blockers, stale pages, likely owners | Confidence-scored and reviewable |
| Audit graph | accesses, tool calls, approvals, evidence used | Security and compliance surface |
The promotion boundary matters. “I prefer short email drafts” should not become firm knowledge. “The finance close workflow owner is Alice” can become shared knowledge only if there is a source and an owner.
The Procurement Test
Ask every desktop or enterprise agent vendor:
- Can we export the memory or graph?
- Can users see and correct what the agent has learned?
- Are personal, team, and firm memories separated?
- Does every retrieved fact preserve source permissions?
- Can shared knowledge changes be approved and audited?
- Can stale facts expire automatically?
- Can corrections trigger retrieval regression tests?
- Can the product use our firm graph instead of only its own private memory?
- Are tool permissions enforced outside the model prompt?
- What happens when two connected systems disagree?
If a vendor cannot answer those questions, the product may still be useful, but it should not become the firm’s canonical memory layer.
The Operating Model
The durable architecture is not one agent to rule the company. It is a governed context layer that many agents can use.
Desktop, browser, cloud, and coding agents
|
v
Policy-controlled context API
|
+-- identity and permission resolver
+-- vector, lexical, graph, and structured retrieval
+-- provenance and confidence filters
+-- action gateway and approval checks
|
v
Firm context layer
|
+-- personal graph
+-- team graph
+-- canonical firm graph
+-- raw source vault
+-- workflow and skill registry
+-- audit warehouse
That keeps Quick, Scout, Cowork, Codex, and whatever comes next from becoming mutually incompatible knowledge islands.
The strategic question for firms is simple: are agents allowed to remember your organization however they want, or do they have to learn through your governed knowledge system?