Technical deep dive
Memory & security
How tamux keeps context durable and risk governed through layered memory, approvals, critique, provenance, and isolation.
Memory stack
SOUL.md
Identity memory: role, principles, operating identity, and stable specialization hints.
MEMORY.md
Durable fact and strategy memory: project facts, conventions, recurring corrections, and stable workflow rules.
USER.md
Operator profile memory: preferences, workflow signals, and user-facing profile information.
Structured runtime memory
Threads, tasks, goal runs, checkpoints, telemetry, operator profile records, and causal traces in daemon-owned persistence.
Recall memory
Search and retrieval surfaces such as session search, history search, and optional cross-session recall integrations.
Procedural memory
Skills and generated workflows: reusable procedures rather than just facts.
If you describe tamux memory as “three markdown files,” you are describing only the most visible surface, not the full system.
Why daemon-owned
- Memory survives UI restarts and disconnects.
- Multiple clients can reconnect to the same durable context.
- Handoffs and subagents can share persistent state honestly.
- Learning loops can operate over real persisted history.
That is one of the sharpest distinctions between tamux and disposable terminal chat shells.
Write pipeline
- A candidate durable fact, preference, or strategy hint emerges from a thread, task, goal, or reflection.
- The runtime decides which memory layer it belongs to.
- The write is bounded and normalized instead of dumping raw history.
- Contradiction and replacement rules are applied when needed.
- The memory artifact is updated.
- Provenance metadata is persisted alongside the write.
Security control plane
tamux security is broader than “don’t run dangerous shell commands.” It is governance around transitions, side effects, scope, reversibility, provenance, isolation, critique, and operator authority.
Execution substrate
Reports what happened or what is about to happen.
Orchestration plane
Manages runs, stages, lanes, retries, and advancement.
Governance plane
Decides whether advancement is allowed, constrained, deferred, denied, or isolated.
Audit layer
Preserves provenance and operator-visible history for later inspection and trust.
Governance tracks transitions
One of the most important design ideas in tamux security is that risk applies to transitions, not just raw commands. Examples include:
- run admission
- lane admission
- stage advancement
- retry
- blocked-to-resumed
- final disposition
The same command string can have very different risk depending on target scope, retries, sandbox posture, concurrency, and provenance continuity.
Structured verdicts
| Verdict | Meaning |
|---|---|
allow | Proceed normally. |
allow_with_constraints | Proceed, but only with narrowed scope or constraints. |
require_approval | Operator must explicitly authorize the transition. |
defer | Do not proceed yet; more conditions must be satisfied. |
deny | Do not perform the action. |
halt_and_isolate | Stop and isolate the work because risk is too high. |
allow_only_with_compensation_plan | Proceed only if mitigation/compensation is explicitly attached. |
Scope-bound approvals
Approvals in tamux are intended to bind to real execution conditions:
- target scope
- risk rationale
- attached constraints
- freshness/expiry window
- policy fingerprint
An approval can become stale if the target scope widens, privilege posture changes, sandbox availability changes, or the action shifts from read-only to side-effecting work.
Critique before risk
tamux already includes a real adversarial self-critique subsystem for risky or suspicious tool executions. It uses advocate, critic, and arbiter roles to decide whether a risky action should proceed, be rewritten into a safer variant, or require confirmation.
Provenance as safety dependency
Provenance is not just for later analytics. The system should be able to show:
- who initiated the action
- what policy inputs were evaluated
- what verdict was returned
- what approval authorized the step
- what tool or command actually ran
If provenance continuity is weak, the system should not pretend side effects were safely governed.
Memory moat
The sharper public description is that tamux combines readable curated memory, structured operational memory, and provenance-aware lifecycle control. That makes its memory system substantially stronger than a single context window or generic vector-store framing.
Operator guidance
- Write only durable facts, preferences, or strategy hints into memory—not task progress.
- Treat prior approval as stale when scope, privilege posture, or execution mode changes materially.
- Use goal runners when the work needs visible approvals, checkpoints, and durable state.
- Prefer bounded work and clear verification paths; that improves both safety and memory quality.