TL;DR
A shared workspace for AI agents should be a bounded, versioned view of an active task, not an expanding conversation transcript. Specialists contribute observations, interpretations, and proposals through controlled interfaces. The workspace preserves their differences, tracks dependencies, and makes conflicting evidence visible. Separate active state from recovery history and reusable memory. Use atomic updates to prevent stale work from silently becoming the current plan, and define incomplete outcomes before enabling autonomous investigation. Start read-only and demonstrate a coordination benefit before adding more agents or production actions.
Introduction
An infrastructure agent identifies authentication failures. Another component finds a recent certificate change. A planner connects the two and prepares a remediation proposal.
Then a delayed log batch arrives. Its records suggest that failures began before the certificate change.
The important architectural question is no longer whether the planner can produce a plausible explanation. It is whether the system can revise that explanation, identify which recommendations depend on it, and prevent an outdated proposal from becoming the accepted plan.
This article develops a shared-state design for coordinated AI. The companion foundation is Global Workspace Theory in AI: Coordinating Agent Intelligence. The related articles address evidence and authority, then operational testing and recovery.
Baars, Geld, and Kozma describe Global Workspace Theory as a relationship between specialized processing and selected information becoming broadly available. The design below borrows that coordination principle. Its database contracts, validation rules, and operating boundaries are proposed engineering adaptations, not a standardized GWT implementation or evidence of machine consciousness.
The objective is practical: make it possible to inspect the current working explanation, the evidence behind it, and what should change when that evidence changes.
Choose the Coordination Problem Before the Framework
A shared workspace is worth considering when new evidence repeatedly changes what different specialists should examine. It is not automatically the right architecture whenever several tools are available.
LangChain’s Workflows and agents documentation distinguishes predetermined workflow paths from agents that dynamically choose their processes and tools. Start with that distinction, then decide whether the task needs distributed responsibilities.
| Task characteristic | Starting architecture | Decision criterion |
|---|---|---|
| The sequence and checks are already known | Deterministic workflow with bounded model steps | Keep the process explicit when runtime discovery adds little value |
| Investigation is dynamic but fits one accountable domain | One bounded agent inside a controlled workflow | Avoid distributing state unless one agent has a demonstrated limitation |
| Several specialists must repeatedly react to changing shared evidence | Task-scoped workspace with controlled contributions | Add coordination where cross-domain dependencies justify its cost |
Specialization describes a responsibility, not necessarily a separate model. A certificate inventory lookup can be an API integration. A policy check can be conventional authorization logic. Giving either component an agent persona does not improve its contract.
For this series, assume one tenant, one production application called payments-api, and read-only access to approved diagnostic sources. Production changes use a separate execution path. Also assume that the team can identify source systems, correlate records, and assess timestamp reliability. Without those prerequisites, the workspace can organize an unreliable timeline without making it reliable.
Separate Active State, Recovery History, and Reusable Memory
The word memory hides three responsibilities that should remain distinct.
The active workspace contains the current goal, selected evidence, working hypotheses, unresolved questions, and candidate next steps. It is temporary in purpose, even when stored durably for recovery.
The event history records how that state changed. An incorrect hypothesis may belong in the history because it influenced the investigation. Its presence there does not make it an established fact.
The reusable knowledge store contains information qualified for later tasks. Entering the current workspace must not automatically qualify an item for future retrieval as trusted operational guidance.
LangGraph’s Persistence documentation provides one implementation distinction: checkpointers maintain thread-scoped graph state, while stores hold application-defined information across threads. Those mechanisms can support the separation, but the application still needs its own evidence and retention rules.
Keep large source artifacts, such as log bundles and configuration snapshots, outside the compact task view. Reference them through stable identifiers with access checks. The evidence repository supports the workspace; it should not be confused with curated lessons for future incidents.
These are logical boundaries, not a requirement to deploy four database products. A small implementation can share infrastructure while separating records, permissions, and retention behavior.
A checkpoint can preserve a mistaken explanation accurately. A retrieval system can return it efficiently. Neither operation makes the explanation true.
Make the Workspace a Controlled Projection
In the proposed design, specialists submit candidate contributions rather than directly overwriting the task’s accepted interpretation.
A coordinator checks each contribution, records permitted transitions, and creates a new workspace version. A projection is the current task view derived from recorded changes. A reducer is the code that applies those changes according to explicit rules.
Microsoft’s Event Sourcing pattern describes reconstructing state from an ordered event history and also emphasizes the pattern’s complexity. Full event sourcing is optional here. A versioned task record with an audit history may be sufficient when complete reconstruction is unnecessary.
For an event-backed implementation, preserve the selection decisions and model judgments as recorded inputs. Rebuilding the projection should not ask a model to reinterpret the incident or query a live service. That would create a new investigation, not reconstruct the old one. Identify the event schema and reducer versions so historical records remain interpretable.
The diagram shows a small transactional design. Notice that the event record, selected task view, and notification intent share a commit boundary. Specialist reasoning happens outside that transaction.
AWS’s Transactional outbox pattern addresses the gap between updating a database and publishing a notification. Applied here, the transaction stores the state change and pending notification together. A dispatcher delivers committed notifications afterward. Retries can produce duplicates, so consumers must handle repeated delivery safely; this is not an end-to-end exactly-once guarantee.
Deduplicate retried contributions within their workspace, and use notification identifiers to keep repeated delivery from launching the same downstream work again.
The coordinator is a logical responsibility, not necessarily one process. For the pilot, serialize conflicting commits within one workspace, not across every tenant and incident. Replicas can handle requests, provided the database enforces the same version checks and constraints.
Most importantly, admission to the workspace means an item is permitted to participate in the investigation. It does not mean the item has been verified as true.
Define What Each Contribution Can Change
An observation reports what a source recorded. A hypothesis proposes an explanation. A proposal describes possible work. A verified outcome records what a defined external check established.
Give these types different transition rules. A planner can propose a certificate-related explanation, but it should not mark its own explanation as independently verified. A reporter can summarize a finding, but that summary should retain references to the evidence rather than becoming another independent source.
Preserve relationships between records as well as the records themselves. The important relationship is not simply that a log and a certificate change belong to the same incident. It is that a particular observation supports or challenges a particular claim, and that a proposal depends on that claim.
For example, failures before a certificate change challenge the claim that the change initiated the incident. They do not automatically establish that the change had no effect. The revised investigation may need to determine whether the change worsened an existing problem.
Keep missing information explicit. A certificate check that has not returned is awaiting_result, not evidence that the certificates are correct. Likewise, an empty query result is only meaningful alongside its time range, filters, target instances, and successful completion status.
Walk the Incident Through Changing State
Consider this illustrative sequence. All times are UTC, and the timeline assumes that source identity, service scope, and clock alignment have been checked. These are invented incident records for explaining the design, not observed production results.
| Workspace version | Newly recorded information | Required coordination behavior |
|---|---|---|
| 17 | Authentication failures are visible from 14:03; a certificate change is recorded at 14:00 | Preserve both observations without declaring causation |
| 18 | A certificate-related hypothesis is selected for investigation | Give the planner the hypothesis, evidence references, and unresolved questions |
| 19 | At 14:07, delayed logs arrive containing failures timestamped 13:57 | Mark the initiation claim as challenged and flag dependent planning work |
| 20 | The planner submits a proposal based on version 18 | Record the submission as requiring revalidation, not as the current accepted plan |
The two time values in the delayed log matter. The event time describes when the source says the failure happened. The ingestion time describes when the investigation received that information.
Use the committed workspace version to order state transitions. Use source event time, with its qualifications, to reason about the incident. Sorting solely by arrival time would place the earliest failure after the configuration change and support the wrong chronology.
Do not rewrite version 18 to make the system appear to have known about the earlier failures. Record when that evidence became available. An operator should be able to distinguish an initially reasonable hypothesis from a recommendation that remained unchanged after relevant counterevidence arrived.
The new observation still needs scrutiny. A timestamp from the wrong instance, an unreliable clock, or a different error mechanism may not challenge the original claim in the same way. Arrival changes what must be examined, not what must be believed.
An Illustrative Shared Workspace Contract
The YAML below represents version 20, after the stale proposal has been recorded. It is a proposed data contract, not configuration for a specific agent framework. The referenced observations live in an evidence repository with their source, event time, ingestion time, scope, and validation status.
Notice three features: contradictory evidence remains selected, the proposal retains its original basis version, and an outstanding check is visibly unfinished.
schema_version: "example-v1"
reducer_version: "workspace-rules-v1"
workspace_id: "incident-042"
workspace_version: 20
scope:
tenant_id: "tenant-a"
environment: "production"
service: "payments-api"
goal: "Identify the authentication failure mechanism"
status: "investigating"
selected_items:
observations:
- "obs-authentication-failures"
- "obs-certificate-change"
- "obs-failures-before-change"
hypotheses:
- id: "hyp-certificate-initiated-failure"
statement: "The certificate change initiated the failures"
status: "challenged"
supporting_evidence:
- "obs-authentication-failures"
- "obs-certificate-change"
challenging_evidence:
- "obs-failures-before-change"
open_questions:
- "Did the certificate change worsen an existing failure?"
- "Do affected instances present different certificate chains?"
proposals:
- id: "proposal-008"
based_on_workspace_version: 18
depends_on:
- "hyp-certificate-initiated-failure"
status: "requires_revalidation"
pending_work:
- request_id: "certificate-check-006"
status: "awaiting_result"
runtime_limits:
max_selected_items: 20
max_investigation_cycles: 6
execution_mode: "read_only"
Replace identifiers, scope, questions, and limits with the actual workload’s values. The limits are illustrative, not research-derived recommendations. Here, max_selected_items counts top-level observations and hypotheses under selected_items; nested references do not count again. Bound questions, proposals, and pending work separately in the implementation. Define one investigation cycle as well, so every component charges work against the same budget.
Trusted runtime services must establish the scope, version, and execution mode. The read_only field describes the restriction; credentials and tool-access enforcement implement it. A generated request to change the field must not change permissions.
The intended result is not a successful diagnosis. It is a state representation that prevents the challenged proposal from advancing without review. A syntactically valid YAML document alone cannot enforce any of those behaviors.
Reject Stale Decisions Without Discarding Useful Evidence
Version control needs two separate meanings.
The proposal’s basis version records the state used to produce it. The commit’s expected version is the database condition that prevents a write from silently replacing newer state. Keep the basis immutable even when the coordinator later records or reviews the proposal.
In the example, the planner worked from version 18. Its attempt to install that proposal without considering version 19 must fail. The coordinator can still record its arrival in version 20 with requires_revalidation, using a new transaction against the current state.
That distinction prevents two mistakes: losing useful work merely because it arrived late, and accepting outdated work merely because it is well formed.
Put the Version Check Inside the Write
An application-side comparison followed by an unconditional database update leaves a race between the check and the write.
PostgreSQL’s Transaction Isolation documentation explains that, under Read Committed, an update can wait for a concurrent writer and then reevaluate its WHERE condition against the updated row. For a single workspace record, include the expected version in the conditional update and verify that exactly one row changed. Roll back the associated history and notification writes when that condition fails.
Keep model calls and slow diagnostics outside the transaction. Compute the candidate from a snapshot, then use a short transaction to validate and commit it. Cross-workspace constraints need additional coordination; a version check on one row does not protect an unrelated task.
Revalidate Meaning, Not Just Version Numbers
Recording a proposal can itself increment the workspace version. That bookkeeping change must not automatically invalidate the proposal it just recorded.
For the pilot, define a conservative set of material changes: new contradictory evidence, expired prerequisites, changed scope, or revised task constraints. Any such change requires dependent proposals to be reviewed. Later, narrower dependency tracking may reduce unnecessary recomputation, but only if its additional complexity is justified.
The review should identify what changed, which assumptions were affected, and whether the proposal was retained, revised, or withdrawn. Simply relabeling a version-18 proposal as version 20 is not revalidation.
A current version also does not guarantee fresh evidence. A service-health observation may expire while the workspace receives no updates. Check freshness when using evidence, not only when admitting it.
Bound Attention Without Suppressing Disagreement
Workspace capacity should limit active material, not erase inconvenient evidence.
Reserve capacity for contradictions, blocking conditions, and unanswered questions. Collapse repeated derivatives of the same source rather than treating three specialist summaries as three independent observations. When material conflicts cannot fit within the configured limits, escalate instead of removing the uncertainty to make the task appear complete.
Budget the model-facing view separately from the stored workspace. Twenty evidence references can still expand into an oversized prompt if each retrieves a large log bundle. Use bounded excerpts with visible qualifications and stable references to the underlying artifacts.
Broadcasting should make selected state available to authorized task participants, not force every participant to rerun after every update. The planner may react to changed evidence dependencies; the reporter may refresh only when preparing an operator update. Record which workspace version and evidence revisions each invocation actually received.
For notifications that only announce a changed snapshot, a consumer can fetch the latest authorized view rather than process every obsolete notice. A history-reconstruction consumer is different: it must preserve the required event sequence. Do not apply snapshot-notification shortcuts to the event ledger.
The practical aim is selective coordination. A shared repository with no admission rules is too permissive; an indiscriminate broadcast that triggers every specialist on every update is too expensive to assume useful without measurement.
Define Incomplete Outcomes Before Successful Ones
An investigation should be able to end without a confident diagnosis. Define states such as evidence_incomplete, budget_exhausted, and human_review_required, alongside domain-approved criteria for a supported conclusion.
When a specialist times out, preserve its outstanding question and last known status. When an investigation exhausts its budget, stop launching work and provide an operator handoff. Do not give the reporter permission to turn a missing check into a clean bill of health.
For the certificate scenario, a valid read-only outcome might be:
Earlier failures challenge the claim that the certificate change initiated the incident. Its contribution remains unresolved. Compare certificate chains across affected instances and confirm the earlier records before selecting remediation.
That is useful even though the cause remains unknown. It communicates what changed and what evidence is still needed.
Define terminal behavior for late arrivals too. Record late results under the retention policy, but do not silently reopen a closed task. Reopening should be an explicit transition with an owner and a renewed work budget.
Give the Coordination Boundary an Owner
The platform team should own state transitions, concurrency controls, delivery, and recovery. Domain owners define what observations mean and which checks support a conclusion. Security owners define admission and disclosure rules.
Monitor proposal invalidations, stale evidence, duplicate delivery, outstanding work, and investigations that exhaust their budgets. A high invalidation rate may reflect a changing environment, slow specialists, or overly broad rules. Interpret it alongside operator corrections and investigation outcomes rather than optimizing it in isolation.
Start with recorded incidents and then a read-only pilot. Compare the workspace design with the existing workflow or a single bounded agent using equivalent evidence, access, and task budgets. Measure time to a supported outcome, operator rework, tool calls, and total operating cost.
Include unsuccessful investigations in that comparison. Excluding escalations and exhausted runs would hide the cost of failing to reach a conclusion.
The first useful demonstration is not that several specialists agree on a certificate diagnosis. It is that the system notices counterevidence, revises dependent work, and hands off unresolved questions without attempting an unauthorized change.
Conclusion
A shared workspace for AI agents should make coordination inspectable. It should show what the system is considering, which evidence supports or challenges it, what remains unknown, and which assumptions a proposal depends on.
The practical starting point is a bounded task view, typed contributions, explicit transitions, and a version-checked commit boundary. Keep active state, historical reconstruction, and reusable knowledge separate. Add specialists only when their contribution justifies the coordination and operating cost.
The certificate incident illustrates the standard to aim for: when the evidence changes, the system’s plan must become reviewable, not merely its narrative more persuasive.
This establishes the shared-state model, not execution authority. Part 2, AI Agent Governance: Evidence Is Not Authority, examines how to prevent selected information, apparent consensus, and persistent memory from becoming permission to act.
Continue this series
Shared workspace, authority, and reliability
Part 1 of 3.
Explore the Enterprise AI hub for related architecture and governance guides.
Foundation: Global Workspace Theory in AI: Coordinating Agent Intelligence
- Designing a Shared Workspace for AI Agents (you are here)
- AI Agent Governance: Evidence Is Not Authority
- AI Agent Reliability: Test the Whole Coordination Loop
2 thoughts on “Designing a Shared Workspace for AI Agents”