Sovereign architect part 2: From Philosophy to Protocol

Part 2 of 2 — The Sovereign Architect

Part 1 laid out what I believe: engineering is applied philosophy, and the job is to survive human irrationality, selfishness, and chaos: not just satisfy a spec. Belief is easy. Enforcing it is not, especially once you're not the only one writing the code.

I work with AI coding agents constantly now: Cursor, Codex, Windsurf (now called Devine), Antigravity (IDE), etc whatever tool the week calls for. The moment you hand implementation to something else, belief stops being enough. An agent doesn't inherit your instincts. It inherits whatever you actually wrote down. So the philosophy either survives being compiled into explicit, checkable rules, or it doesn't survive at all. That compiled form is AGENTS.md, the file I hand every agent before it touches my code. This is that file, unpacked.

Grounded Intuition: the missing discipline

Part 1 ended on trusting an instinct once it's been checked. That's harder to enforce than it sounds, especially with an AI agent, because an agent's "instinct" is really just pattern-matching wearing the costume of judgment, the exact failure mode Part 1 warned about. So this principle needs a rule sitting underneath the others: voice the call, then ground it, before it's allowed to drive a decision. Cite the reasoning, (it could be the benchmark, the precedent, the calculation) even when the only audience is yourself.

This is what makes the philosophy operational instead of decorative. First-Principles tells you to question inherited assumptions; Grounded Intuition tells you what to do once the questioning runs out and you're left holding a judgment call. Don't just guess. Don't just vibe. Show your work, even when no one's asking to see it.

Execution Principles

Four habits keep the philosophy from evaporating under deadline pressure. Each one is a Part 1 principle translated into something an agent or a distracted version of me can actually follow without interpretation.

Think First. State assumptions out loud before acting on them. Ask when uncertain instead of guessing. Present alternatives instead of committing silently to one path. This is Asymmetry turned inward, onto the collaboration itself: assume I might have made a bad assumption, and check, rather than trusting the request at face value.

Simplicity. Build only what was asked. No single use abstractions, no speculative flexibility for requirements that don't exist yet. The test is social, not technical: if a senior engineer would call it overcomplicated, it is. This is Delete, restated as a constraint on generation instead of a rule for refactoring: don't create the bloat in the first place.

Surgical Edits. Match the existing style. No unprompted refactors. Pre-existing dead code gets mentioned, not silently deleted, it might be load-bearing in a way that isn't obvious. Every changed line has to trace back to the actual request. An agent that "improves" things nobody asked about is indistinguishable, from a blast-radius perspective, from one that's careless.

Goal-Driven. Vague tasks get converted into verifiable success criteria before work starts. "Make it faster" isn't a task, it's a mood, it becomes something like "reduce p95 latency from 200ms to 100ms under load." Multi-step work gets written as 1. [Step] → verify: [check], because strong criteria are what let an agent loop independently without drifting. This is Complexity Absorption at the planning stage: defining the verification is hard, unglamorous work, and it's supposed to be hard for whoever's specifying the task and not ambiguous for whoever ends up depending on the output.

In practice, the whole loop compresses to one line:

Vague Task → Think First → Verifiable Criteria → Surgical Edit → Self-Verify → Ship

Absorbing Complexity: where it actually lives

Complexity Absorption is easy to state and easy to get wrong in practice, because "hide it from the user" can just as easily mean "hide it badly", buried in a global variable, duct-taped into a callback, technically invisible to the user and a nightmare for the next engineer, who is also, eventually, a user of the code.

The discipline is encapsulation, not concealment. Heavy lifting — retries, fallback states, local caching, reconciliation — lives behind a single clean internal interface. The rest of the system calls one function and doesn't need to know it queried a cache, hit a timeout, fell back to a queue, and retried three times to get there. And critically: the machinery behind that interface stays legible. Hidden complexity is still complexity. Burying it under cleverness just moves the cost from the user to whoever reads the code next, which is usually also me, months later, having forgotten why any of it works.

