Comma Agent Implements Persistent Long-Term Memory Before DeepSeek Super-agent

Comma is a persistent personal AI agent ("housekeeper") that implements long-term memory and continuous operation ahead of DeepSeek's Super-agent design proposal. The system originated as Bridge (publicly released April 28), launched its fixed main dialog and task delegation June 3, and formally released as Comma October 1 — months before Anthropic's Claude Tag (June 23) and DeepSeek's Super-agent article.

Single-Session Architecture

Each workspace runs a single resident Router that receives all messages (group chats, private chats, client messages) into one continuous session. Concrete tasks are delegated to independent Worker sessions; results and provenance are returned to the Router. This single-session design keeps the full work history in one record. When the context window fills, older content is compressed out of the model context but the original log is retained; the Router can search and retrieve any original message or tool result, including compressed portions.

Example: A user asks why a hotel far from the subway was chosen on a previous Shanghai trip. The Router retrieves the original task return, price comparison, and execution log to answer and decide whether to reuse that choice.

The single session also enables concurrent task progress: while one task waits for user input (e.g., "check LAN IP then connect to AC"), the user can continue with other requests (e.g., check recent emails, ask what OpenAI released yesterday).

Condensed Workspace & Jev Fast Decision Model

The Condensed Workspace is a per-workspace fact list (one sentence per entry) shared by every Router and Worker. A fast decision model called Jev governs what enters and stays in this list.

Write-time gate: per-entry sharing judgment

When an agent proposes a new or modified fact, each candidate is posed to Jev as an independent yes/no question: "Is this a current fact that other agents in the workspace need to know?" Jev returns a probability; if below a threshold the update is rejected and sent back to the agent for reconsideration. The question phrasing was tuned: reverse phrasing caused near-universal rejection; forward phrasing created a clear probability gap where the threshold is set.

Post-reply audit: staleness and drift detection

After every agent reply, Comma asks Jev two independent questions using the current fact list, recent dialog, and the latest tool calls:

Needs update? Did the conversation reveal a new decision, owner, status, constraint, or location that the list lacks, or has an existing entry become outdated?

Drifted? Does the agent's latest reply or tool use contradict the fact list or the user's request, repeat a failed approach, or pursue a goal outside the conversation?

Probabilities exceeding thresholds trigger a reminder to the agent (which decides whether to act). Thresholds were calibrated on human-annotated samples.

Concrete flow: User states "book window seat, prefer morning flights" → Jev judges it a shared fact → entry added. Later user says "back pain, switch to aisle for long-haul" → next audit flags the old entry as stale → agent reminded to update.

Long-Term Memory & Information Flow Control (IFC) for Teams

Beyond the condensed fact list, the Router maintains richer long-term memory: user preferences, contacts, environment details, and dated work logs. Preferences, explicit user requests, and handoff progress are written by the Router during conversation; Workers receive needed information via task handoff.

In Comma for Teams , one Router serves the whole team, ingesting group chats, private chats, and private channels. Information Flow Control (IFC) governs disclosure: every piece of data carries its allowed readers; before the agent emits any output, it declares which sources it used, and the IFC kernel (implemented in Lean) verifies that all recipients in the target conversation are authorized for those sources. If blocked, the agent receives the reason and can either strip restricted content or ask the relevant person for approval.

Long-term memory follows the same rules. Group memory is visible to the whole group; private-channel or DM information is written into audience-scoped notes whose reader set is derived from the sources used at write time. Example: a private DM about a client quote is recorded for later use, but a group reply only shows content the group members are allowed to see.

Memory files are user-editable: over-broad preferences, outdated scopes can be corrected directly; fixed rules can be promoted into the Router's instructions.

Cross-member requests require confirmation: a Slack user asks Comma to query another member's Comma for iOS progress; the request routes to the target member who can decline, delegate to their own Router, or create a task directly.

Agent-Written Monitoring Loops (eBPF + Lean Verification)

For waiting on external events (contract return, repo changes, flight updates), agents write a C program per monitor, compiled to eBPF and run persistently in the cluster — called a Loop . Each Loop waits on timers or events, checks conditions, and wakes its owning agent when needed. Semantic judgments are delegated to Jev via structured questions; Jev returns only the judgment, while the agent retains action authority.

Thousands of Loops share one process; each must only access its own memory. The async-ebpf runtime provides machine-checked proofs: ~40,000 lines of Lean establish that any verified program, once compiled to x86_64 machine code, accesses only its own memory and preserves the caller's state on return. The proof targets the actual running code: Rust runtime modules are translated to Lean via Charon and Aeneas, then verified. The C compiler used to build Loops is itself compiled to eBPF and runs inside the same sandbox.

Example: User asks for cheapest Shanghai→Kunming flight tomorrow. Comma returns current best price as a card; a Loop then continuously monitors for price changes and wakes the agent only when a noteworthy change occurs.

Cost-Aware Task Scheduling via Human Acceptance

Tasks are categorized in a routing table (e.g., "price comparison & booking", "email triage"). The scheduler records per-category: model used, inference intensity, completion count, and cost. Success/failure is determined by human acceptance : a pending task accepted = success; rejected = failure.

The scheduler picks the model/intensity combination with the lowest average cost per completed task, while allocating a small fraction of tasks to explore other allowed combinations to gather comparative data. As more tasks accumulate per category, allocation becomes more accurate and cost decreases.

Two Feedback Loops

The system operates two closed loops (illustrated in Figure 12):

User corrections → update rules/facts (via Jev-audited Condensed Workspace and long-term memory).

Acceptance & cost → adjust which model handles each task category.

Comma demonstrates that system-level design — single-session continuity, audited shared facts, privacy-preserving team memory, verified persistent monitors, and empirically tuned scheduling — is as decisive as model capability for agents that must operate reliably over long horizons in real workflows.