DEV Community

Cover image for I Mapped a 19th Century French Kitchen onto AI Orchestration — Here's the Spec
Jack
Jack

Posted on

I Mapped a 19th Century French Kitchen onto AI Orchestration — Here's the Spec

Look, I'm not gonna front like I came into this with some grand research agenda. I'm a CS student from Las Vegas. No lab backing me. No funding. No pedigree. Just a dude who got genuinely frustrated watching multi-agent AI systems fall apart at the seams and decided to do something about it.
What I built is called XP-Arc. Named after my daughters, Xyla and Peace. Public meaning: Exponential Architecture. Private meaning: it should outlast everything built on top of it.
Here's the thing that nobody's really solving right now —

Agent pipelines keep failing the same three ways and everyone acts surprised

First way: silent data loss. An agent hits an entity type it can't process and just... drops it. No log. No flag. No signal. The intelligence map has a hole and nobody knows.

Second way: cascade corruption. One agent writes bad output. The next agent downstream eats it as gospel. By the time it hits the end of the pipeline the output is confidently, catastrophically wrong.

Third way: brittle orchestration. Everything works beautifully until one component hiccups — then the whole thing stalls. Because nobody planned for failure. They just planned for success.

This isn't bad luck. This is what happens when you build agent systems as chains — A calls B calls C — instead of building them as actual systems with shared state, typed routing, and real degradation logic.

That's what XP-Arc fixes. All three. By design, not by patch.

The blueprint came from a dead French chef Auguste Escoffier. 1900. The dude didn't invent cooking — he invented the system that makes professional kitchens run under pressure. Defined roles. Clean handoffs. One person standing at the pass whose whole job is making sure nothing leaves the kitchen wrong.
When I found that system I didn't see a restaurant. I saw a multi-agent architecture that had been battle-tested for 125 years.

The mapping isn't a metaphor. It's a spec.

Escoffier Role: XP-Arc Station
The Job: Garde Manger
The Forager: Raw intelligence acquisition
Saucier: The Analyst - Relationship inference
Entremetier: The Mapper - Structural intelligence
Rotisseur: The Chronicler - Temporal tracking
Poissonnier: The Sentinel - Anomaly detection
Aboyeur: The Aboyeur QA enforcement — nothing moves without clearance
*R&D Lateral Mesh: *- Stress-tests the system from outside the active brigade

The Aboyeur is the whole game. In Escoffier's kitchen the expeditor stands at the pass and checks every single plate before it goes to the dining room. In XP-Arc the Aboyeur node validates every station output against a formal schema before anything propagates downstream.

Can't bypass it. Can't configure it away. It's structural.

One shared surface instead of a chain.

Every agent in XP-Arc reads from and writes to a single SQLite state machine — the Intelligence Pool. Nobody talks directly to nobody else. Everything flows through the pool.

One seed URL hits the pool. The Executive wakes up, reads the entity type, routes it to the right station. That station extracts new entities, writes them back. Which wakes the Executive again. Which routes again.

One seed becomes a cascade. I call it the Exponential Snowball. You plant one thing and the whole intelligence picture assembles itself — automatically, recursively, without you touching it again.

What happens when things break — Fracture Protocol

When a primary station fails or comes back with low confidence output, XP-Arc doesn't just hand the same task to a weaker agent and hope for the best.

It fractures the task.

Breaks it into atomic micro-tasks. Routes each one to a lightweight local model — Llama 3 8B, Mistral 7B — each one operating with a narrow, precisely scoped job. One question. One data source. One output format.

Small models choke on complex multi-dimensional tasks. But give them one thing to do and they perform. Shard the load, shard the requirement for expensive inference.

The pool tracks the whole lifecycle:

raw → processing → failed → fractured → stitchable → mapped
Downstream stations see one clean mapped entity. The whole fracture happened behind the scenes. Invisible.

Zoran's Law
Every adaptive system has a tipping point. XP-Arc's is this:

**S > 1: **When the correction rate outpaces the informational decay rate, the system self-heals.

When 70% or more of your stations are running primary roles — not fallbacks — the system hits coherent intelligence output. That's the Zoran Threshold. Below it, the brigade degrades gracefully. The Sentinel watches this ratio live and tells you exactly where you stand.

The system knows its own health. That transparency is the feature.

You drop a seed URL in. Watch the graph build itself in real time. Nodes pop as entities get extracted. Edges draw themselves as relationships get inferred. The shadow infrastructure of any target just... maps itself. On screen. While you watch.

The stack
Python 3.12
Zero external dependencies — stdlib only, no installs, no lock files
SQLite state machine
Compatible with A2A and MCP by architecture, not retrofit
MIT licensed — take it, fork it, build on it

Real talk — what's done and what isn't

The PoC runs clean. The Snowball executes. The Forager extracts. DRAGON visualizes live.

What's not done yet: full Aboyeur validation, pool authentication, production-scale benchmarks. I documented every one of those gaps openly in the whitepaper security section. Named my own vulnerabilities before anyone else got the chance.

A framework that can't account for its own attack surface doesn't deserve to be trusted with yours.

Come find the flaws:
Full whitepaper. Full source. Aboyeur Protocol schema. All of it open.

github.com/UnkleJack/xp-arc

Las Vegas-born CS student. No lab. No funding. No pedigree. Just a regular dude who built something real.

Go see it live: unklejack.zo.space/dragon

Top comments (0)