Skip to main content
AMFS doesn’t just store what agents know — it captures why they acted. Every read, write, tool consultation, and outcome forms a decision trace that becomes searchable precedent.

The Problem

AI agents are stateless. Each session starts from scratch with no memory of past decisions, patterns, or mistakes. When something goes wrong, there’s no way to answer:
  • What information did the agent have when it decided?
  • What external sources did it consult?
  • Has a similar decision been made before, and what happened?
Traditional systems of record (CRMs, ERPs, ticketing systems) store the final state — the deal was closed, the ticket was resolved, the deploy succeeded. But the reasoning that connected data to action was never treated as data in the first place.

Decision Traces

A decision trace is a structured record of how an agent turned context into action:
This trace is queryable. The next agent — or a human auditor — can replay exactly what happened and why.

How AMFS Captures Decision Traces

AMFS’s existing primitives map directly to each component of a decision trace:

1. What the agent knew

Every read() call is automatically logged by the ReadTracker. When the agent later commits an outcome, AMFS knows exactly which entries informed the decision.

2. What external inputs were gathered

record_context() captures tool calls, API responses, and other external inputs without writing to storage. These appear in the causal chain alongside AMFS reads.

3. What the agent decided

The agent’s decision is written as a versioned, provenanced entry:

4. What happened next

Outcomes close the feedback loop. Confidence on causal entries adjusts automatically:

5. Why did we do that?

explain() returns the complete causal chain:
Returns:

From Traces to Graphs

Individual decision traces accumulate into a context graph: entities connected by decision events with “why” links.
Over time, this graph captures institutional knowledge that no single agent or person holds:
  • Precedent — “The last time we saw this pattern, we rolled back and it worked.”
  • Exception logic — “We always check PagerDuty before deploying changes to retry logic.”
  • Cross-system synthesis — “The decision combined AMFS memory, PagerDuty incidents, and git history.”

The Knowledge Graph

AMFS now has a persisted knowledge graph that complements the session-scoped decision trace. The two layers serve different purposes:

How Edges Are Created

The knowledge graph is populated automatically — no manual graph construction needed: Each edge carries confidence, evidence_count, first_seen, and last_seen. Repeated materializations increment the evidence count rather than creating duplicate edges.

Querying the Graph

Agents can explore the knowledge graph via the SDK or MCP:
Via MCP:
The Memory Cortex also compiles CONNECTION_MAP digests from graph edges, surfacing the most important relationships for an entity during amfs_briefing().

The Feedback Loop

Decision traces compound through AMFS’s outcome system:
Entries validated by positive outcomes decay slower. Entries correlated with incidents get boosted. The system learns which decisions lead to good outcomes without any explicit training.

Enriched Decision Traces

When commit_outcome() is called, AMFS automatically captures a rich snapshot of the session:
The resulting trace includes:

Per-Agent Memory Graph

AMFS tracks which agents interact with which entities, enabling per-agent memory views:
The agent memory graph shows every entity an agent has read from or written to, with entry counts and relationship types — giving you a complete picture of any agent’s knowledge footprint.

Immutability and Replay

Because AMFS uses Copy-on-Write versioning, decision traces are immutable. You can reconstruct the exact state of the world at any past decision point:
This is the difference between a system of record (stores the current state) and a context graph (stores the decision lineage). AMFS preserves both.

Pro: Immutable Decision Trace Store

Pro extends OSS traces with cryptographic guarantees and advanced telemetry:
  • HMAC-SHA256 signing — every trace is signed with content_hash and chained to the previous trace via parent_hash, forming a Merkle chain that detects tampering
  • LLM call spans — record model, provider, prompt/completion tokens, cost, latency, temperature, and finish reason for every LLM call during a session
  • Write events, tool calls, agent interactions — full audit trail of every action
  • OpenTelemetry export — export traces as OTel spans following GenAI semantic conventions, compatible with Jaeger, Grafana Tempo, Datadog, and Honeycomb
  • Auto entity extraction — LLM-powered extraction of entities (services, people, tools) and relationships (depends_on, uses, manages) from trace data
  • Immutability enforcement — Postgres RULEs block UPDATE and DELETE on the trace table

MCP Integration

Via the MCP server, AI coding agents can build decision traces automatically:
No manual instrumentation required. The causal chain builds itself from normal agent workflow.