The evolution of an agent.
We build an agent the way it actually comes into being: layer by layer. Every part solves a concrete problem of the previous one - from the first LLM call to the swarm.
The agent harness.
Five parts turn a bare LLM call into an agent: conversation, identity, tools, boundaries. Each part comes with basics for everyone, experiments for members and deep dives for pro.
The LLM Call
One request, one response - the raw building block everything else grows from. And the key insight right at the start: the brain is not inside the agent. It's at the other end of the line.
Message History
After every answer we hang up - the next call starts from zero. Context only exists because we read the full transcript aloud at the start of every call.
System Prompt
soul.md - who am I today? Personality, role and rules as the very first message: how an agent gets its identity.
Tools & Loop
The LLM can only talk - acting is the harness's job. Tool definitions, execution and routing: this is where the agent loop emerges, and the language model becomes an agent.
Guardrails
The agent's house rules: what it must never do, how errors are caught - and why boundaries aren't distrust, they're architecture.
Free for everyone: the concept, the analogy, the why.
With a free account: experiments, quizzes and the deeper material.
For pro members: the depth for everyone who wants to actually build it.
The extensions.
Everything you bolt onto an agent - even a finished one like Pi or Hermes: memory, MCP servers, sidecars, channels & triggers, and eventually the swarm. The block grows from the front: parts that already have a page sit on top, the rest below them as a roadmap.
Memory
An agent never remembers - it re-sends. How information gets into the context at all, what travels once per session versus once per request, and when that justifies a service of its own next to the agent.
MCP servers
The protocol that makes a capability discoverable and callable. Why every harness used to write its own tool binding before MCP, what a server offers - tools, resources, prompts -, and which of the two transports is the right one when.
Sidecars
What sits at the other end of a tool: a stateless service next to the agent that offers one capability and keeps nothing once it has answered. Why that is its own container rather than a function inside the agent process.
Tool calling in production
Tool calls work in the prototype and break in production - not because of the model but because of six translations in between. What goes wrong, why it is so hard to see, and what you build against it.
Tiny Agents and the Compression Boundary
Two hundred tools do not fit into any context - and the tool list is the cheaper of the two problems. Why dynamic filtering falls short, and what a compression boundary does instead.
Guardrails in production
The house rules inside the harness are the first defence - but the harness is a party: it executes what the model says. In production a second control plane therefore sits outside it. What it sees, what it prevents, what it can only prove.
- Channels & triggers
In preparation
- Swarm
In preparation
The inference.
The brain at the other end of the line: which models exist, which engines serve them, what hardware they need - and how to compare them honestly.
How an LLM works
At the other end of the line sits no knowledge and no plan - just a machine guessing the next token. Why exactly that kind of guessing is enough to translate, program and argue is the founding question of Block III.
The model landscape
There is no such thing as "the LLM" - there are hundreds of models, in every size, open and closed. The good news: your harness stays the same. Only the number it dials changes.
What's inside a model download
"Running it locally" means: a folder with a few gigabytes in it. Which file does what - and why the smallest one of them, the chat template, decides whether your model answers or stutters.
Inference engines
A model file is just a bag of numbers. Turning it into an API that answers your call is the job of the inference engine - the record player that plays the record.
Hardware
Why does everyone talk about graphics cards when LLMs come up? Because memory is the hard limit: it decides which models you can even choose - and what every answer costs.
Benchmarks
Every week a new model "beats" all the others. Benchmarks turn that noise into numbers - useful for rough sorting, dangerous when trusted blindly.
Fine-tuning
Sooner or later every project says it: "let's just train the model on our own data". Usually that is premature. Fine-tuning teaches a model form and behaviour, not knowledge - and that distinction is where most of the misunderstandings sit.