Maxwell's Demon: From Isolated Agents to Shared Operational Context

Two agents can investigate the same incident without knowing about each other. I want them to find each other's work.

The design must preserve evidence, access rules, and approval checks.

This article proposes a system for that problem. It describes the data rules, access boundaries, and tests that the design would need. It does not report a production deployment or measured savings.

Consider a database incident. Alice checks whether the database has used all available connections in its connection pool. She finds no evidence of this fault during the sampled period.

Ten minutes later, Bob starts an agent from a support ticket and checks for the same fault. Alice's investigation is still open, but Bob cannot see its findings.

A shared summary could help Bob decide what to check next. It must state when Alice collected the observations and link to the evidence. A result from one period does not rule out the same fault at another time.

The design addresses two costs:

• Coordination: people must find work that covers the same problem. They must share enough information for others to use it.
• Interface maintenance: a command-line interface (CLI), background worker, Teams approval card, and web dashboard need common data and action rules. Otherwise, each interface can apply different business rules.

I propose a Work Object for each investigation. This record would keep the same ID and retain its data when a process stops.

It would store findings with version numbers, references to evidence, and actions that need a decision. Each interface would show only the data its reader can access.

A discovery service would compare summaries and suggest related work.

The discovery service could recommend evidence to inspect. Separate policy checks would control access and actions that change external systems.

1. System parts and access boundaries

The proposed system has four responsibilities. The components below are candidates. This list does not report completed integrations.

Identity and policy: Go + Keycloak

A Go gateway would check access tokens issued by Keycloak. These tokens identify the caller and the access granted to that caller. The Keycloak application security guide describes its OpenID Connect, OAuth2, and SAML support.

A webhook sends an event to another service. The design would need separate, verified rules to check who sent each webhook.

The gateway would also separate tenants, which are customer or organizational accounts. It would check resource permissions and the version of the applicable policy.

A u64 compartment mask uses 64 bits to represent access categories. It would be a filter for this application. Keycloak does not guarantee that filter.

Tool access and progress reports: Rust bridge + gateway

A local Rust bridge would connect the software that runs an agent to approved tools. It would send progress summaries in a defined format.

A server gateway would direct requests and apply policy. The local bridge and remote gateway would each need separate security checks, even if they share code.

Third-party tool servers still need their own software runtimes and security checks.

Durable execution: Rivet Actors + Pi Durable

Rivet v3 preview architecture has three parts: a control plane, actor nodes, and object storage.

The control plane assigns Actors to nodes and directs HTTP and WebSocket requests. Nodes run application code with the Rivet SDK. They connect out to the control plane. Many Actors can share a Node.js, Bun, or Rust process.

Each Actor has a durable volume for its state, SQLite database, and key-value data. This volume retains data when the Actor stops.

The control plane confirms a write after a majority of its volume replicas have saved it to disk. These replicas are copies of the volume. It then moves the data to object storage, such as S3, in the background.

An Actor can sleep and wake on another node with its saved data. Current self-hosting docs specify one region.

I propose using an Actor to hold each Work Object. Test recovery and storage settings before use.

Rivet documents Pi Durable inside an Actor through pi(). Pi saves run steps to the Actor's SQLite database. Without a sandbox, its file tools also store files there. Pi Durable is still in beta.

Before use, test saved checkpoints, duplicate prompt handling, crash recovery, and the Rivet integration. A checkpoint records a point from which a run can resume.

The execution rules must distinguish a saved checkpoint from an action that changes an external system. A SQLite transaction cannot by itself undo a sent email or an AWS API call.

Tools need idempotency keys, a recovery action, or a rule against automatic retries. An idempotency key lets a service identify repeated requests for the same operation. After an uncertain outcome, inspect the external state before retrying.

I propose an agentOS sandbox for generated code. Before use, test its controls for host access and network access.

Interface views: MCP, web, and chat

MCP is the Model Context Protocol. A terminal, web workspace, and Teams adapter would use the same Work Object. Common data formats could reduce duplicate work on forms and validation.

Each adapter would still need maintenance, access checks, and tests. A Dynamic Apps integration would need the same checks.

2. One record with views for each reader

