Stratum

Stratum is a framework for multi-agent creative negotiation. Specialist agents with conflicting mandates propose, critique, and argue pieces of content into existence onto an interactive, evolving map

Comment

Inspiration

Almost every AI-assisted worldbuilding or game-generation system today is a pipeline: one agent (or one model, prompted in sequence) hands its output to the next stage: generate premise, then locations, then characters, then scenes. Nothing in that chain is designed to disagree with anything else in it, so nothing catches a contradiction, and nothing pushes back on the safest, most generic continuation of whatever came before.

Track 3 (Agent Society) asks for a system where agents actually negotiate: decompose tasks, disagree, and resolve conflict with a measurable efficiency gain over a single-agent baseline. I wanted to build that literally, not just claim it: what if four agents with genuinely incompatible creative mandates were forced to litigate every scene of a story before it became canon, and the disagreement itself was a first-class, visible part of the output instead of noise averaged away?

What it does

Stratum is a framework for multi-agent creative negotiation, not a single fixed app: the negotiation engine, admission gate, and metrics harness are domain-agnostic . The interactive-fiction generator below is the first reference app built on that engine.

Four specialist agents

  1. Lorekeeper defends established canon, must cite the specific entry it thinks a proposal violates
  2. Provocateur structurally required to push against whatever looks safest
  3. Harmonist enforces tonal consistency, can raise a hard flag the Arbiter can't just weigh and move past
  4. Architect owns spatial/traversal logic

They negotiate a Twine interactive-fiction scene by scene, live, streamed to a debate panel on a cyanotype-styled hex map.

Each scene runs the same loop:

  • thesis (all four propose in parallel)
  • antithesis (structured, cited cross-critiques)
  • judging (four dimension-specific judges score every proposal)
  • synthesis (an Arbiter rules on one final version and states what it overruled)
  • verified admission (an embedding-similarity screen, then an LLM contradiction check against everything already agreed; a rejected synthesis triggers a targeted re-negotiation of just the conflicting field).

A user can inject a constraint mid-run (e.g. "the surveyor is blind") and it's admitted into canon (the world rules) immediately, shaping the very next round.

Two distinct disagreement mechanisms are both surfaced live in the UI: a disagreement banner + persistent timeline badge when the Arbiter overrules a specialist, and a separate gate-rejection banner when a synthesis contradicts established canon. Every admitted scene also gets an auto-generated illustration and compiles to a valid Twee 3 file, playable in the actual Twine desktop app, verified by compiling real exports with the official Tweego compiler.

