DEV Community: Empire Iron Corps

From Unzip to Verified PASS in Three Minutes: Assembling an AI Agent Team That Checks Its Own Work

Empire Iron Corps — Mon, 26 Oct 2026 09:08:32 +0000

Most agent frameworks ask you to do one thing: trust the README. Copy some prompts, paste a config, and hope the whole thing holds together. When it doesn't, you're on your own — nothing tells you whether you assembled it wrong or the instructions were wrong to begin with.

When I packaged my 16-role AI agent "company" as an open-source kit, I wanted the opposite experience. The question I cared about: can a stranger reproduce my setup, and can a machine prove they did?

Here's the answer I shipped, and the thinking behind it.

The three-minute path

The whole assembly is four steps:

Unpack. One archive, 38 files, no build step. Windows gets a zip, Unix/macOS a tar.gz (older unzip builds mangle non-ASCII filenames, so tar.gz there).
Copy two things to two places. The 22 charters and 5 templates go to docs/empire/ in your project. Two knowledge-graph seed files go to docs/knowledge-graph/. That split is deliberate — the org chart and the memory system are different subsystems.
Create an empty battle log. One markdown file, docs/PROJECT_MEMORY.md. This is the shared memory every role reads and writes.
Run the check.

node scripts/verify-empire.mjs <project-root>

If it prints PASS, the team is assembled. If it doesn't, it tells you exactly which file is missing or inconsistent.

What "PASS" actually means

The verify script isn't a formality. It checks that the 22 charters are all present, that cross-references between them resolve, that the role roster matches the charters, and that the hard-boundary clauses exist where the rules say they must. Assembled-wrong fails loudly, with the specific gap named.

There's a second script for the knowledge-graph side (verify-graph.mjs) and a third one (pack-lint.mjs) that scans the pack itself for author-internal terms before shipping — more on that below.

The recorded run: proof, not promises

Inside the pack there's a file called 成功验证.md — "verified run." It is not a testimonial. It's a log of an actual assembly performed in a clean directory, from unpack to summon, with the commands and outputs written down. Every step in the manual maps to a step in the record.

The rule this enforces on me as the author: if a step in the docs can't be reproduced, the record catches it. This isn't theoretical — during development, an earlier version of the docs skipped the knowledge-graph seed step, and the verification record is what exposed it (the graph check failed on a fresh assembly even though it passed in my own workspace, where the old files masked the gap). The fix went into both the docs and the script.

The lesson generalizes: a self-check that runs in the author's environment proves nothing. Run the check where nothing pre-exists.

The pack scans its own wording

One more script ships in the pack: a lint that scans every markdown file for terms that shouldn't be in a public distribution — the author's internal project names, platform identifiers, automation IDs, that layer of private context. The wordlist itself is encoded into the script, so the check can run without the forbidden terms ever appearing in the repo.

This one earned its keep the embarrassing way. After I added a new section mentioning my internal tooling directory, the lint flagged the path on the next run — I'd have shipped it otherwise. The check doesn't get tired and doesn't assume good intentions, which is exactly what you want from a checker.

What this has to do with agent teams

The assembly story is the small version of a bigger claim: agent teams need machine-checkable state, not narrative state. "It's set up" and "it works" are claims, and claims need a command that can fail. The same discipline that verifies the assembly (a script with a PASS) verifies the team's daily output (evidence grades on every "done") and verifies its boundary conditions (a reviewer role whose objections are checkable, not vibes).

Everything I described — the 16 role charters, the ten rules of engagement, the battle log format, the verify scripts — ships in one free pack:

Repo: https://github.com/yyyz1yyyz2/empire-iron-corps
Downloads + install guide: https://empire-iron-corps.vercel.app
License: docs CC BY 4.0, code MIT

Honest notes, as always: the charters are written in Chinese (an English edition of the pack itself is on the roadmap — this post is the English tour). All 16 member names are explicitly fictional AI personas. No income claims anywhere; it's an organizational pattern, not a product pitch.

Disclosure: my own open-source project; nothing here is paid promotion.

If you assemble it and something doesn't reproduce, that's the most useful issue report I could ask for.

Give Your AI Team an Officer Whose Only Job Is Saying No

Empire Iron Corps — Sun, 18 Oct 2026 09:03:23 +0000