Each interface would show the fields that its reader has permission to see. For example, it could format the fields for a terminal or chat card.

Every view must keep the record ID, version, and access rules. It must show where the evidence came from and which finding it supports.

Separate interfaces can give different accounts of the same incident. A shared record gives each interface a common source. Each view can show the details its reader needs and has permission to read.

For example, the same investigation could support these views:

• A site reliability engineer (SRE) could see findings, saved checkpoint IDs, links to evidence files, and available tools.
• A product manager could see customer impact and the next business decision. The record must contain those fields before the view can show them.
• A support lead could receive a short Teams update when a relevant part of the record changes.

Each view needs rules for versions and access.

The design must define the order in which the system applies writes to the record. It must also define how the system handles conflicting changes.

Approval must identify the exact operation

A chat card can become out of date while someone reads it. The system must check the pending operation again when the user responds.

Before an action that can have a significant effect, the proposed executor would save the pending operation and pause.

The MCP elicitation feature lets a supported client request user input in a defined format. The MCP elicitation specification, 2025-06-18 defines that exchange. It does not define this application's approval policy or execution guarantees.

A Teams adapter would need an equivalent approval process.

The server must record exactly what the user approves. The approval must identify the action, target, arguments, approving user, expiry, and scope_epoch. The scope_epoch field identifies the policy version.

Before execution, the server must check that the operation is still pending and the user still has authority. It must also check that the approval matches the current operation. The server must reject expired or changed requests.

The server must check the pending state and consume the approval in one atomic operation. Both steps must succeed together, or neither must take effect. An approval can be consumed only once. This does not guarantee that an external tool call happens exactly once.

Local work and the last confirmed summary

Engineers should be able to keep local tools. They can share progress without moving all execution into a remote container.

A local agent program, such as Claude Code, could send a versioned CheckpointDigest to a remote Shadow Actor. A CheckpointDigest is a short progress summary with a version number.

The proposed Shadow Actor would store the state that the local session reports. It cannot inspect work that the session has not sent.

This example records a finding limited to one observed period:

Example CheckpointDigest (JSON)

{
  "session_id": "sess_alice_9f",
  "version": 18,
  "observed_at": "2026-10-14T14:32:00Z",
  "scope_epoch": 7,
  "goal": "Investigate elevated database commit latency",
  "entities": ["rds-eu-prod-04"],
  "findings": [
    {
      "claim": "Connection-pool exhaustion was not observed in the sampled interval",
      "status": "supported_for_observed_interval",
      "evidence_refs": ["artifact:pool-metrics-window-17"]
    }
  ],
  "open_hypotheses": ["WAL-related contention or storage latency"],
  "execution_availability": "local_only"
}

These are proposed rules for this application. They are not a Rivet or MCP standard.

The gateway must verify the sender, check versions, and assign security labels from trusted policy. These labels identify the access categories that the data requires. A client must not gain access by editing the digest.

Three limits apply:

• Local execution: files and shell commands stay on the laptop unless an explicit policy permits upload or remote execution.
• Separate request paths: a model gateway does not automatically control local tool calls. A separate control must check tool access.
• Available information: when the laptop is offline, the Shadow Actor can use only confirmed summaries and available artifacts. These summaries must have a confirmed receipt. It must state that limit.

The version field identifies the digest revision. The observed_at field gives the time of the summary. It does not define the period covered by the measurements. Each evidence artifact must record that period's start and end.

The scope_epoch field identifies the policy version. The server must check this version.

An old summary can remain useful evidence. Readers must see its age and limits. Do not present it as current system state.

A completed session can supply material for a playbook, which is a set of instructions for a task. Someone must first extract the conditions for use, steps, and validation checks.

An abandoned session does not prove that its approach failed.

3. Finding related evidence: the Maxwell's demon analogy

Return to the example. Alice is investigating Write-Ahead Log (WAL) waits on rds-eu-prod-04. WAL records database changes before the database writes them to its main data files. Bob is checking checkout timeouts. Dave is verifying backups against the same database.

Sending all three raw traces would add noise and could expose restricted data. A trace records steps in an execution.

Matching only the hostname would also be insufficient. The backup job might affect the incident, or it might have no effect.