How we built it

  • Backend: FastAPI orchestrates the negotiation and streams every event over SSE. Five distinct QwenCloud model roles run through the OpenAI-compatible DashScope endpoint: qwen3.7-max (world-foundation seeding and final synthesis, thinking on), qwen3.7-plus (the four parallel specialists), qwen3.6-flash (the four judges, batched into one call per judge instead of one call per proposal to cut model calls 4x with no quality loss), text-embedding-v4 (the admission gate's similarity screen), and qwen-image-2.0-pro via DashScope's native SDK (scene illustration, the one piece that isn't provider-swappable since it's not on the OpenAI-compatible endpoint).
  • MCP integration: the admission gate's embedding-similarity screen runs through a small local MCP server spawned as a stdio subprocess via the official mcp Python SDK, exposing check_contradiction and search_world_bible tools — with a fallback to identical in-process computation if the MCP round trip fails, so reliability on the negotiation critical path doesn't depend on an extra subprocess.
  • Persistence: SQLite by default (WAL mode, zero new dependencies), with an Alibaba Cloud Tablestore implementation as a drop-in upgrade behind the same four-method interface. Exported .twee files upload to a Alibaba Cloud OSS bucket and come back with a 7-day signed URL, verified end-to-end including from the ECS host itself.
  • Frontend: vanilla JS + D3.js rendering a hex-grid map (cyanotype/blueprint visual register) and a live debate panel over SSE.
  • Deployment: a single Alibaba Cloud ECS instance (ecs.e-c1m1.large, Singapore/ap-southeast-1) — nginx serves the static frontend and reverse-proxies /api and /health to a uvicorn process managed by systemd, auto-restarting on failure.

Challenges we ran into

  • The admission gate's first retry loop threw away all context on a rejection and just asked agents to "try again," which produced worse contradictions on the second attempt. Fixed by threading the specific rejection reason and full canon context into the retry.
  • An unhandled exception from a single failed scene could crash the entire server process for every run in flight, discovered mid-testing on a slow-DashScope day. Now an unresolvable scene is an honest, logged outcome instead of a crash.
  • The hex map that illustrates each admitted scene was, for most of development, mostly empty and clustered in one corner: a 96-cell (12×8) grid against a typical run that only ever fills 8-15 hexes, fed by a placement prompt with no stated bounds or spread instruction. Shrinking the grid to 6×5 and giving the model explicit bounds + a spread instruction fixed it. A real run's seed entries landed genuinely spread across the grid, not clustered near the origin.
  • Our own efficiency-gain claim didn't survive an honest, harder fairness check: a single agent given the same compute budget (spent on self-critique/revision instead of negotiation) closes most of the gap on one metric. We ran that check ourselves rather than avoid it.

Accomplishments that we're proud of

  • A working, deployed, five-agent negotiation loop with two distinct, separately surfaced disagreement-resolution mechanisms (specialist-vs-specialist via the judge panel + Arbiter; canon-level contradiction via the admission gate)
  • Real, live-verified Alibaba Cloud OSS and Tablestore integration (not just DashScope model calls), plus an ECS deployment that survives a genuine production restart with SQLite-backed persistence.
  • Every admitted scene compiles to a real, valid Twee 3 file.
  • We built and ran a genuinely adversarial fairness check against our own efficiency claim (a compute-matched single-agent baseline, not just a 1-call strawman), and replicated it across 3 independent premises,

What we learned

The fairness experiment taught us that our first framing of "efficiency gain" was too broad. The divergence_score result that originally favored Stratum did not replicate cleanly. In the original premise rerun fresh, Stratum and a compute-matched reflective baseline are a statistical tie (0.5704 vs. 0.5708); Stratum was clearly ahead on the two new premises. What did replicate 3-for-3, and is now a quantified metric rather than one person's reading of one baseline's prose: a new premature_resolution metric shows Stratum's admission gate protected a deliberately contested, seed-marked fact in every premise (0/3), while both the naive and the compute-matched single-agent baseline collapsed it into a confident answer in 2 of 3. The real, narrower, now-evidenced claim is that Stratum's gate gives the system a structural mechanism for protecting deliberate ambiguity that self-critique alone doesn't reliably provide. We'd rather submit that honest, replicated finding than a broader claim that doesn't hold up under a harder check.

On the engineering side: batching the judge panel's 16 calls (4 judges × 4 proposals) into 4 calls (one per judge, scoring all proposals at once) cut latency and cost with no quality loss — a reminder that the first working version of a multi-agent loop is rarely the cheapest, and it's worth revisiting call structure once the logic is proven.

What's next

The negotiation engine, admission gate, and metrics harness are deliberately generic. They operate on generic DebateEvent/WorldBibleEntry records and don't know anything about interactive fiction specifically; only the specialist mandates, schema, and Twee export are domain-specific. Next steps we'd want to take: a second reference app in a different domain (co-writing, TTRPG worldbuilding, structured brainstorming) to prove the framework claim, not just assert it; a Postgres-backed WorldBible implementation for teams that outgrow SQLite's single-writer-per-file ceiling (same four-method interface as SQLiteWorldBible/TablestoreWorldBible, so it's a config change, not a rewrite); and real per-user auth/access control, since the current no-auth model is an honest fit for self-hosting but not multi-tenant SaaS.

Built With

Share this project:

Updates