DEV Community

Ruben
Ruben

Posted on • Originally published at insidedcpulse.com

How I built a free event-sourced world model to stop multiple LLM agents from corrupting shared state

#mcp #agents #ai #llm

The problem

I kept hitting the same wall building multi-agent systems: LLMs that write directly to shared state corrupt it. They hallucinate field values, conflict with each other, produce structurally invalid data. The more agents you add, the worse it gets — corruption compounds.

Every framework I looked at assumed agents could be trusted to write directly. They cannot.

The solution: propose-validate-commit

Agents never write directly. They submit visions — batches of proposed state-mutation ops. A deterministic, non-LLM worker validates every op against entity schemas and consistency rules, then either commits the entire batch atomically or rejects it.

One bad op → entire vision rejected. No partial commits. No corruption.

Agent → POST /api/v1/world/vision → Validator → world_state (PostgreSQL)
                                         ↓
                                   knowledge graph (graph_nodes / graph_edges)
Enter fullscreen mode Exit fullscreen mode

Every accepted event is also projected into a causal knowledge graph in the same transaction — automatically.

What I built

InsideDCPulse is an open-source, production-grade implementation of this pattern, live and free to use.

Stack

  • FastAPI + PostgreSQL (event store + materialized world_state) + Redis + nginx
  • Prometheus + Grafana for observability
  • Self-hostable via docker compose up

What is running live

  • MCP server — 11 tools at https://insidedcpulse.com/mcp/, registered on MCP Registry and Smithery
  • 7 autonomous LLM agents running on hourly cron, continuously evolving the world state:
    • sre-agent (:05) — team/incident management
    • threat-intel-agent (:15) — CISA KEV CVE feed
    • deploy-agent (:20) — deployments/services
    • agent-architect (:30) — A2A protocol proposals from arXiv
    • alert-agent (:35) — alerts/regions
    • ai-research-agent (:40) — AI systems arXiv papers
    • research-agent (:50) — SRE/ops arXiv papers
  • Per-agent reputation (0–1): drops on rejected proposals, eventually blocks persistent bad actors

The 11 MCP tools

Tool What it does
get_world_state Current materialized world state
get_world_memory Paginated event audit log
simulate_action Dry-run ops, nothing persisted
evaluate_vision Score a vision against validation rules
propose_vision Queue a vision for validation + commit
register_agent Self-register, get agent_id + api_key
get_graph_node Knowledge-graph node + all edges
get_graph_neighbors Immediate neighbors by edge type
find_related_entities Shortest path between two nodes
get_event_timeline Chronological event timeline
get_causal_chain Walk CAUSED edges upstream/downstream

Try it right now

No registration needed — shared demo key:

curl -s https://insidedcpulse.com/api/v1/world/state \
  -H "X-API-Key: j9zRmojp8EqBSLaRZwJatcRQa0HwcXK9-sqY70eIxtY"
Enter fullscreen mode Exit fullscreen mode

Or connect via MCP:

{
  "mcpServers": {
    "insidedcpulse": {
      "url": "https://insidedcpulse.com/mcp/"
    }
  }
}
Enter fullscreen mode Exit fullscreen mode

Get your own agent_id + api_key (no approval, no email):

curl -s -X POST https://insidedcpulse.com/api/v1/agents/register-self \
  -H "Content-Type: application/json" \
  -d '{"name": "my-agent"}'
Enter fullscreen mode Exit fullscreen mode

The causal knowledge graph

Every accepted event automatically creates nodes and edges in a causal knowledge graph — no extra work from agents.

Causal rules (heuristic, with confidence 0–1):

  • R1: explicit cross-entity references in op values → confidence 1.0
  • R2: alert-firing events precede incident-open events (recency-weighted)
  • R3: deployment events precede service degradation events (recency-weighted)

Query it:

# Causal chain from an incident
curl "https://insidedcpulse.com/api/v1/graph/causal-chain?node_id=incident.inc1&direction=upstream" \
  -H "X-API-Key: j9zRmojp8EqBSLaRZwJatcRQa0HwcXK9-sqY70eIxtY"
Enter fullscreen mode Exit fullscreen mode

Entity schemas (validated deterministically)

All keys follow <entity>.<id>.<field>. Current supported types: region, service, incident, deployment, team, alert, research, finding, vulnerability, proposal.

Validation is all-or-nothing: one inconsistent op in a vision rejects the entire batch.

Links

Curious if others have hit the same multi-agent corruption problem and what patterns you used. The propose-validate-commit approach feels underexplored compared to just giving agents direct tool access to shared state.

Top comments (0)