Maxwell's demon offers one useful analogy for selective discovery.

The thought experiment describes an observer that sorts molecules through a gate.

Here, the gate is a service that selects authorized summaries that could help an investigation. Bennett's paper discusses the physical thought experiment and its limits. This software proposal does not claim to be thermodynamically equivalent or to provide free computation.

The service would compare CheckpointDigest records. It would send a short suggestion when related evidence could change the next step in an investigation. The recipient must still check that suggestion.

Steps to find related evidence

The first filter would use tenant, permissions, entities, service dependencies, and observation periods. Entities are the systems or resources named in a summary.

A later step could rank candidates by measured findings and possible causes that remain under investigation. Shared entity names can help a search. They do not prove a common cause.

The proposed process has five steps:

1. Send: send a new digest version after a meaningful change. Examples include a finding supported by evidence or a possible cause rejected after a check.
2. Filter: select recent candidates. Apply fixed tenant and access rules before the model processes them.
3. Rank: score the authorized candidates for their likely usefulness to the current investigation.
4. Suggest: send a short lead. Include its source, observation time, and summary version.
5. Inspect: check current permission again before retrieving the evidence artifact. Review that evidence before changing the plan.

Where Clef-flash could fit

Cloudflare's model definition describes Clef-flash as a 9B multimodal decision model. It returns probabilities for allowed answers to typed questions, which specify the permitted answer format.

Clef-flash is a candidate for ranking a limited set of authorized summaries. Each summary must be permitted for both the intended recipient and the ranking service.

A Rust gateway could call a separate model service. Evaluate its probability estimates on this task before using them to set a threshold for sending suggestions.

The design would give the ranking service a candidate set and a no_match option. The application would set any limit on the number of candidates. Check the API and serving version before setting that limit.

Confidence alone is a poor rule for finding related evidence. A confident session can be wrong. Two uncertain sessions can have evidence that helps when combined.

Test whether a suggestion helps the recipient inspect useful evidence. Include evidence that challenges the cause the recipient is investigating.

Finding related evidence also has a cost. It uses computing resources, adds network delay, requires evidence retrieval, and takes the reader's attention.

Compare work saved with those costs and the cost of misleading suggestions. Record the units and method for each measure. State how you calculate cost before combining time, money, and reader effort.

A suggestion should identify the observation, its source, and its age. For the example incident, it could read:

Related investigation: Alice observed WAL-related waits on the database backing checkout during an overlapping window. Inspect artifact:wal-metrics-04 before restarting checkout. (Updated 2m ago).

The ranking service must not remove an approval requirement or grant permission. Trusted tool rules and server policy must determine the checks required for an action.

The server must also validate tool metadata. An incorrect read-only label must not let a tool bypass these checks.

4. Security: keep labels with the data

Sharing findings between sessions can expose restricted information. A summary, notification, or cached model input can reveal that information even when it omits the raw artifact.

Denning's lattice model describes a framework for information flow among security classes.

In this proposal, each confidentiality compartment is an access category. When the system combines data, it must retain all the compartments that the input data requires.

These compartment checks are one part of the access rules. Tenant and resource checks also apply.

A u64 can represent up to 64 compartments. Each bit represents a compartment.

The filter below permits a read when the reader's clearance contains all required bits. Clearance is the set of compartments the reader can access. The required set can equal the clearance set. It does not have to be smaller.

Both masks must come from trusted policy:

Compartment filter (Rust)

/// Fast-path lattice invariant: one piece of authz, not the whole boundary.
/// Both masks must come from trusted policy compilation and signed state.
fn compartments_allow_read(clearance: u64, required: u64) -> bool {
    required & clearance == required
}

This function checks only whether the clearance includes the required compartments. It does not verify the caller, separate tenants, or prove that labels are complete. Measure its execution time on the target system.

The surrounding system must also meet these requirements:

