Shared Memory, Scoped Permissions: The Architectural Decisions That Separate Production Agent Systems from Chatbot Wrappers

Most enterprise agent deployments fail at the same invisible boundary: the point where a system needs to remember something it was not explicitly told in the current request. The agent has no model of the work, no awareness of prior decisions, and no structured sense of who owns what. That is not a model problem. It is an architecture problem, and it sits squarely in how work context is represented, stored, and shared across agent runs.

Companion piece to our broader work on enterprise agent context design. See Enterprise Agent Context: Architecture & Design Patterns for analysis of GitLab Orbit, Noz, lifecycle graphs, and dependency-aware reasoning in production.

Why Flat Memory Fails in Agentic Workflows

The default pattern in enterprise agent projects is to attach a vector store to an LLM and call it memory. This works for retrieval over static documents. It does not work when the agent needs to understand that a task depends on another task, that a decision was made three days ago by a specific team, or that a particular user's scope of access excludes a sensitive workstream.

Vector similarity retrieval returns semantically related chunks. It does not return structured relationships between entities, nor does it enforce any notion of who is permitted to see what. When an agent operates across multiple users and multiple workstreams, those gaps become operational failures, not edge cases.

The deeper issue is that flat logs and vector indices model information as a collection of facts. Production work is not a collection of facts. It is a graph of dependencies, assignments, states, and decisions that evolve over time.

Graph-Based Work Context as the Core Primitive

Asana's Work Graph architecture offers a concrete reference point for what structured work context looks like at scale. Rather than storing tasks as rows in a database, the Work Graph models tasks, projects, portfolios, teams, and dependencies as typed nodes with typed edges. An agent operating over this graph can answer questions like "what is blocking this project" or "which tasks are assigned to this person across all active workstreams" because the answer is a graph traversal, not a keyword search.

The architectural implication for teams building internal agent platforms is direct. The memory layer should be a graph, not a log. Nodes should represent durable work entities: tasks, decisions, artefacts, agents, and people. Edges should represent typed relationships: dependency, assignment, approval, and precedence.

This structure gives agents the ability to reason about context rather than recall it. The difference matters commercially because reasoning over structure generalises to new situations, while retrieval over logs only surfaces situations that have already been explicitly recorded.

Scoped Permissions as a First-Class Architectural Concern

Shared memory creates a permission problem that most teams underestimate until it causes a production incident. If multiple agents read from and write to a shared graph, the question of what each agent is permitted to see and modify is not a feature to add later. It is a structural constraint that must be designed into the graph from the beginning.

Node-Level Access Control

The correct model is node-level access control, where each node in the work graph carries an access policy. An agent operating on behalf of a finance team should be able to traverse nodes within that team's subgraph without being able to read nodes tagged to a confidential HR workstream, even if both exist within the same graph instance.

This is not equivalent to row-level security in a relational database, though the analogy is useful as a starting point. In a graph, access to a node can depend on the path used to reach it, not just the node's own properties. That path-dependency requires a permission model that understands graph traversal, not just identity checks against a flat access control list.

Write Scoping and Atomic Commits

Write operations require equal care. An agent that can modify any node it can read will eventually produce conflicts when multiple agents operate concurrently on overlapping subgraphs. The safer pattern, which we have explored in depth in our work on shared memory for multi-agent systems, treats agent writes as atomic commits against a versioned graph. Each agent proposes a change, the change is validated against the current graph state, and only then is it merged. This is architecturally similar to how Git handles concurrent edits to a shared codebase.

Evaluation Continuity Across Agent Runs

One of the least-discussed problems in enterprise agent architecture is evaluation continuity: the ability to assess whether an agent's behaviour is improving or degrading across runs that span days or weeks. Most evaluation frameworks assume a single prompt-response pair. Production agents operate across sessions, hand off work between agents, and accumulate state over time.

The work graph provides a natural evaluation substrate. Because decisions and their outcomes are recorded as nodes and edges, it becomes possible to replay a sequence of agent actions against the graph state that existed at the time those actions were taken. That replay capability is the foundation of meaningful offline evaluation for agentic systems.

Without it, teams are left evaluating agents on synthetic benchmarks that do not reflect the actual distribution of work states the agent will encounter in production. The result is systems that pass evaluation and fail in deployment, which is the pattern we see most frequently when teams engage us after a failed first build.

Infrastructure Patterns That Support Coachable Agents

The phrase "coachable agent" describes a system that can be corrected, guided, and improved by the humans who work alongside it, without requiring a full retraining cycle. That property depends on the agent having a persistent, structured model of its own prior actions and their outcomes.

Correction as Graph Edits

If an agent makes an incorrect decision and a human corrects it, that correction should be recorded as a structured edit to the work graph, not as a note in a chat log. The edit carries the original state, the corrected state, and the identity of the correcting agent or human. Over time, this produces a structured dataset of corrections that can be used to fine-tune the agent's planning behaviour or to build rule-based guardrails against known failure modes.

Preference State as a Persistent Node Type

Agent personalisation in enterprise contexts is often implemented as a system prompt with a few user preferences appended. That approach does not persist across sessions and does not compose across multiple agents. The more durable pattern is to model user and team preferences as a node type within the work graph, with versioned history. An agent can then read the current preference state as part of its context construction, and preference updates are handled through the same write-scoping mechanism as any other graph modification.

These patterns together produce a system where human oversight is structurally embedded in the architecture, rather than bolted on as a post-hoc moderation layer. That distinction matters for enterprise deployments where auditability and control are non-negotiable operational requirements.