Take a feature that would naturally require the user to manage an API key or rotate a credential. The unexamined version pushes that straight to them, maybe a settings screen, a .env file, a setup guide. The sovereign version keeps that concern inside the system: credentials sourced from the deployment environment, never requested interactively, the user never aware a key existed in the first place. The complexity didn't disappear, it just moved to the side of the interface built to carry it.

Quality Gates

Principles that aren't checked are just vibes with better branding. Three gates make the philosophy non-negotiable rather than aspirational.

Self-Verify. Before calling anything done, mentally simulate it against the principles, the edge cases, and the stated success criteria. This is where Complexity Absorption gets its bite: did this solution just push a decision, a setup step, or an edge case onto the user instead of solving it? If yes, that's a fail and it should get corrected before anything is considered finished.

Zero-Error. Never introduce bugs or regressions. Fix any breakage you cause. Delete code that becomes unused because of your change. Leave the system cleaner and more stable than you found it, not just functionally equivalent with new code stapled on.

Cost-Aware. Before anything ships, name its cost out loud. Does this introduce recurring hosting or infrastructure spend? Does it commit future me to maintenance hours nobody budgeted for? An unnamed cost isn't really free, it's just a cost nobody agreed to pay yet, and it always gets collected eventually, usually at a worse time than now, hopefully not when there is a downtime in prod. The gate isn't "is this expensive", plenty of the right calls are. It's "did I actually choose this cost, or did it just happen to me."

Decision Hierarchy

Principles conflict. Privacy sometimes costs speed. Absorbing complexity yourself sometimes costs simplicity in your own code. Rather than resolve that case-by-case under deadline pressure, the hierarchy resolves it in advance:

1. Privacy and sovereignty
2. Reduce complexity and failure modes
3. Absorb remaining complexity yourself — don't pass it to the user
4. Speed, lightweight footprint, scale
5. Handle asymmetry and bad-faith actors
6. Minimal and deletable

Notice where Complexity Absorption sits: above raw speed, below eliminating complexity outright. Try to delete it first. If you can't, bear the cost yourself before you optimize for how fast you shipped it. Speed purchased by dumping unresolved complexity on the user isn't speed in the sense I think of it, you are just putting debt on someone else or yourself.

Cost doesn't get its own rung here, because it isn't competing with the other five, it's the audit that runs underneath all of them. Every rung on this list has a price. The hierarchy tells you which price wins when they conflict. Cost tells you whether you actually noticed you were paying it.

The Rules

The rules read like a checklist, but each one is a principle made literal enough to follow without interpretation.

• Structured logs, never secrets — Asymmetry applied to your own failure data. Assume logs get seen by someone who shouldn't see what's in them, and design accordingly.
• Evaluate the attack surface of every dependency; prefer fifty lines of custom code over a library you don't fully control — Delete and Sovereignty working together.
• Name the recurring cost of any new dependency, service, or piece of infra — in dollars, hosting hours, or maintenance burden — before adopting it, not after the invoice arrives.
• Never ask for .env files or credentials directly; work around them — Privacy enforced at the level of the collaboration itself, not just the code.
• Push back on bloat or privacy risk, explain why, offer an alternative. Philosophy that only holds when I'm paying attention isn't a philosophy — it's a mood.
• Be token-efficient. Concise code, minimal prose, no boilerplate unless asked — Delete again, applied even to how the work communicates itself.

Closing

Part 1 asked what you're actually optimizing for when nobody's checking your work. Part 2 is how you check it anyway — the same five or six questions, run in the same order, whether I'm the one writing the code or an agent is doing it under my name. Name the assumption. Absorb the complexity. Verify before you ship. Never let a cost go unspoken.

A philosophy that can't survive being turned into a checklist was never a philosophy. It was a mood with good branding. This is the checklist.