• Keep all required labels: the Work Object must inherit every required compartment from each input it uses. Inputs include prompts, local files, tool outputs, and peer evidence. The system must control these input paths to enforce labels.
• Check tool use and data access separately: permission to call a tool does not give permission to read every possible result. Label the returned resource and data.
• Filter before ranking and recheck before retrieval: unauthorized summaries must not enter the ranking model's context. Apply the same rules to model caches, progress reports, notification queues, and the destination channel.
• Control release to a wider audience: a summary keeps the confidentiality requirements of its source data. Release to a less restricted audience requires an explicit approved transformation and a record of that decision. A permitted status field is one example.
• Check policy versions: keep tenant checks separate from the 64-bit mask. When access is revoked, reject old scope_epoch values. Invalidate affected caches for suggestions and access decisions. Information already disclosed cannot be recalled.

5. Rank summaries after meaningful changes

The number of sessions alone does not determine the cost of finding related evidence. Update frequency, candidate counts, time in queues, and summary size also matter.

An event-driven design runs after a change. It can avoid ranking unchanged records, but its savings need measurement.

I would start with these controls:

1. Use meaningful changes: rank after a new supported finding, rejected possible cause, tool failure, or proposed action with a significant effect. Combine frequent updates and limit the queue size.
2. Filter before ranking: limit candidates by tenant, access, age, service dependencies, and shared entities. An initial limit of 24 candidates plus no_match would be an application setting to test. It would not be a model guarantee.
3. Keep required checks during failure: on timeout or overload, match candidates with fixed rules and access checks, or send no suggestion. Access checks and mandatory approvals must still deny actions if their checks cannot complete.

Prefix caching depends on the serving system

Prefix caching reuses attention state when the start of a token sequence matches an earlier sequence. Attention state contains results from earlier model calculations. Tokens are the units of text a model processes. vLLM's design documentation describes block hashes that include tokens, preceding context, and other inputs. A block hash identifies a block from its contents.

It also describes cache salts that separate trust groups. A salt is an extra value used to prevent groups from sharing the same cache entries.

Cache behavior depends on the selected engine, model integration, and version. Check the settings in the chosen system that serves Clef-flash, including any SGLang deployment.

Capacity estimates must remain valid without assumed prefix reuse.

Stable tool definitions and new evidence added later in a prompt may preserve more reusable prefix blocks. Measure the actual cache hit rate and response time.

Access rules must also cover prompts and cached attention state. A cache does not control access.

Use a shared record during large incidents

During a large incident, many sessions may refer to the same entity. If every session notifies every other session, the number of pairs grows with the square of the session count.

A shared incident record can reduce duplicate notifications. It can also give readers a place to compare evidence.

I propose linking related sessions to an Incident Work Object when they meet a configured threshold. Assign a coordinator or a lease, which grants control for a limited time.

Keep the source of each piece of evidence. Track competing explanations. Apply access checks to membership.

The first confident report must not become the accepted cause without evidence.

Measure the complete request path

Cloudflare's October 1, 2026 launch note reports a Clef-flash median of 38.8 ms and p95 of 122.4 ms across its 43 benchmark runs. The median is the middle result. The p95 is the 95th percentile.

These results do not establish this system's response time or service guarantee.

Tests here would need to include filtering, time in queues, model processing, Actor wake-up, network delay, and evidence retrieval. Test these steps under concurrent load. Use fixed model and serving versions for each test. Verify their current limits.

6. Save evidence outside the active model context

A short summary can omit details needed to check a finding. Keeping every log in the active model context also has a cost.

The proposed design separates the information used for current work from the evidence kept for later review.

Two failures guide this separation:

• Replacing tool output with a summary can remove evidence that a later reader needs to check the conclusion.
• Keeping all raw output in every prompt uses context capacity and increases processing cost.

The active context would contain a digest and authorized references to artifacts, such as artifact:pool-metrics-window-17.

Durable storage would keep selected raw evidence under explicit retention rules. The Work Object would record which artifacts support each finding.

Readers can recover only artifacts that were saved, remain available, and are still authorized for them. A reference does not prove that an artifact exists.

Test artifacts that are missing, expired, or no longer authorized. Define who decides how long to keep evidence. Define how readers learn that evidence has expired.

Test suggestions before training a model

Execution traces could supply evaluation or training examples if retention rules and permissions allow that use. A closed ticket does not prove that every investigation step was correct.

A merged pull request (PR) or cleared alert can label an outcome. It does not show which suggestion helped.

