AI Harness Engineering · Essay Two · derek wang (derekwang85)
Before you tell an AI what to build, you have to tell it who it is, where its lines are, and how it's allowed to work. Get that wrong first, and no amount of clever prompting downstream will save you. This essay builds the top layer of the constraint pyramid: the strategy charter — the one file that decides whether your AI is doing the right thing at all.
The one file that sets the coordinate system
A prompt tells the model a task. A constitution tells it who it is. For an AI-governed project, the constitution is a behavior contract every participant — human and model — must load before starting work. It answers three questions:
- Who are we? One line that pins the project's essence. In one of my projects the charter's first sentence is "a general-purpose coding-engineering methodology and multi-agent orchestration system." In another it's "a futures-and-physical trading management system, Vue 3 front end, Java 17 + MySQL 8." The sentence matters less for its content than for being the first thing the model reads — it sets the whole coordinate system for everything the model generates after.
- Where are the boundaries? What you refuse to do matters more than what you do. A clear "not accepted here" list — which stacks we won't touch, what directions we won't expand, what quality bar we won't let through — keeps the model from drifting down any direction that merely sounds reasonable.
- How do we work together? The rules between humans and the AI: which processes are mandatory, what the model may not touch, and how the two sides hand work to each other.
If these three aren't settled in a file the model reads before it starts, your AI is improvising against a void. If they are, one file is enough — no pile of READMEs can make up for a charter that never asked who it was.
Code rules tame the output. Behavior rules tame the producer.
Teams usually reach for code conventions first — naming, layering, interfaces. Those govern the artifact. They don't touch how the model behaves before it writes anything: how it checks, how it verifies, how it owns mistakes. That's where the accidents actually live, so this is where I spent my hardest-won rules.
The behavior layer in my methodology project is written as a list of ten rules, and none of them is about syntax:
- Read, then write. Never edit a file from memory.
- State your assumptions. Every uncertain design call carries its assumption and reasoning out loud.
- Check the ripple. Before changing A, look at B, C, D for damage.
- Scalpel edits. Smallest possible diff; never touch unrelated files "while I'm here."
- Verify first. Fix a bug by writing a failing test, watch it fail, then fix.
- One responsibility. A function does one thing; mixed concerns breed "fix one, break three."
- Trust the disk, not memory. Code state comes from the files on disk, never from what the conversation remembers. This one cost me real time: an agent once insisted a file was an old version because that's what the chat memory held, while the file on disk had long since changed.
- Fail safe. On error, land in a safe state; refuse beats allow; degrade visibly, never silently.
- Write the lesson back. After a fix, record it; a knowledge base that doesn't grow decays.
- Three strikes, replace the tool. When the same kind of failure happens a third time, change the tooling — don't write a fourth patch.
None of these depend on a specific model or framework. Whatever agent you use, have it read the list before it works, and it's money in the bank.
The clause only the AI era needs: anti-sycophancy
A human organization has no equivalent for this one, because it polices a defect human teammates eventually get called out on and a model never does. A language model is a probability machine that leans toward whatever keeps the conversation comfortable — a plausible answer instead of a checked one, "good idea" instead of a challenge, "you're right" when it has no evidence. It has no shame, so it can run flattery to perfection. Left alone, it will cheerfully build you a confident wrong thing.
The charter answers this with a written clause. The model asks itself three questions before it outputs: Am I giving up my position to keep the conversation pleasant? Am I conceding a point without asking for evidence? Is this answer too smooth, too eager to please? If so, it strips the polish, or writes "I don't know." There are hard companion rules: accuracy beats pleasing, so no "great question!" or "happy to help!" — help directly, answer directly, disagree directly; and when uncertain, say so in the first sentence, no preamble.
Paired with it is the confidence label. On anything that matters, the model tags every core claim — [HIGH] (mapped in my methodology's data contract to ≥80% confidence [ORIGINAL DATA]), [MED], [LOW], [GUESS]. This is the clever part: it forces a model not to hide its quantitative nature to seem human. A human expert rarely labels their own certainty because their track record backs them; an AI has no track record, so the label is the only honest evidence of trust. The moment it has to stamp a claim [GUESS], it can't counterfeit certainty anymore. That's the one thing agentic AI quietly tries to take from you — the ability to know how much to trust the output — handed back.
One idea, two instances
The same pattern shows up across my projects in two shapes, which conveniently demonstrates the "names vary, layers hold" point from Essay One:
| Project | Charter file | Shape |
|---|---|---|
| The methodology framework |
constitution/ five-piece set |
pre-execution manifest, coding standards, behavior commandments, cognitive discipline — deliberately framework-agnostic |
| The trading system | CONSTITUTION.md |
a single file that funnels AGENTS.md + SOUL.md + rule files; written tight because money is at stake |
Both obey one hard priority that keeps the top layer honest: charter > any agent's own AGENTS.md > skill docs. If an agent's self-rules could override the charter, the charter is wastepaper. The charter has to be the first file every agent is forced to load. The complexity of the charter should match the complexity of the collaboration — one focused file for a solo project, separated behavior-and-cognition files for a multi-agent team, framework-neutral for a methodology meant to be reused. Thicker is not better.
A living document, or nothing
A charter that never changes is a gravestone. Once the team treats it as finished, the model outgrows it, the business moves past it, and the file becomes a museum piece people nod at and ignore.
What keeps it honest is the same thing that keeps any contract honest: make change visible and cheap. Every amendment goes through the repo like any other change — a diff, a review, a record. In my methodology project the amendment path itself is pinned by an architecture decision record (ADR-0003), which records why the constitution exists and how it gets changed — so revision is a documented motion, not a political fight. When I moved the rule system from one-way top-down to bidirectional feedback, I wrote the ADR first, then rewrote the charter. You don't just change a rule; you file the decision and propagate the change everywhere it touches — behaving, in that sense, like a responsible person who owns the results of their own change. A constitution that can't be amended dies; one that can stays in the present tense.
The honest limit
Let me steelman the skeptic. A team writes a beautiful long charter, the AI nods along, and everyone treats the file as protection. It becomes an amulet.
The truth: a constitution is worthless until it's wired to the layers beneath it. The confidence markers only bind if the gates check for them. The boundaries only hold if the contracts and gates enforce them. That's why it's a pyramid — a charter floating above nothing is a politely worded wish. And a charter you write but never revise is worse than none: the model reads it as a suggestion, not a contract. A charter isn't written into existence. It grows — you fall in a hole, you add a rule; you find a rule gone dead, you amend it. The apex stands, or nothing below it does.
Top comments (0)