Everything in the agent-tooling world is optimized for shipping: faster loops, longer context, more autonomy. Almost nothing in the stack is designed to stop. So when an agent team drifts — and it will — nothing catches it, because every role you defined was built to produce.

After months of running a 16-role AI "company" for my coding work, the highest-leverage structural decision wasn't a smarter planner or a better executor. It was adding a role whose entire charter is objection.

The failure mode: the yes-stack

Multi-agent setups fail quietly. Each agent is agreeable by training, so a bad plan doesn't get argued down — it gets elaborated. I've watched an "improvement" pass through intel ("looks promising"), product ("defines it well"), engineering ("can implement"), and growth ("ready to distribute") — four yeses stacked on an assumption nobody actually verified. The stack feels like validation. It's just momentum with extra steps.

A recent post here on dev.to measured a version of this beautifully: models that correctly say "this label is wrong" when asked directly will still reproduce the wrong label when asked to generate output. Verification mode and generation mode are different modes. If every role in your pipeline lives in generation mode, the wrong thing ships politely.

The pattern: an independent veto role

The fix I landed on — borrowed from how human organizations handle exactly this problem — is a risk officer with three structural properties:

1. Independent reporting line. The risk role does not report to the "CEO" agent or any department. It's a peer. This matters more than the role's intelligence: a reviewer whose evaluation is graded by the people it reviews is not a reviewer.

2. Stop first, justify after. The risk role can halt any department's action immediately; the written justification comes later, and the principal (the human, or a designated arbiter role) rules within a fixed window. The ordering is deliberate. If veto requires prior justification, the action completes while the debate happens.

3. A charter, not a vibe. "Be careful" does nothing. The role's document specifies what it checks (claims without verification trails, irreversible actions without rollback plans, scope that grew mid-task, anything matching the hard-red-lines list) and what it must produce (the stop reason, the specific evidence, the appeal path).

What it actually catches

Genericized from real incidents in my own setup:

The unverifiable "done." An engineering role declared a fix complete; the risk role's check — "show the verification run" — found the test suite was never executed. Not malice. Optimism with a clipboard.
The growth tactic that was actually spam. A distribution role proposed a "community outreach" pattern that was, on inspection, posting the same pitch across twelve forums. The hard-red-lines list made this a one-line stop, not a debate.
The scope that grew. A "small refactor" quietly became a rewrite of a working subsystem. The stop forced the change to be re-justified at its actual size.

None of these require genius. They require someone whose job is to look.

The objection I get most: "doesn't this slow everything down?"

In tokens, yes — maybe 10% of the budget goes to the checking role. In rework, it's the cheapest line item I have. The asymmetry is the whole point: a wrong action costs a full cycle to undo; a veto costs one paragraph.

And it's worth saying clearly: the veto is not final. It escalates to the human decision-maker. What the veto does is move the default — from "actions proceed unless someone objects" to "questionable actions pause until someone rules." For a system that can act fast, that default flip is the entire product.

If you want to steal the pattern

You don't need my pack; the pattern is four paragraphs:

Add a reviewer role with no production duties and no reporting line into the roles it reviews.
Give it stop-first authority with mandatory written justification and a fixed arbitration window.
Write its charter as checkable conditions, not attitudes.
Keep a human (or a separately-chartered arbiter) as the final say, so the veto can't become a denial-of-service attack on your own team.

I packaged my full version — 16 role charters including this one, with the veto language, the hard-red-lines list, and the arbitration flow — as an open-source pack (docs CC BY 4.0, code MIT): empire-iron-corps on GitHub, with an install guide at the landing page. The charters are in Chinese; an English edition is on the roadmap. All role names are explicitly fictional AI personas, and as always: no income claims — this is an organizational pattern, shared as-is.

Disclosure: my own open-source project; nothing here is paid promotion.

How does your agent setup handle the "who is allowed to say no" question? Genuinely curious — it seems like the least-discussed role in the entire stack.

I Replaced My Prompt Pile with a Constitution: Organizing AI Coding Agents into a 16-Role Company

Empire Iron Corps — Wed, 14 Oct 2026 11:24:47 +0000

