Most people are still using AI the way they used a word processor in 1995 — open the app, type a prompt, get an output, paste it somewhere else. That works for small productivity wins. It is also already the outdated frame.

The frame that compounds is different. The model is not the assistant; it is the brain of a system you build around it — a system that holds your business context, your standards, your past decisions, and your way of working. That system is the orchestration. It sits between you and the model. The model gets replaced every few months; the orchestration does not. It is the only thing in this loop that compounds with you over time.

This piece is the operating principles for that orchestration layer. Seven of them. The technical practice underneath — how the system itself is built — lives in the companion piece, Engineering Practice Boundaries — One Bar for Engineers and AI, written for technical readers. You don’t need it to follow the seven below. They are what you, the person running the operation, layer on top once you accept that the model is a commodity and the next one will be too.

The audience is operators: founders, intrapreneurs, builders, leaders running real work and starting to wire AI into their teams. The principles are written so a senior engineer can use them too — but the frame is the operator’s, because what you are really building is a small organisation of agents. Which roles in your team stay distinctly human, and which collapse into the orchestration over the next two years, is decided by how well you build that small organisation. The principles below are what decides it.

1. The corpus is malleable

Every document you’ve written about your business — strategy, positioning, operating principles, decision logs, customer research — is an opinion held at a moment by a particular author. Truth is contextual. What was right six months ago may be wrong now.

The orchestration layer holds this in mind continuously. It treats your written corpus as evidence and prior, not ground truth. When the live conversation contradicts what you wrote in February, the conversation wins by default; the corpus updates, never the reverse. Drift between what’s written and what’s now is detected actively, surfaced explicitly, and resolved by deprecation or rewrite.

The failure mode this prevents is the one that breaks every “AI knowledge base” people build: the agent quotes a stale document with confidence, you act on it, and the quote was right when it was written and wrong by the time you used it. The orchestration’s job is to know the difference.

2. Written down, versioned, portable

If it isn’t written, it doesn’t exist. The instructions you give your agents, the corrections you’ve taught them, the templates you reuse, the rules you want enforced, the playbooks for recurring tasks — all of it lives in writing, or it lives nowhere. The agent cannot read your intentions; it can only read what is captured.

Versioned, not pinned to a single laptop. The skill you wrote last quarter has to still exist next Tuesday on whatever machine you are on. The correction you taught the agent in February has to persist into August. If the system only works on your original computer, you don’t have a system — you have a personal habit that disappears the day your laptop does.

Portable across people and machines. A new team member should be able to pick up the orchestration the same way they would pick up a well-written internal handbook — not by sitting next to you and watching. This is the same standard a serious organisation applies to its operating procedures, and it is the standard the orchestration layer has to meet.

3. Memory is tiered — three horizons, three sets of rules

Context and memory are critical, and they are not flat. Three buckets, each with its own write discipline and decay model. Confusing them is a category error that surfaces as either lost work or stale advice.

Short-term, short-lived. Active conversation, in-flight tasks, current plan, scratch reasoning. Ephemeral by design. Cleared at context reset. Never the source of truth for anything.

Mid-term, malleable, evolving. Project memos, in-flight tickets, watch-memos with explicit revisit dates, hypotheses under test, persona drafts, market reads. Decay is expected and welcome — these documents are supposed to change as understanding sharpens. They are working memory, not archive.

Long-term, stable across months. Doctrines, big goals, codified principles, decision registry, identity-level material. Slow to write, slow to change, never silently overwritten. This is the layer the engineering principles, the strategy, and the operating bar live in.

Promoting ephemera into long-term — turning a chat thread into doctrine — corrupts the doctrine. Demoting load-bearing facts into chat — never writing them down — loses them. Each tier has its own authoring cadence and its own deprecation rules. The orchestration enforces which tier a piece of context lives in.

4. The system corrects itself

Closed loop. The orchestration observes itself, surfaces deviations, and proposes refinements to the operator. Failures become rules. Frictions become tooling. Repeated manual work becomes codified pattern.

The cadence is concrete: twice is a pattern. The second time you correct the agent for the same class of mistake, that correction must run on a rule, hook, skill, or memory entry — not on your vigilance, not on your hope that you’ll remember next time. The third instance happens because the system was built to prevent it.

The operator decides what gets codified. The orchestration never silently mutates the long-term layer (per principle 1) and never lets the same problem fire three times. Self-improvement is suggested, not performed unilaterally. The loop must close, and the system is responsible for closing it.

5. Protect the operator’s cognition

This is the meta-principle that subsumes most of the others when you trace the why.

AI intelligence is cheap and getting cheaper. Your attention is not. It is the scarcest, most expensive resource in the loop. The orchestration protects it as the primary design constraint. Every output, every notification, every approval request is weighed against the cost it imposes on you.

Concretely:

  • Scope discipline. One thing at a time. A request that asks you to weigh in on five unrelated topics splits before it reaches you.
  • Distill first, detail second. Lead with the verdict, the summary, the link. Expose detail on request, not by default.
  • Approval gates only where they earn the interruption. Briefs to a sub-agent that doesn’t know your business, a change in working mode, or a fan-out across multiple agents — surface the shape before firing. Routine actions you have already approved a hundred times do not. The goal is not to maximise human-in-the-loop checks; it is to minimise them, while keeping the high-stakes ones where they belong. Every avoidable approval is a withdrawal from the cognitive bank.
  • Parallel by default. Independent work runs in parallel. Serial execution is the exception and has to justify itself.
  • The link is the recap. When a document, ticket, or page already exists, point to it. Don’t re-narrate the contents in conversation. One source of truth per fact.
  • Operational agents and strategic advisors are different tiers. Operational agents are loaded with your context and execute on your behalf. Strategic advisors stay deliberately context-naive — their job is to challenge the frame, not to comply with it. You decide which tier to call. The orchestration never collapses them into one.

