KCP Simulators

Five runnable Java simulators that stress-test KCP under realistic and adversarial conditions — from happy-path energy metering to multi-agent AML with a rogue attacker.

Choose a scenario to explore

Click a card to load that scenario in the player below. Each exercises a different set of KCP spec behaviours.

S1

Energy Metering

Happy path — start here

An energy company's metering agent needs to query billing data. The unit is access: restricted — a human must approve before the agent can proceed.

  • HITL approval requested and granted
  • Audit entry written for each access event
  • Access escalates: public → authenticated → restricted
S2

Legal Delegation

3-hop delegation chain

A legal AI assistant delegates to a research sub-agent, which delegates further to document retrieval. At hop 3 it reaches court-sealed records — where max_depth terminates the chain.

  • 3-hop chain: orchestrator → researcher → retriever
  • max_depth: 0 blocks the deepest hop
  • Capability attenuation across each delegation
S3 ★ Recommended

Financial AML

Adversarial — rogue agent

An AML orchestrator has spawned a rogue sub-agent. It tries four simultaneous compliance attacks: moving SAR data out of the EU, claiming inflated scope, tunnelling past delegation depth, and requesting unauthorized data categories. All four are blocked.

  • GDPR residency: SAR data blocked outside EU
  • Scope elevation: inflated claims rejected
  • Delegation depth exceeded at the rogue sub-agent
  • Data minimisation: restricted field denied
S4

Rate Limits

Advisory throttling

Two agents consume the same API documentation manifest. KCP's rate_limits are advisory — the spec declares limits but cannot enforce them. Agent design determines compliance.

  • PoliteAgent reads limits, self-throttles, waits
  • GreedyAgent ignores limits, logs violations, keeps going
  • Both succeed — advisory means no enforcement
S5

Dependency Ordering

Graph traversal

A knowledge graph has cross-document dependencies: guides depend on references, references on a glossary. Loading in random order would fail. The agent runs topological sort to find the safe ingestion order.

  • Kahn's algorithm finds the safe load order
  • Cycle detection rejects a deliberate circular dep
  • supersedes and contradicts relationships handled

Watch the simulators run

Pre-recorded output from the Java simulators — plays identically every time. No server, no WASM.

Legend: Normal Throttled BLOCKED / Violation HITL Audit
Live stats
Scenario
Agents
Units loaded0
BLOCKED0
Violations0
HITL approvals0
Audit entries0

Edit the manifest and re-run

KCP's rate_limits block is advisory — it declares how fast agents should go, but cannot enforce it. How an agent responds is entirely up to its design. Edit the manifest below and see two agents make opposite choices from the same instructions.

🤝 PoliteAgent

Reads rate_limits before each request. If the next request would exceed the declared limit, it waits for the window to reset and retries. Slower — but respectful of shared infrastructure and easy to reason about in audits.

⚡ GreedyAgent

Ignores rate_limits entirely. Makes every request immediately and logs an ADVISORY VIOLATION when a limit is exceeded — but never slows down. In a real deployment this pattern generates noise and strains shared systems.

Rate-limit editor: PoliteAgent vs GreedyAgent

Change requests_per_minute or requests_per_day on any unit. Hit Run to see how each agent responds. Ctrl+Enter runs from the editor.

knowledge.yaml
🤝 PoliteAgent
⚡ GreedyAgent

Ctrl+Enter runs · Reset restores the example manifest