Like a lot of you, I started with one AI coding agent and a growing pile of prompts. Every incident produced a new patch: "when you do X, remember Y." Within a few months the pile was unreadable, the agent ignored half of it, and I still had to re-explain the same decisions every session.

The turning point wasn't a better model. It was a different question. Instead of asking "what prompt fixes this?" I started asking "who owns this decision?"

1. Personality stickers vs. enforceable charters

Most "AI team" templates you find are personality stickers: "You are Alice, a senior engineer who loves clean code." Fun, but not load-bearing.

What actually changed my agent's behavior was writing charters instead of personas. Every role in my setup has a document that specifies:

Mission — what this role is for, in one sentence
Decision framework — the procedure it must follow before acting (e.g. "any 'should we build X?' passes five questions: why fight it, do we have ammunition, how do we retreat, can we hold the ground, who executes")
Collaboration protocol — what it must accept from other roles (a risk officer's veto is non-negotiable; bad news travels up unfiltered)
Hard boundaries — lines it cannot cross even when the user asks (spam, fake engagement, fear-selling)
Output standard — what its deliverable must look like (every claim graded by evidence level; "no verification run, no 'done'")

The persona is three lines of flavor. The charter is the actual operating system.

2. The org chart (16 roles, no humans in the loop except decisions)

The structure that emerged:

A CEO-role agent that owns strategy and arbitration (one decision framework, applied everywhere: five questions before any battle)
Eight staff officers: chief of staff (sequencing), intel (recon & evidence grading), product (acceptance criteria), engineering (implementation & verification), growth (distribution), risk (independent veto power), opportunity (unit economics), foresight (long-range bets)
Content legions (writing / short-video / short-drama) with an independent review corps — three reviewer seats that are structurally forbidden from reporting to the production chain. No review, no ship.
A standing scout mechanism that continuously reconnoiters open-source practices and absorbs them (evaluate → trial → adopt → review)

The role I didn't expect to matter most: the risk officer. Agents don't have self-preservation instincts, but they do have drift. A role whose entire charter is "say no, then justify" catches the drift early.

3. The ten rules that survived contact with reality

The full set ships in the pack, but three proved load-bearing:

Evidence before claims. No "should work." If the verification command didn't run, the task isn't done. Every claim is graded: machine-level proof, behavior-level proof, or consensus of independent checks.
One battle at a time. Parallelism is for independent tasks with disjoint writes — never for three half-wars. Priority conflicts get arbitrated, not raced.
A shared battle log is the memory. Every action appends ≤3 lines (decision + reason, or failure + root cause + fix) to one log file. The next session starts from the log and never asks a human to re-explain context.

That last one quietly killed my biggest time sink: context re-explaining. The log is the handover document.

4. Accountability without bureaucracy

The piece people assume must be heavy: process. It isn't, because the process is enforced by other agents, not by meetings:

The review corps grades every deliverable; under threshold = automatic rework, no debate
Failures trigger a four-step root-cause investigation; the same root cause twice = process blame, not bad luck
Any "done" without a verification trail is treated as not-done by the next shift

The overhead is a few hundred lines of markdown. The saving is measured in not-re-doing things.

5. What I'd tell my past self

Stop collecting prompts; start writing charters with explicit decision frameworks
Give one role veto power and protect its independence structurally
Write the shared log format first — it's the real memory of the team
Keep hard boundaries even when it's inconvenient; they're what makes delegation safe

6. The pack (free & open)

I packaged the whole thing as Empire Iron Corps — 22 charters, ten rules of engagement, five working templates, a knowledge-graph methodology for keeping lessons, and three zero-dependency verification scripts (pack integrity + assembly check + wording lint).

Repo: https://github.com/yyyz1yyyz2/empire-iron-corps
Landing page with downloads: https://empire-iron-corps.vercel.app
License: docs CC BY 4.0, code MIT

Honest notes: the charters are written in Chinese (an English edition is on the roadmap); all 16 member names and backstories are explicitly fictional AI personas — they exist to constrain behavior, never to be passed off as real credentials; and the pack shares an organizational paradigm, with no income claims attached.

If you've solved the "many agents, no accountability" problem differently, I'd genuinely like to hear how — charters plus a shared battle log is my current answer, and I assume it's not the only one.

Disclosure: this is my own open-source project; nothing here is paid promotion.