Review the supporting evidence before using a trace as an example of a good suggestion.

I would use this evaluation plan:

1. Reconstruct the information used for the decision: use only evidence available when the suggestion was made. Separate observations supported by evidence from possible causes and later findings.
2. Compare with matching by fixed rules: include cases with the same hostname but no useful connection. Include old conclusions and useful evidence that contradicts the recipient's current explanation.
3. Review labels and separate the data: use test cases reviewed by people. Keep incidents and time windows separate across training and test sets. Check whether reported probabilities match observed outcomes. Training alone does not prove that they match.
4. Record use and outcome separately: OpenTelemetry span links can connect spans across traces. A span records one operation in a trace. Add application events for a suggestion, artifact retrieval, and later plan change. Their order alone does not prove that the suggestion caused a better result.

7. Other experiments and their limits

The same selection method could be tested in three other areas. Each needs its own permissions, cost budget, and criteria for success:

• Find information for the current context: rank saved playbooks and artifacts for inspection in an active session.
• Select optional traces for retention: use their meaning to select optional diagnostic traces to keep. Keep required security and compliance records under fixed rules.
• Retrieve information before it is requested: test authorized, read-only diagnostic requests whose rules permit safe repetition. Account for load, cost, and sensitive data before using them.

These remain experiments. A restricted answer format limits the possible outputs. It does not prove that the selected answer is correct or safe.

OWASP's prompt injection guidance describes attacks carried in external content, including tool outputs and documents. These attacks try to make a model follow instructions in that content.

A ranking model can also choose the wrong option after reading hostile content. Check that responses are in the allowed set. Treat retrieved text as untrusted data. Keep authorization outside the model.

Any option that leads to an external action still needs the required policy and approval checks.

How to test whether this design is useful

The next step is a small prototype. Use matching by fixed rules as the baseline for comparison.

Test whether versioned summaries help one investigation find useful evidence from another without exposing restricted data.

Then test out-of-date approvals, duplicate submissions, uncertain tool outcomes, revoked permissions, missing artifacts, and model-service failure.

Compare the ranking service with the baseline. Measure useful suggestions, false matches, missed matches, response time, cost, and reader effort.

Report access-control and approval failures separately. A useful suggestion cannot compensate for a disclosure or an unauthorized action.

The intended result is that an engineer can keep local tools. Other authorized readers can inspect a clear record of findings and pending decisions.

The prototype must test whether this reduces duplicate work.

Sources

Sources checked on October 27, 2026. Repository links point to the checked revision. Rivet sources checked again on October 28, 2026; v3 is a preview release.

• Keycloak application security guide. OpenID Connect, OAuth2, and SAML support. It does not verify the proposed Go gateway.
• Rivet v3 preview architecture, storage, self-hosting regions, and Pi Durable documentation. Control plane, shared actor nodes, replicated volumes, and object storage. Pi runs inside an Actor and saves run steps in SQLite. Without a sandbox, its file tools also store files there. Pi Durable remains in beta. These sources describe the available design; they do not verify this proposed application.
• MCP elicitation specification, 2025-06-18. Structured user input and client capability negotiation. Application approval policy remains separate.
• Bennett, Notes on Landauer's principle, Reversible Computation and Maxwell's Demon. Physical information processing and Maxwell's demon. Used only to bound the analogy.
• Cloudflare Clef-flash model definition. The 9B multimodal decision model and typed answer schema. It does not establish application accuracy or latency.
• Denning, A lattice model of secure information flow. A lattice framework for security classes and information flow. The abstract and bibliographic record were checked through Crossref; the full paper was not reviewed.
• vLLM automatic prefix caching design. Matching token prefixes, block hashes, and cache salts. No claim is made that Clef-flash has the same serving configuration.
• Cloudflare Clef launch note, October 1, 2026. Vendor-reported Clef-flash median 38.8 ms and p95 122.4 ms across 43 benchmark runs. These are not measurements of this architecture.
• OpenTelemetry overview: links between spans. Links can associate spans within or across traces. An application still needs events to record artifact use and outcomes.
• OWASP LLM Prompt Injection Prevention Cheat Sheet. Indirect prompt injection through external content; tool authorization and defense in depth.