There’s a fair chance Claude Code is open on your machine right now, doing the job everyone assumes it’s for: writing code faster than you can. You describe, it generates, you review, you paste.
The conventional wisdom is that Claude Code is a code generator. A very good autocomplete with opinions. For me, that framing is tidy, and it’s wrong — not wrong at the edges, wrong at the foundation.
Here’s the bigger thing it misses, and it’s the thing I now spend my working life inside.
The enterprise AI question of 2026 is not “which model should we buy?” That decision’s already been made, mostly by procurement: Microsoft reported 20 million paid Microsoft 365 Copilot seats on its April earnings call, up from 15 million in January. The assistants are bought, licensed, and already sitting in the estate.
The question that actually lands on my desk is the next one — how does the AI we already pay for reach the systems we actually run, the warehouse and the customer data and the service platform, without failing the security review?
The market is converging on an answer, and it has one non-negotiable property: the assistant acts as the signed-in person. Not as a service account with god-rights. Not as a shared key everyone hides behind. As you — so the system enforces your permissions, and the audit log tells the truth. I’ve spent nine months building that answer for real enterprises, and somewhere along the way I stopped designing it from scratch.
Today I spend a lot of my time working from a reference architecture. I call it the Run-As-You Rail: five planes that every one of these builds crosses, whatever the logos.
The identity plane — the directory, the app registrations, the roles.
The hosting plane — the cloud machine the connection lives on.
The integration plane — the engine in the middle that moves and gates the calls.
The data plane — the platform that holds the answers and decides who sees which rows.
The protocol plane on top — the tool definitions the assistant actually calls.
The architecture is the constant; the customer’s requirements pick the parts. The build I’ve just finished: ChatGPT and Copilot reaching Snowflake as the signed-in person, identity in Microsoft Entra, a bridge on AWS.
The build before it had a service-management platform in the data seat instead, and an earlier one ran identity on Keycloak rather than Entra. Swap Snowflake for Databricks tomorrow and the rail survives that too.
The pattern holds; the parts rotate.
Five planes used to mean five specialists, and a hand-off at every seam. The seams are where these projects get rocky — every hand-off loses context, and every boundary is a place for a fault to hide.
Which brings me to what Claude Code actually is in my working day.
The architecture doesn’t live in my head, and it doesn’t live in a slide deck or Confluence. It’s encoded — as skills, recipes and checklists my teammate can execute, plus a persistent memory of each estate: which identity contract is in force, which rails are protected, what’s already been proven. When a session starts, Claude Code doesn’t start from zero. It starts from the pattern.
So a morning’s brief doesn’t look like “write me a function.” Stripped of names, here’s the shape of one from the Snowflake build:
Today: finish the data-plane leg and prove it end to end.
1. Deploy the three tool endpoints, then verify what's actually
deployed matches source — not what we remember deploying.
2. Run the contrast test: two test users call the same tool.
I want two different answers, each attributable to its user.
If they match, the rail is lying to us — stop and show me.
3. Another client's live rail shares this environment. It is
read-only today. Snapshot its configuration before any write,
and prove it byte-for-byte unchanged after.
4. Anything hard to reverse waits for my approval. Ask.
And then it goes and does it — not by generating code for me to carry to each system, but by operating each plane through that plane’s own controls.
The cloud machine through the cloud’s remote-management channel, with no remote-desktop doors left open on it at all.
The identity configuration through the directory’s own admin interfaces.
The data platform in its own query language.
The finished tool endpoints called directly, the way a real user’s assistant would call them.
One continuous thread; nobody re-explains the system at a boundary, because inside one reasoning context there are no boundaries.
My job in that loop is direction and judgement — and personally approving anything that would be hard to reverse.
Then one leg of the build broke, and the relationship earned its name.
Copilot’s calls were failing where ChatGPT’s identical calls succeeded. The fault could have lived in any of six layers between the assistant and the data: the token Copilot minted, the bridge’s identity injection, the tool definitions, the permissions gate, the identity exchange, the Snowflake user mapping. A conventional team throws that fault over five walls and waits a fortnight for it to come back. My teammate traced it through all six in one sitting — and not by guessing. Reconstructed from that day’s notes:
SYMPTOM Copilot fails. ChatGPT, calling the same tools
through the same rail, succeeds.
THEORY 1 The permissions gate is rejecting Copilot's role.
MEASURE Temporary logging onto the live bridge; decode the
credential actually arriving. The role is present.
Theory dead.
THEORY 2 The identity exchange is failing downstream.
MEASURE Replay the exchange on its own, outside the rail.
It holds. Theory dead.
EVIDENCE Read what is genuinely deployed at each layer —
the live configuration, not the source, not memory.
One mismatch found.
FAULT One name: a field the data platform required in the
credential, which the identity configuration had
never been told to send.
FIX One change, at the layer the evidence chose.
TIDY-UP Instrumentation off. The one log that caught a live
credential: scrubbed. Temporary access: deleted.
Read the MEASURE lines again, because they’re the whole method. It decoded the credentials actually arriving — not the ones we assumed were arriving. It replayed the identity exchange in isolation to see whether that step held on its own. It read the deployed state rather than either of our memories of it. Twice it held a confident, plausible theory, and twice the measurements killed it. That’s not a weakness of the method — that is the method. No amount of reasoning would have found a single missing field name. Reading the actual credential did.
The law underneath is short, and it’s the phrase I now use for the whole relationship: operate, don’t generate.
At the strategy altitude it means this: the valuable thing was never the generated code. The valuable thing is an operated estate — the AI your company already pays for, reaching the systems it actually runs, on a rail that passes a security review. That is what the sunk investment has been waiting for, and it’s why one architect with an encoded pattern can now do what used to take a bench of specialists a quarter.
At my desk, it means terms — because working this way puts an agent’s hands on development and test systems. Some poor use of this powerful technology could easily take your system down with one badly chosen command. So the terms of the relationship matter more than the tooling.
Mine, in the order I’d give them to you:
Permission gates on. Nothing irreversible happens without a human click.
The never-touch list is written before the session starts. On this build, another client’s live rail shared the environment: read-only, snapshotted first, proven byte-identical after.
Secrets never cross the working surface. Not printed, not echoed, not left behind in a log. One got caught in a debug log during that diagnosis; it was scrubbed the same hour. That’s the discipline — not the absence of the problem, the handling of it.
Instrument, don’t theorise. Every confident claim is provisional until you’ve both seen the evidence.
Verify against what’s deployed, never against your memory of it. Live estates drift.
Tidy up. Temporary logging, temporary access, temporary anything — tracked, and reverted when the job’s done.
Make it write down what it learned. Every hard-won fix goes back into the encoded pattern, so the next build starts ahead of the last one.
And the biggest term of all: this amplifies an operator’s judgement — it does not replace it. I could steer that diagnosis because I knew what right looked like at every layer. Hand the same teammate to someone who doesn’t, and you get output that’s fast, confident and wrong — which, on live systems, is the most expensive kind of wrong there is.
People usually ask for the configuration at this point, because “encoded” is doing a lot of work in the paragraphs above — and because this is where my setup stops being a coding assistant and becomes something else: a pattern-based operations companion, designed that way on purpose. The smallest real version of the design is three files, and you can copy all three this afternoon.
The instruction file is the estate contract — read at the start of every session, so the teammate never begins from zero:
# CLAUDE.md — the estate contract (excerpt)
## What you are
The operations companion for this estate. You operate systems
through their own controls. You do not freelance.
## The estate (the five planes)
Identity: [your directory] Hosting: [your cloud]
Integration: [your engine] Data: [your platform]
Protocol: [what the assistant calls]
## Never touch
- The live rail serving [the other team]: READ-ONLY. Snapshot
before any shared-environment write; prove unchanged after.
- Anything in .env: use it, never print it.
## Terms
- Nothing irreversible without my approval.
- No fix accepted without measured evidence.
- Verify against deployed state, never memory.
- Every temporary thing you add, you remove.
The proof standard is a skill — a named, repeatable test the teammate can be told to run, so “it works” has a definition instead of a feeling:
# .claude/skills/contrast-test/SKILL.md
---
name: contrast-test
description: Prove a rail runs AS the user — two test users,
same tool, different attributable answers.
---
1. Sign in as TEST_USER_A, then TEST_USER_B. Their passwords
are never stored here and never typed by the teammate.
2. Call the same tool endpoint as each user.
3. PASS only if the answers differ AND each answer is
attributable to its user in the audit log.
4. If the answers match, STOP. The rail is impersonating,
not running-as. Find which layer collapsed the identity.
And the never-touch list is not a polite request in a prompt — it’s a hook, checked in code before any tool call is allowed to run:
// .claude/settings.json (excerpt)
{ "hooks": { "PreToolUse": [{
"matcher": "Edit|Write|Bash",
"hooks": [{ "type": "command",
"command": "python .claude/hooks/guard.py" }]
}]}}
# .claude/hooks/guard.py — the never-touch list, enforced
import json, sys
PROTECTED = ["prod-rail/", "client-b/", ".env"]
call = json.load(sys.stdin)
if any(p in json.dumps(call.get("tool_input", {}))
for p in PROTECTED):
print("BLOCKED: on the never-touch list", file=sys.stderr)
sys.exit(2) # exit 2 = the call is refused, and the
# teammate is told why
Here’s the part I’d underline before you copy any of it.
Every tutorial on the internet can teach you that syntax — skills, commands and hooks are documented, learnable, commodity. What can’t be copied is what you put in them: which paths are sacred on your estate, what “proven” means for your systems, which terms you would never let a teammate operate without.
The three files above are small, but they aren’t trivial. They’re judgement, compiled.
And if they read as paranoia, consider how the people who make this tool run it on their own estate. Anthropic’s engineering team published their internal discipline this week: every operating agent gets a single-purpose identity carrying only the minimum permissions for its job — their incident-response agent can write docs, post in company channels and read production logs, and that’s all, which means it can diagnose an incident but never deploy the fix itself. Every agent action lands in the security log. And, in their own words: “we treat these agents as a new type of insider threat.” That’s the maker of the tool, running the tool on my terms. The blueprint isn’t eccentricity. It’s the discipline arriving — most estates just haven’t noticed yet.
Here’s what this means for you.
Your estate has the same five planes mine does, whatever your logos are — and somewhere in your company is an AI budget that has already been spent, waiting for exactly this kind of rail. When you next get some downtime, take one page and map your five planes. Who holds identity. Where a bridge would live. What sits in the middle. Which platform holds the data. What the assistant would actually call.
Write your never-touch list before anything else — then compile it: the three files above are your starter kit, with your estate’s names in the brackets. Then pick one cross-system fault you’d normally hand off, and run it as a pairing instead, with the instruction that changes the relationship:
Don’t theorise. Instrument, measure, and show me the evidence before we accept any fix. Nothing irreversible without me.
One rule for the session: every claim is provisional until you’ve both seen the proof.
If the estate you’d point it at is the one stuck at the security review: two minutes — find out what’s actually blocking it. Run As You is free at the end.
The next time the terminal’s open, notice which question you’re asking. “Write me this function” is the question everyone was taught. “Operate the estate with me, and show me your evidence” is the question the last nine months taught me — and the difference between those two questions is the difference between a tool and a teammate. Used with judgement, this is the fastest way I know to build things that pass a security review. Used without it, it’s the fastest route to an outage. The judgement, as ever, is the part that stays yours.
Until next time,
Chris
P.S. — The rail has a book. Run As You is my free field guide to the one decision this whole essay demonstrates — the assistant acts as the signed-in person: the badge, not the master key — plus the Four Questions to put to any AI proposal before the security review. Get it free here.