THE OPERATING SYSTEM AROUND THE MODEL
A language model is half the machine. The harness is the other half.
Everyone meets a language model as a box you type into. The leverage is everything around that box — and I design and run these systems.
A harness runs the loop, memory outlives the session, one governed door reaches every tool, agents carry the work, and a safety model fails closed.
The operating system around the model — each node opens its section.
Blue pulses carry context and memory inward to the kernel. Purple pulses carry tool calls out to the gateway. Green pulses are sub-agents fanning out and reporting back. Watch the amber packet stop at the approval gate before it can leave the sandbox.
Start at the center. Behind the chat box runs a loop most people never see —
THE KERNEL
The kernel for language-model sessions.
The loop that runs every turn: read, act, check, repeat.
Gather context. Act. Verify. Repeat. — the agent loop an SDK runtime runs: the model decides, the harness manages context, dispatches tools, and gates every call through a hook before it executes.
The harness is not an agent. It is the loop every agent runs inside: inject context at session start, dispatch a tool, gate the call through a hook, append the result, repeat. The model is the CPU; the harness is the instruction cycle around it — and it is exactly what an agent SDK packages, the same loop that powers a coding agent or an embedded one.
Context injection at the start
At session start the harness loads the working set — conventions, the memory index, the files in play — straight into context. The model wakes up already oriented instead of guessing.
One dispatch, then loop
Each turn the harness dispatches a single tool call, waits for the result, appends it to the transcript, and loops. Nothing executes that the loop did not schedule.
Every call passes a hook
Before a call runs it clears a hook. PreToolUse can rewrite the call, allow it, or deny it; Stop decides whether the loop continues or halts. The hook is the gate, and the loop never skips it.
hooks fire at fixed points: SessionStart · PreToolUse · PostToolUse · Stop
The kernel runs the loop. But an unbounded loop that can touch the real world is dangerous — so the first thing I built around it is a wall.
ISOLATION
Deny by default. Fail closed.
Walls around the loop, so one slip never opens the door.
Anything not explicitly granted is already denied.
Containment is the wall around the kernel. A request earns its way in by clearing every ring; miss a single grant and it stops at the wall, not after the damage. Defense in depth means one failure never opens the door — there is always another ring behind the one that broke. At the base sits OS-level sandboxing — the same idea agent SDKs reach for with Linux bubblewrap or macOS Seatbelt — so a subprocess can be denied at the operating-system level regardless of what the model intended.
Rule-based denial
A static allow-list runs first. If no rule names the action, the action does not happen.
Context filtering
Untrusted text is screened before it reaches the model, so an instruction hidden inside a document cannot quietly become a command.
Worktree isolation
Code work runs in an isolated git worktree. A change stays contained to its branch until a human merges it.
Domain routing
Each identity is pinned to its own destination. An action aimed at the wrong place is denied at the boundary, before it is sent, not flagged after.
Per-scope authorization
Every backend is issued the narrowest scope it needs. A read token cannot write, and a write token cannot reach a backend it was never granted.
deny-by-default · defense-in-depth · fails closed
Containment decides what it's allowed to do. The next question is what it's allowed to remember.
PERSISTENCE
What an agent remembers, and how it stays bounded.
What the system keeps between sessions — and how it stays small.
Write · consolidate · retrieve. — short-term memory is the context window; long-term memory lives in external stores. The hard part is not storing — it is managing what stays.
Memory is not one store. The field borrows the split from cognitive psychology: short-term, working memory is the model's context window — its active scratchpad, bounded and ephemeral — while long-term memory lives in external stores read back on demand. Long-term subdivides into kinds: episodic experience, semantic fact, and procedural skill.
Working memory the context window
The active scratchpad for the current task. Fast, bounded, ephemeral — it is the short-term store every model already has.
Episodic
Specific past experiences and events — what happened in this task or an earlier session. The system's recallable history.
Semantic
Durable facts about the user, the domain, and the world. The knowledge that holds true beyond any single session.
Procedural skills & rules
How-to procedures, skills, and conventions — sometimes implicit in the model's weights, sometimes written out as explicit guidelines the loop reads back.
- write
- consolidate
- retrieve
the field, for reference — where mine sits
These name the same kinds mine does — episodic, semantic, procedural. My choice: consolidate every layer into one knowledge base, rather than stitch several stores together.
Mem0
a memory layer that extracts salient facts, stores them, and retrieves them across sessions
Zep
temporal knowledge-graph memory — tracks how facts change over time and supersedes stale ones
A-MEM
Zettelkasten-style agentic memory — atomic notes that link to and update one another
LangMem
an SDK for long-term memory, modelling semantic, episodic, and procedural kinds
MemGPT / Letta
virtual-context paging — an OS-style hierarchy that pages memory in and out of the window
Pure embedding search finds the passage that answers a question, but stumbles on whole-corpus questions no single chunk can hold. The shift is from vector-only retrieval toward hybrid vector-plus-knowledge-graph: extract a graph from the corpus, then retrieve over its structure for better global reasoning and provenance.
Everything writes to and reads from one durable, queryable knowledge layer — raw capture, consolidated, into a single encyclopedia every subsystem queries. The one wiki to rule them all.
This is the one I run: every subsystem reads and writes that single base, so an agent today can pick up what an agent learned months ago.
working · episodic · semantic · procedural — bounded by consolidation
Memory feeds the loop its context. To change anything in the real world, that loop still has to reach out — through one door.
THE CONTROL PLANE
One governed door to many tools.
One front door so the model reaches many tools through a single, watched channel.
Routing · scoped auth · rate-limit · observability. — a proxy in front of many tool backends is a control plane, not a context-compression trick. It turns scattered server chaos into one governed, auditable surface.
The Model Context Protocol is the open socket — "USB-C for AI" — that lets a model plug into external systems through one uniform interface, collapsing a custom connector per tool into a single standard. A gateway sits in front of many MCP backends and presents them as one governed surface: it routes and manages their lifecycle, hands each backend its own narrowly-scoped credential, enforces rate limits, and traces every call for audit. The agent never holds the raw secrets, and one place sees everything that happened.
the tool types an agent calls
MCP servers
standardized tools, resources, and prompts behind the open protocol
CLIs / shell
local command-line tools and scripts — the shell is itself a universal tool surface
HTTP APIs
direct calls to web services, each with its own auth
Workflows
a deterministic, pre-defined orchestration invoked as one callable tool — a fixed control-flow graph of model and tool calls
Routing & lifecycle
One place discovers, deploys, updates, and retires backends. Session-aware routing keeps a given session hitting a consistent server instance.
Per-backend auth isolation
Each backend gets its own narrowly-scoped credential. A read token cannot write, and a token for one backend cannot reach another. The agent never holds the raw secrets.
Rate limits & observability
Quotas at the hub protect backends from a runaway agent; centralized tracing gives one auditable record of every tool call the system ever made.
routing · scoped auth · rate-limit · observability
One governed door is how the work leaves the building. The runners that do the work sit behind it.
EXECUTION
Skills are invoked. Agents run.
You start a skill; an agent starts itself.
Fixed rails, or self-driving. — a workflow runs through predefined code paths and is repeatable; an agent directs its own process and tool use at runtime. Two ends of one spectrum, not competitors.
A skill is a guided workflow a human invokes on demand. An agent is a role-based runner with its own loop. The line between them is who pulls the trigger, and how long the thing lives once it is running. The same distinction runs deeper: a workflow is deterministic — its control flow is known in advance — while an agent decides the path as it goes. The rule of thumb is to use the simplest thing that works and reach for autonomy only when the task genuinely needs open-ended decisions.
Run modes on two axes
A daemon stays up. A supervised loop runs on a budget. A cron agent wakes on a schedule. A hook agent fires on an event. A skill runs only when a human calls it. Plot them on autonomy against trigger and the whole roster fits on one grid — one generic way to classify runners.
Sub-agents keep contexts clean
A spawned sub-agent gets its own isolated context window, system prompt, and restricted tool set — sometimes a different model. One investigation's context never pollutes another, and independent work runs in parallel.
pipeline
Prompt chaining — a fixed sequence, each step feeding the next.
routing
Classify the input, dispatch to a specialized handler.
fan-out
Parallelization — subtasks run concurrently, then aggregate.
supervisor
Orchestrator-workers — a central model delegates and synthesizes.
review
Evaluator-optimizer — one produces, another critiques, loop until it passes.
the field, for reference — where mine sits
These are the frameworks on offer. The patterns above are the ones I compose by hand to run my own work.
LangGraph
graph-based orchestration with explicit state and control flow
CrewAI
role-based multi-agent teams that collaborate on a task
AutoGen
a conversational multi-agent framework — agents exchange messages
OpenAI Agents SDK
handoffs, guardrails, sub-agents, and tracing
Claude Agent SDK
the same agent loop, packaged as an embeddable library
The agents on this page aren't a diagram for show — they're the roster I push my own work through every day.
workflows are deterministic · agents are autonomous · the patterns compose
Agents that run themselves are the point — and the risk. Which is the only reason I let them run unsupervised: a rule that makes it safe.
THE RULE OF TWO
Give an agent any two of three powers — never all three.
Why it's safe to let it run alone: it never holds all three powers.
at most two of three every external send gated — any two of the three dangerous capabilities are workable; the third is never granted silently — it becomes a stop a human approves.
Three capabilities are dangerous together: access to untrusted input, access to sensitive data, and the ability to change external state. Any two are workable. All three is the precondition for an exfiltration or a runaway action — so the third is never handed over quietly. It converts into an approval.
The Rule of Two
Hold any two and the agent works unsupervised. Reach for the third and the system turns it into an approval, not a capability. The rule itself is the blast wall.
A control loop watches the whole thing
A MAPE-K loop runs over the system: Monitor, Analyze, Plan, Execute, over a shared Knowledge core. The system observes its own behaviour and adjusts.
Gated sends, tamper-evident log
Every action that leaves the building passes an approval gate — no external send is exempt. Each decision is written to a hash-chained log: change one entry after the fact and every entry after it stops matching.
- #1a1f3…
- #29c0e…
- #37b22…
at most two of three · every external send approved · hash-chained audit
Worked exampleA document arrives in a small business owner's inbox. A hook agent picks it up — untrusted input. An injection scan runs, the harness extracts the fields, memory supplies the vendor's history. A skill drafts a reply and a ledger line. But the task now touches sensitive data and would make an external state change — three of three. The Rule of Two forces a stop: read and draft are allowed; the send and the write wait for a human. Draft-only, by construction.
This is the rule I trust enough to let agents act on my behalf: the dangerous third capability is the one thing they can never grant themselves.
Six subsystems. Step back, and they're one machine — and that machine carries real work.
THE WHOLE MACHINE
How the parts fit together.
Step back: six subsystems, one machine that carries real work.
Build-organ ships → runtime runs → tools act → memory persists → operational layer governs. — a closed control loop, not a stack of unrelated boxes. Each layer hands off to the next.
Step back and the subsystems relate as one machine. The runtime is the agent SDK — the harness loop, tool-calling, sub-agents, hooks, and sandboxing; everything an agent executes runs here. The build-organ is an internal developer platform: a software catalog, golden paths, and self-service scaffolding that ships products and services without each team rebuilding the foundation. Those products run on the runtime, call tools through the gateway control plane, and use memory for context that outlives a session.
Wrapping all of it is the operational layer — governance, human-in-the-loop approvals, and observability that keep autonomy safe and auditable. The relationship is the point: the build-organ builds the services, the runtime runs them, the tools act, memory persists, and the operational layer governs. A microkernel of orchestration, safety, and memory at the core, with everything else swappable.
- Software catalog
- Golden paths
- Self-service scaffolding
- Observability
An internal developer platform: build, deploy, and operate services without re-deriving the foundation each time.
How the layers relate
Build-organ
ships
catalog, golden paths, and scaffolding produce products & services
Runtime
runs
the agent-SDK loop executes them: sessions, tools, sub-agents, hooks
Tools
act
MCP, CLI, API, and workflows reached through one gateway control plane
Memory
persists
working and long-term stores, consolidated into one knowledge base
Operational layer
governs
governance, human-in-the-loop approvals, and observability wrap the running services — the Rule of Two and the audit journal live here
What it carriesThis is the load I run it against: the recurring operational work of several small organizations and a personal infrastructure stack — more obligations than anyone can hold in their head. Under this architecture the toil becomes a team of agents: a cron agent reconciles the books overnight, and has for months; a hook agent captures every session's decisions into memory; an on-demand skill drafts routine correspondence. I stopped doing the work and started steering it — and every action that would leave the building waits at an approval gate.
WHO BUILT THIS
The leverage isn't the prompt. It's the system around it.
Who builds this — and what this page is really proof of.
I'm Christian Juul Wendell. I design and run the operating system around the language model — the harness, the memory, the gateway, the agents, and the safety model on this page are the ones I actually use. The point isn't any single subsystem; it's that they compose into something that carries real work, with a human in the loop where it counts.
This site — its copy, its diagrams, its structure — is itself an output of that system. Built with Claude Code, by the system it describes.
Bounded autonomy. Reversible by default. Audited always. A human in the loop at the right time — complemented, not replaced.