Beyond enterprise chat
Enterprise AI products are converging on a familiar shape: bring company data, talk to models, invoke tools, generate outputs. But the long-term opportunity is not a better enterprise chat interface. The more important product is a multiplayer operating system for humans and agents working together on shared, versioned enterprise state.
Created Aug 21, 2026
Most enterprise AI products follow one interaction model: the user asks, the model retrieves context, optionally invokes tools, and returns an answer or a document. Useful, but it treats AI work as a sequence of isolated conversations.
Real enterprise work is different. It is collaborative, long-running, permission-sensitive, iterative, asynchronous, distributed across people and systems, dependent on durable shared state, and subject to audit, compliance, review, and approval. A chat transcript is not a sufficient abstraction for that work.
The next generation should evolve from AI that answers questions about enterprise data to an environment where humans and agents continuously collaborate on enterprise work.
In that environment, chat is only one interface. Documents, analyses, plans, code, dashboards, and workflows are persistent artifacts. Humans and agents collaborate on the same artifact. Every change is versioned and attributable. Permissions extend to agents, tools, and individual actions. Long-running work can be inspected, redirected, paused, or resumed.
The core primitives are not messages. They are users, agents, skills, tools, tasks, artifacts, versions, permissions, events, branches, and enterprise objects. Five of them carry most of the weight:
A reusable package of instructions and context describing how a type of work should be performed: procedures, examples, templates, evaluation criteria, domain vocabulary, constraints. Skills are installable, versioned, permissioned, testable, and publishable inside the enterprise. Skill libraries form around recurring work: legal review, incident analysis, hiring debriefs, financial planning.
An execution entity: model plus instructions, context, skills, tools, memory, runtime, permissions, and budget. It performs multi-step work toward an objective. Skills and agents are separate concepts; a skill is knowledge, an agent is the worker that applies it.
A specific invocation of an agent, with durable identity and state: objective, inputs, permissions, budget, schedule or trigger, checkpoints, outputs, execution history. Tasks can be scheduled, event-triggered, dependent on other tasks, paused for approval, resumed, and reassigned.
The durable output being created or modified: a memo, an analysis, a contract review, a plan, a dashboard, a dataset. The artifact, not the conversation, is the primary object; the conversation is one of several ways to interact with it. Every meaningful write produces a new immutable version.
A governed capability with declared objects, actions, scopes, ownership, data classification, approval requirements, side effects, and reversibility. Authorization layers from organization to workspace to session to user to agent to the specific invocation.
The features being shipped today, more file types, more connectors, more models, matter but are incremental. The larger opportunity is becoming the environment where enterprise work itself is represented and coordinated. That means moving:
| From | To | What changes |
|---|---|---|
| Chat sessions | Shared workspaces | The workspace holds persistent agents, artifacts, tasks, context, and collaborators. |
| Generated answers | Versioned artifacts | Every meaningful output becomes durable, editable, attributable, and composable. |
| Individual prompting | Multiplayer collaboration | Multiple humans and agents work simultaneously without losing control or history. |
| Broad connector access | Policy-aware capabilities | Every agent action is evaluated against user authority, session policy, tool scope, and resource sensitivity. |
| Opaque runs | Inspectable execution | Users observe progress, redirect work, approve actions, and preserve intermediate results. |
| Prompt libraries | Skill ecosystems | Reusable, versioned skills become organizational assets. |
| Isolated APIs | An enterprise ontology | Tools and data sources map into shared objects, relationships, and policies. |
| One-shot automation | Durable tasks | Work can be scheduled, resumed, reviewed, and triggered by enterprise events. |
What the environment has to get right, distilled from the full thesis.
Reverse the chat-first relationship. Users select a section and prompt against only that section, work manually while an agent works elsewhere, inspect the sources behind a change, compare versions, branch, merge, restore, and delegate different sections to different agents.
The authorization question is no longer "can this user access this resource." It is "can this user, through this agent, using this tool, perform this operation on this resource in this session." A Zanzibar-style relationship model computes an effective capability for the full tuple. Policies keep it livable: always allow reads from approved sources, require approval for external writes, require human confirmation for destructive or irreversible actions.
Every change, by a person, an agent, a workflow, or an external tool, produces a version with metadata: author, initiating user, prompt, model, tools invoked, sources, sections affected, patch, cost, approvals. The product idea is not "put Git in a document editor." It is bringing the safety, traceability, and parallelism of version control into collaborative knowledge work, without exposing Git's complexity.
Private exploration and shared progress are both real needs. Branch from the shared artifact, work manually or with agents, compare, submit selected changes, merge automatically where possible. The merge unit is logical structure, document to section to block to statement, not raw lines.
An append-only sequence of meaningful events, session created, prompt submitted, tool invoked, artifact patched, branch merged, gives three things: auditability (who initiated, what changed, who approved, what data left), reproducibility (replayable provenance and reconstructable execution context, not promised identical output), and multiplayer synchronization from one ordered stream.
Reads run in parallel; writes to independent regions run in parallel; writes to the same logical region get serialized, rebased, or surfaced as conflicts. Globally locking a document while an agent works kills the multiplayer experience. Lock the smallest practical logical unit, and reserve pessimistic locks for schema changes, destructive migrations, and publishing final versions.
"Rewrite only the executive summary." "Do not touch anything outside the selected section." "Ask the legal-review agent to inspect only the liability language." Artifacts expose addressable regions; the model does not regenerate a whole document to make a local change. Local transformations improve latency, cost, controllability, mergeability, and trust.
People move fluidly between manual editing, natural-language transformation, inline suggestions, structured review, agent delegation, and branch-based experimentation. The ideal is "the agent helps me work on the artifact," not "the agent creates an output I either accept or regenerate." Human edits are events and versions too.
Prompt, loading state, result is not enough for long-running work. While an agent works, the user can add context, correct assumptions, change the goal, stop a tool call, approve a pending action, ask for intermediate results, or terminate while preserving partial work. The agent exposes meaningful checkpoints, not its hidden chain of thought.
A quick rewrite, a deep financial analysis, and a multi-system plan have different requirements. Users and enterprise policy control reasoning depth, token budgets, tool-call budgets, wall-clock and monetary budgets, and approval requirements. Most users pick presets: quick, balanced, deep, exhaustive. Cost and latency become explicit instead of invisible.
Not all work starts from a prompt. Weekly competitive briefs, nightly contract review, monthly board-report refreshes, pipeline monitoring. Scheduled tasks execute with explicitly defined permissions, not the broad ambient authority of whoever created them.
An agent connected to ten APIs may still have no idea what the objects mean, which fields are authoritative, what is sensitive, or what actions are permitted. A minimal core ontology, organization, workspace, agent, skill, tool, task, artifact, event, permission, policy, extended with the enterprise's own objects, lets agents operate against a semantic, policy-aware capability layer instead of a pile of endpoints.
Seven layers, from the surfaces users touch down to the audit trail.
Model access will continue to commoditize. So will retrieval, connectors, document generation, and basic tool use. The defensible system is the one that owns:
▸ the collaborative state · the artifact history · the permission graph · the execution history · the enterprise ontology · the skill library · the task graph · the human-agent interaction model
Once users and agents continuously work through this layer, it stops being an interface to a model. It becomes the coordination layer for enterprise knowledge work.
The winning product may look like a chat interface at first. Underneath, it behaves like Google Docs, Git, Temporal, Zanzibar, an agent runtime, and an enterprise semantic layer combined.