Skip to content
YantrikDB

Multi-Agent Ops: Which Agent Memory Is Stale?

Five agents watched the same incident. YantrikDB kept enough history to show which reports were stale.

This is the multi-agent AI showcase — the one that matters most to anyone building agent fleets today.

A basic retrieval stack can hand all five observations to a model and ask it to guess. YantrikDB preserves every structured claim with its source, validity window, and confidence band. The example coordinator then applies explicit, inspectable rules to identify which claims are active and which have expired.

The scenario

Section titled “The scenario”

Black Friday 2026, 15:20 UTC. The on-call engineer at a large e-commerce platform opens the incident coordinator and asks:

“Is the checkout rollout active? Are customers impacted?”

Five sub-agents have been watching five different sources. They all believe they’re telling the truth. Two of them are working from stale data.

The five agents

Section titled “The five agents”
AgentSourceState at 15:20
agent.deployCI/CD pipeline✅ Fresh — rollout completed 15:10
agent.telemetryPrometheus metrics✅ Fresh — error spike at 15:13
agent.supportCustomer support inbox✅ Fresh — 3 tickets since 15:12
agent.configFeature-flag API snapshot❌ Stale — last polled at 14:50
agent.statusPublic status page scrape❌ Stale — last updated 14:40

Each agent writes structured claims with extractor, valid_from, valid_to, and confidence_band. None of them gets to flatten the truth.

What the runnable coordinator produces

Section titled “What the runnable coordinator produces”

Phase 3: Polarity contradictions

Section titled “Phase 3: Polarity contradictions”
[1] POLARITY_CONTRADICTION
    checkout_rollout --is_active--> true
    (agent.deploy)    CLAIMS YES  [15:10 - now]    conf=high
    (agent.config)    CLAIMS NO   [14:50 - 15:10]  conf=high


[2] POLARITY_CONTRADICTION
    checkout_service --is_healthy--> true
    (agent.status)    CLAIMS YES  [14:40 - 15:13]  conf=medium
    (agent.telemetry) CLAIMS NO   [15:13 - now]    conf=high

Both disagreements are preserved. Their validity windows do not overlap, so the coordinator can distinguish a historical state change from two simultaneously active claims that require review.

Phase 4: The temporal query

Section titled “Phase 4: The temporal query”

“What did we believe at 15:20?”

checkout_rollout   YES   [agent.deploy,    15:10–now, high]
checkout_service   NO    [agent.telemetry, 15:13–now, high]
customer_impact    YES   [agent.support,   15:12–now, medium]

“What would we have believed at 14:55?”

checkout_rollout   NO    [agent.config,    14:50–15:10, high]
checkout_service   YES   [agent.status,    14:40–15:13, medium]

Same database. Same claims. Different moment in time = different truth. The on-call engineer can query the fleet’s belief state at any point in history, because validity windows are first-class.

Phase 6: The reconciled answer

Section titled “Phase 6: The reconciled answer”
Current facts (chosen by source-freshness + confidence):
  checkout_rollout --is_active--> true  = YES   [authority: agent.deploy]
  checkout_service --is_healthy--> true = NO    [authority: agent.telemetry]


Agents with STALE beliefs (excluded from verdict):
  - agent.config
  - agent.status


Recommended action for the on-call engineer:
  * checkout_v8 rollout IS live (deploy completed at 15:10)
  * checkout service IS degraded (telemetry confirms error spike)
  * customer impact IS real (support tickets arriving)
  * ROLL BACK checkout_v8 via feature flag

Why couldn’t Postgres + embeddings + a dashboard do this?

Section titled “Why couldn’t Postgres + embeddings + a dashboard do this?”

A vector index can return all five observations as similar, but similarity alone does not encode source, polarity, or validity. A relational or graph database can model those fields too, but the application must design the schema, conflict lifecycle, temporal filtering, and retrieval integration itself.

YantrikDB packages those memory-specific primitives together: the two claims coexist, temporal queries preserve both historical views, and conflicts between recognized structured claims can be recorded for review. The example’s final verdict remains coordinator policy, visible in the linked Python script.

What this unlocks

Section titled “What this unlocks”

Every agent fleet today has this problem:

  • RAG/retrieval agents — different retrievers surface different documents; current stacks average them, losing the disagreement
  • Tool-using agents — the API says one thing, the cached result says another; current stacks pick a random winner
  • Monitoring/ops agents — five dashboards, five opinions; current stacks rely on the human to reconcile
  • Multi-modal agents — vision says X, audio says Y, text says Z; current stacks force early commitment

With YantrikDB, an integration can store each agent’s observation as a claim with provenance, validity, and polarity. Recognized structured conflicts are recorded for review. The coordinator can ask not just “what’s the answer?” but “what beliefs are live right now, and which sources have gone stale?”

This is not agent orchestration. It is a memory substrate for building explicit, auditable belief-management policy.

Run it yourself

Section titled “Run it yourself”
Terminal window
git clone https://github.com/yantrikos/yantrikdb-server
python yantrikdb-server/docs/showcase/multi_agent_ops_engine.py \
    ydb_your_token \
    http://your-cluster:7438

Use the current published server and engine versions.

Full script: multi_agent_ops_engine.py

Your agents disagreed. The database preserved the evidence needed to decide.