The discipline is to ask, of every piece of friction the system imposes: is this saving cognition, or spending it? Friction that prevents a costly mistake earns its place. Friction that asks you to confirm a routine action you have already approved a hundred times does not.

6. Engineering principles apply by default

The orchestration is, structurally, software — even when you don’t think of it that way. Every skill, every prompt, every connection, every automation you set up is a piece of system-building. The principles that have governed serious software for forty years also govern this. There is no separate, lower bar because it is “AI” or because it is “personal”.

That means clear ownership of responsibility per piece, root-cause fixes over workarounds, change you can review and roll back, simplicity over speculative complexity, documentation that explains why. The full version is in Engineering Practice Boundaries — One Bar for Engineers and AI and is written for technical readers. You don’t need to read every line of it to apply it — the orchestration just needs to inherit the bar.

The corollary that catches operators specifically: AI does not get a discount on the bar. An agent that ships a quick fix bypassing your review process is not doing you a favour; it is degrading the operation under the same logic that would get a careless team member pulled aside. The orchestration is what enforces this — not the model, the orchestration.

7. Manage agents like you manage people

What works for humans works for agents. More context helps. Correction helps. Guidance helps. The management toolkit you’d run on a new hire is the same toolkit you run on an AI agent — and the orchestration is what lets you actually run it.

The arc is familiar. Early on the agent gets the long version: the goal, the constraints, the example, the bad pattern to avoid, the way you want it framed. You correct it the first few times the way you’d correct a new hire. You show the good answer and the bad one and let it learn from the contrast. You stay close.

As the agent gets fluent in a class of work, abstract higher. The detailed SOP you wrote in week one becomes the macro invocation in week eight — handle this the way we handled X — and the agent fills in the procedural gap because it has the context to do so. You show once; you let it learn. The grip loosens the same way a manager lets autonomy expand once trust has been earned. This is how compounding actually shows up: the things you used to walk through line-by-line move to a one-line invocation.

The other half is specialisation beats generalism. A general-purpose agent that knows everything in your operation eventually drowns in the cross-traffic of conflicting instructions, half-relevant memory, and skills written for unrelated work. The fix is the same fix an organisation reaches for when a generalist starts getting diluted: hire a specialist, give them the narrow context they need, and route the right work to them.

Concretely — when a class of work is mature enough to have its own SOP, lift it out into a specialised sub-agent with its own prompt, its own tool budget, its own memory. The generalist agent steps up a level and orchestrates across specialists instead of trying to be all of them. You climb the abstraction; the cycle repeats. When the new abstraction starts to collapse under load, you delegate that layer too, and you climb again.

The whole orchestration ends up mirroring what well-run organisations do. Onboard with context. Correct in feedback loops. Document SOPs. Promote on demonstrated proficiency. Specialise when the generalist is overloaded. Manage the managers. None of this is novel management practice; what is new is that it now applies to software, not just to teams of people.

What this enables

The principles are not a posture. They are what makes the rest of the year compound.

Write a skill once; never re-explain that workflow again. Set a hook once; never make that mistake again. Capture the doctrine once; the next conversation inherits it without you re-narrating it. Build the corrective loop into the system; the third instance of the problem prevents itself.

The compounding doesn’t show up as one big leap. It shows up as a hundred small things no longer stopping you, while the operators around you are still hand-rolling each session.

What to do now

If you are building this for the first time:

  1. Decide where the orchestration lives. A folder, a repository, a workspace — anywhere that is versioned, readable, and not lost when your laptop dies. Don’t optimise the structure yet; just put something in it. Structure earns itself by use.

  2. Write the first three skills. The three workflows you run most often, in the form: when I do X, do it this way. A short trigger, a short checklist, an example. The third time you find yourself typing the same paragraph at the agent, that paragraph is a skill.

  3. Catch one repeated mistake at the source. The single thing the agent gets wrong most often that you would want it to never get wrong again. Catch it at the action level — before it ships — not after, by review. This is the one rule that proves the loop is real.

  4. Split memory into three tiers from day one. Even if each tier starts with a single file. Merging them later is the bug; resist the temptation now.

  5. Run the orchestration the way a serious team runs its operation. Review changes. Prune what stops earning. Write down why a decision got made, not just what got changed.

The model will keep getting better. None of that is the edge — every operator reading this has access to the same model. The edge is what wraps the model. Build it now, tune it weekly, prune it honestly, and the compounding takes care of itself.

Which roles in your operation collapse into the orchestration over the next two years and which stay distinctly human is decided by how well that orchestration is built. The seven principles above are what decides it.

These principles are the what and the why. Three companion pieces on this site handle the rest of the picture:

Principles, doctrine, implementation, tooling — each piece extends the others. Read in any order; the loop closes.

Free resource

Personal AI Harness Audit

Send me a short description of your current harness — skills, hooks, memory, personas, connectors — and I'll send back a written audit plus a set of prompts your coding agent can run to level it up.

Drop your email and one paragraph on your current setup — or a link to your `.claude/` folder if it's public. One email back with the audit and the next-step prompts. No list, no sequence.