Knowledge changelog

MCP servers

Step 8 of the build diagram was a tile without a page. Now the component is there, in three tiers. Basics: what the protocol solves, why every harness used to write its own tool binding before MCP, tools versus resources versus prompts, and when stdio versus Streamable HTTP. Pro builds a server of your own, with the service under mcp/ in this repo as the case study - five files, sixteen editorial tools, eleven for the simulation worlds, and the two design decisions everyone otherwise trips over twice. The deep dive takes on operation: tool poisoning and rug pulls, permissions per tool rather than per server, session caps and reaper, and the auth model of several endpoints in one container. The sidecar page now links to it where it previously only mentioned it.

Practice world - an emulated MCP endpoint

A practice world you create yourself: at /weltmodell an MCP endpoint appears that declares a scenario's tools like any other server and runs none of them. Every call goes to a world model together with the session so far, and the observation it predicts is the result - so the world has state without anyone storing one. Two scenarios are ready: "Elektro Rauner" with 48 tools across eight areas, and the slim "Stadtbücherei Ahlbeck" with 20 across four. That makes it possible to practise tool selection among many tools without building a system first. That all of it is invented is part of the contract, not a footnote: it is in the instructions to the client, in every tool description, on every answer and in every log line. Four caps bound a world - calls, context length, response time, lifetime. The rule that goes with it: practise in the invented world, measure in the real one.

Benchmarks

New chapter "World models - and what AgentWorldBench measures" in the Benchmarks building block. A world model does not predict the next action but the next observation: it plays the environment that gets acted in. Qwen-AgentWorld covers seven of them (MCP, search, terminal, SWE, web, operating system, Android). The AgentWorldBench values as published on 24/06/2026 - 58.71 for the 397B against GPT-5.4 at 58.25, Claude Opus 4.8 at 56.59 and Gemini 3.1 Pro at 54.57 - appear in the chapter as third-party figures, together with the point that what is measured there is simulation quality and not the ability to act. Plus the use cases (practice environments nobody has to build, prediction as preview, data generation with a caveat), the three limits (drift, no truth, nothing gradable) and how the /welt endpoint in this repo is built.

The world, or a model of the world

The difference between "the world answers" and "a model predicts how the world would answer" - demonstrated on two MCP endpoints of this platform. The same question goes to the CRM of Simhaven (/sim-crm, rows in a Postgres table) and to the practice world (/welt, a world model with no system behind it). Both answers are neatly formatted JSON, both look equally plausible. The obvious test fails: three identical calls in the same world return three character-identical answers, because the session history travels along. They only diverge across two freshly created worlds from the same scenario - the same firm carries customer number K-1156 in one and K-1051 in the other. They agree exactly where the scenario text pins something down (38 property managers, Kliem as K-1077, Trienekens as K-1042); everything else is invented, in the same format, unmarked. Hence the three consequences: a benchmark without real execution measures storytelling, an agent must not grade its own success report, and fine-tuning on invented tool answers confirms itself. The rule that follows: practise in the invented world, measure in the real one.

Fine-tune FunctionGemma on your own MCP

The FunctionGemma chapters stop short of the training, because the vendor publishes no training parameters. The new course catches up, against eleven real tools from the sim worlds of this repo (mcp/tools/sim_calendar.ts and sim_crm.ts). Six chapters along the order from the building block: log the starting state, build the test bench S1-S5 as runnable code, put the raw specialist in front, distil a dataset from runs of the large model, run the LoRA, build the switch into the harness. Three measurements on the same test bench, all from a run that actually happened on a DGX Spark: large model 95.2 per cent of tasks completed at 6.42 seconds, raw specialist 73.8 per cent at 0.20 seconds, fine-tuned specialist 90.5 per cent at 0.16 seconds. Test stage S5 (mandatory value missing, ask back instead of inventing) jumps from 50 to 87.5 per cent and thereby lands on the value of the large model - on eleven training examples. The open temperature question from chapter 06 is settled too: the vendor figure of 1.0 costs 8.7 points raw, and only 1.6 after the fine-tune.

Build an MCP server that does something

MCP was mentioned everywhere on the platform and built nowhere. The new course builds a server that does something: the Simhaven helpdesk with eight tickets, a product manual and nine tools an agent uses to clear the inbox. Seven chapters from the empty server to a container of its own - both transports with a decision criterion, the tool description as the prompt part of the tool, one transport per session including reaper and caps, two auth models side by side (service token and case-bound token), the three typical failure modes triggered rather than claimed, and operations with a health check and one log line per call. Every printed output is measured: 130,152 characters for a tool that returns the whole inbox, 5,223 with a cap. The MCP component links to the course, and the course quotes the service under mcp/ in this repo.

The model landscape

In the model landscape the gap sat in the middle of the component: 659 words of basics below, a pro tier with over 2000 above, and a table of contents in between. The deep dive is now written out. Dense against mixture-of-experts with our own numbers instead of a general explanation, namely the measurement error in our own duel volume, whose first edition put an MoE against a dense model and therefore measured a twelve-point gap where the repeat with matching designs left 5.8. Then what post-training leaves behind in the answers: language leaks from the data mixture, the tool grab with no occasion on a task that needs none, and reasoning that shifts the cost from the number of steps into the text between them. A licence section that exists nowhere else, with the three cases from our own catalogue and what applies when you pass on a fine-tuned model. And finally the order from the task to the model, with the measurement series as the reason why twenty cases of your own beat any leaderboard.

Hardware

As with the neighbouring component, two outlines and no text sat above the basics. Now the calculation is there. The pro tier brings weights, KV cache and overhead together into one number, puts bandwidth beside it as the second figure (speed hangs on the memory bus, not on FLOPS), sorts consumer, workstation, data centre and unified memory by what the premium actually buys, and works three examples through step by step: a MacBook Pro, an RTX 4090 and a small server for eight people, including the point where dense and MoE overtake each other. The deep dive takes the case after that: tensor versus pipeline parallelism with their downsides, what NVLink really saves over PCIe (almost nothing at decode, a factor of fourteen at prefill), why ten percent of the layers in RAM halve the speed, and the formula that turns purchase, power and utilisation into one number per million tokens. Every number comes from the same formulas as the page's own VRAM calculator and from the model cards.

Inference engines

Above the basics the component held two tables of contents and no text. Now there is something there. The deep dive explains what makes an engine fast: PagedAttention as page management for the KV cache, continuous batching with iteration-level scheduling, quantisation in the two places where it behaves differently, and the knobs on your own server in the order in which they pay off. The pro tier puts llama.cpp, vLLM and SGLang side by side, places TGI, TensorRT-LLM, MLX and ExLlama, explains why concurrent requests are cheaper than sequential ones, and closes with three recommendations for single seat, small server and multi-user operation. Every number has an origin: either our own measurements from the DGX Spark or a named paper.

Fine-tuning

Block III gains a seventh component: fine-tuning. The basics settle what fine-tuning actually changes - form and behaviour, not knowledge - and why prompt and RAG come first, plus the difference between full training and a LoRA adapter. The pro level takes the decision apart: three conditions that have to hold beforehand, where the dataset comes from, why distilling from the large model's runs is the normal route, and why the awkward cases belong in it. The deep dive goes into production - switching adapters on in vLLM, llama.cpp and Ollama, several of them on one base model, the versioning triple of adapter, dataset and test bench, and the chat template trap.

workshop:unternehmen-03-vom-schattenlauf-zum-selbstlauf

Part 3: how a tailored agent gets into operation. Four stages - shadow run, proposal, sampling, autonomous operation - and the ascent hangs on measured numbers instead of confidence. The intervention rate is the load-bearing one: it says when the next stage is due, and it is the reason every model change demotes an agent by one stage.

workshop:unternehmen-02-die-neun-achsen

Part 2: the nine decisions the ceiling is made of. Every axis carries levels, every level an evidence sentence and the jump point at which testability tips over. Together they span the state space - and that, not the number of tests, decides whether an agent stays checkable.

workshop:unternehmen-01-die-eingezogene-decke

Part 1 of the series “The Enterprise Harness”: why an agent inside a company gets built differently from one on your own machine. Not because it is allowed to do less - but because nobody is sitting beside it pressing Ctrl-C when it takes a wrong turn. The ceiling you build in for it is the answer to the question about the worst Monday morning.

Cut

The tailoring tool is live: a workbench tool where an enterprise harness gets set up for exactly one process. Nine axes with levels - from effect on the world through to escalation. Push one up and the panel beside it says in that same moment what has to be proven for it and which components belong to it; a rule set locks combinations that cannot be evidenced. Plus the four operating stages shadow run, proposal, sampling and autonomous operation, ascent by numbers instead of by trust, the build file to print and take along, and the build brief as a starter package. The first cut is open to every member, further processes are Pro.

workshop:harness-01-llm-call

The build prompt now has a setup automation that applies to all ten parts: the coding agent installs, creates folders, symlinks the start command into the PATH, puts the key into its own file in the home directory and sources it from the shell configuration. Questions only when two answers would lead to genuinely different results. This version came out of a real run, and the questions were the most annoying part of it.

workshop:harness-00-einstieg

The introduction now says how little you type yourself: every session has a build prompt, the coding agent installs, sets up and runs the acceptance test itself in a fresh terminal session. Part 1 creates a serien-prompt.md for that, holding your answers for all later sessions.

Why the same question takes 150 seconds one time and 4 the next

Why the same question takes 150 seconds once and 4 seconds the next time: 150,000 tokens of documentation, one model on a DGX Spark, and the order inside the prompt alone decides a factor of 36 in time to first token. With measurements, four scenarios and the cache killer almost everyone builds in without noticing.

Memory

Memory is the first component from Block II with the section "How do the others do it?": storage form, write path, read path, scope, upkeep. It sits right beside the implementations Honcho, Mem0, LLM-Wiki and OKF, and shows what the six harnesses built themselves before binding a service.

Guardrails

The Pro tier of Guardrails now carries the section "How do the others do it?": approval model, isolation, inbound and outbound side, budget. Six harnesses, every cell with a source-code citation from the pinned repo commit. With that, all five components of Block I have the comparison.

Tools & Loop

The Pro tier now carries the section "How do the others do it?": tool definition, execution, return path and loop termination in six real harnesses, every cell with a source-code citation from the pinned repo commit.

System Prompt

The Pro tier now carries the section "How do the others do it?": sources, dynamic parts, user control and caching of the system prompt in six real harnesses, every cell with a source-code citation.

Message History

The Pro tier now carries the section "How do the others do it?": where the history lives, how it survives, what happens when it gets cut, and how six harnesses solve that in source code. Every cell with a citation and a permalink to a pinned commit.

The LLM Call

The Pro tier now carries the section "How do the others do it?": six real harnesses (OpenClaw, Hermes, Pi, HybridClaw, DeepSeek Harness, NanoClaw) across five dimensions of the LLM call, every cell with a verbatim code citation and a permalink to a pinned commit. Plus matrix, A/B duel and code detective.

How do the others do it?

"How do the others do it?" now has a place of its own. Until now the section sat at the bottom of four component pages; now there is a hub with three ways in. Through a challenge: "The context window runs out", and below it how all six harnesses solve that, across message history, compaction and memory, with a pattern sentence per harness. Through a topic: eleven layers instead of four, newly added guardrails, memory, compaction, MCP binding, triggers & channels, tool routing & skills and sub-agents, each as a matrix with source-code citations, A/B duel and code detective. And through the portrait of one harness: every layer of OpenClaw or Hermes in one piece, as an architecture profile. No citation is invented; the pages sort the same cells differently.

workshop:harness-04-tools-loop

With part 4 your agent is complete: conversation, identity, tools, loop, all of it in about 200 lines without a single dependency. It is the same engine that runs inside the big coding agents, just with far more comfort around it there. The chapter now carries the session itself, with sequence, time budget and the points where the loop tips over.

workshop:harness-03-system-prompt

Part 3 gives your agent an identity, and the chapter now guides you through the session rather than just the prompt. Sequence with a time budget, what matters in describing the role, and what sounds different afterwards.

workshop:harness-02-message-history

Part 2 now explains the session instead of merely announcing it. The gap from part 1 gets filled: the model knows nothing of the first call when the second arrives, and the message history is the answer to that. The sequence is laid out with a time budget, along with the points where the thing is decided and what runs in your terminal at the end.

workshop:harness-01-llm-call

Part 1 of the harness series has become a chapter. Before, it was essentially a build prompt with a few sentences in front of it, so anyone who read the series without building it came away with nothing. Now the part carries the session itself. The sequence is laid out in four steps with a time budget, from preparation through the interview and the build to sign-off, along with what matters in the four questions your coding agent will ask you. At the end you ask your agent a question in the terminal and get an answer. Two things you see with your own eyes: that it really is no more than one call, and that the call stays stateless.

The LLM Call

The building block now talks to qwen3.8-27b-fast instead of qwen3.6-35b-fast: the GPU slot holds only one large model, and Qwen 3.8 is what sits there now. The example calls and the downloads are affected. Plus a correction on the pro level: the paragraph on the context window named a separate output cap that no longer exists in that form. What is correct is that max_tokens may not ask for more than the single 262,144-token window.

workshop:harness-00-einstieg

There was nothing before part 1 of the harness series. Part 0 fills that gap: nine sessions, and afterwards an agent you built yourself runs on your own machine, about 200 lines with no framework underneath. The introduction says up front what that is good for and what it is not. Tools at this level are read a file, write a file, look at a folder, and out of those come both a to-do list and a small coding agent where only the system prompt differs. What an agent is comes from the system prompt; what it can do comes from the tools. The system check on the page tests your machine before the 45 minutes of the first session are spent.

Benchmarks

Model report 04 "Qwen vs. Qwen" has been recalculated for a second edition — with the right opponent. The first version compared Qwen3.8-27B against the mixture-of-experts Qwen3.6-35B-A3B; that is not its predecessor but a different architecture from a different line, and it inflated the gap to twelve points. Now two dense 27-B models face each other on the same endpoint: 744 scored runs across all 20 tasks, 88.4 against 94.2 percent. The result is narrower and more interesting — the new generation loses nine of 38 cells. It wins where a task contains a question of doubt (tidy-up, work rules, course corrector, building an application) and loses where the task brings its own diagnosis: on the error reader the old generation passes 20 of 20 in 61 seconds while the new one thinks its way into the time limit four times. Plus the token bill (+32 percent median at practically the same number of moves), all 65 failed runs on both sides individually, and 26 charts. As a PDF in the library, Pro tier — and free at /gratis/qwen-duell.

The model landscape

Qwen3.8-27B has joined the model landscape - the generation step above Qwen3.6-27B with native image input and switchable thinking, complete with its field report from agent operation: 343 of 364 scored runs passed (94 percent), 1,344 tool calls under Hermes without a single error. Measured 14 August 2026.

Benchmarks

AgentLens now has coding tasks - and a test bench that, for the first time, runs something instead of reading it. For the two new tasks the resulting application is started after the run and questioned over HTTP: first the ordinary requests, then a restart of the service, then the same question again. Anyone who kept state in memory only fails at exactly that point. Task one is a brownfield case (a running API with three defects, reported as complaints from operations rather than as bug descriptions), task two builds from scratch. Both run on a third harness which, unlike the two lean ones, brings a furnished development environment - what should be measured is programming skill, not survival in a bare environment.

The model landscape

The model card for Qwen3.6-35B-A3B now carries its field report from agent operation: 720 scored runs across eighteen tasks, 82 percent with the thinking block, 78 without - and why the average hides the interesting part. Measured 13 August 2026.

Benchmarks

New model report 02: Qwen3.6-35B-A3B evaluated across the complete AgentLens catalogue - 726 runs, eighteen tasks, both harnesses, and as a hybrid twice over: with and without the thinking block. The volume measures what audible reasoning buys and costs in agent operation, with trace evidence for every finding - as a PDF in the library, Pro tier.

Benchmarks

A new genre in the library: model reports. The first volume evaluates gemma-4-31B-it across the entire AgentLens catalogue - 180 runs, eight tasks, both harnesses, 79 pages. A findings table up front names the five places where the model did not get through - each with evidence, cause, remedy and the building block that explains it. The volume then explains the measurement setup, then documents every task individually with real numbers and trace excerpts, and names the flaws of the test rig along with corrected rates: thirteen sim runs that never reached their world, and two unequally equipped sandboxes. Pro tier, card on the AgentLens page.

The model landscape

The model browser now also shows how a model holds up when an agent actually drives it: models that have been through an AgentLens batch carry a field report in their detail panel, with its own measurement date. First up is Gemma 4 31B from the CRM batch of 13 August - one pass in twenty attempts, and that one came from bundling its tool calls.

Tiny Agents and the Compression Boundary

New in the library: workshop volume 05 "Tiny Agents" - the companion book to the station. 79 pages, 26 chapters: the two problems, the registry with veto and abstain, the brief/digest protocol with hard budgets - plus the operations part with a token-by-token walkthrough, month three, model swaps and eight failure patterns. Pro tier, card at the top of the station.

Hardware

Four new devices in the VRAM calculator: NVIDIA DGX Spark, MacBook Pro M5 Max, Mac mini M4 and Mac Studio M3 Ultra. Memory requirements can now be checked against the machines that actually sit under desks - including the cases where plenty of memory meets narrow bandwidth.

The model landscape

The model browser grows from twelve to eighteen cards - all six additions are models AgentLens is currently benchmarking itself: NVIDIA's Nemotron 3.5 Lightning and Nemotron 3 Nano (Mamba hybrid MoEs for a single GPU), inclusionAI's Ling-3.0-tiny (7.9B MoE under MIT), Google's Gemma 4 in two builds (26B-A4B as MoE, 31B dense - both multimodal, both Apache 2.0) and Poolside's Laguna-S-2.1 (118B-A8B for agentic coding). Every card is verified against its Hugging Face repo and, as always, says what you'd use the model for and why it's on the list.

Benchmarks

The benchmarks building block gets its counterpart for real: AgentLens, the platform's own benchmark. Models receive real agent tasks - creating and restructuring files, analysing a server log, cleaning up a customer list, plus the parcours worlds calendar diplomacy and CRM caretaker as well as memory tasks across several conversation turns - and solve them in two real harnesses (Pi and Hermes), repeated per cell. Every run is fully recorded: under "Discover" sits the results overview with pass@k versus pass^k, and behind every number lies the clickable trace - every tool call, every result, every failed attempt, failure classes from ghost call to error spiral flagged automatically. With a free account you see released models and complete sample runs; the full matrix with model profiles and the harness comparison belongs to Pro. The methodology has its own page on the building block.

How an LLM works

Block III now starts on the inside: how an LLM works. The station makes good on the sentence the LLM call left unproven - that a huge, clever random generator sits at the other end of the line. Freely accessible: the single task (the next token, in a loop) with a sampling explainer for deforming the distribution; for members, the path through the machine - embeddings, attention read off a heatmap, the MLP as knowledge store, the stack up to the finished distribution, and the three training phases from continuer to assistant, with its own riddle wall. In the deep dive for Pro: hands-on backprop, the scaling laws, and why hallucination is not a malfunction but the task. Also new in the library: the German-language workshop volume 04 on the subject - 73 pages from the wager to the consequences for agent building, with a numbers walkthrough, glossary and sources, as a PDF for Pro members.

Guardrails in production

New building block in block II: guardrails in production. The house rules from block I live inside the harness - but the harness is a party, it executes what the model says, and not every agent runs through your code. This station takes up the control plane outside it: what sits in the harness and what in a proxy, what prevents live and what only proves after the fact, what a rule guarantees and what a detector merely makes more likely. The problem and a gate you switch yourself are free at the top; below it, eight chapters for Pro members: the damage catalogue, the classification map on four axes (location, timing, effect, decision), the gatekeeper, the detectors with their real rather than advertised numbers, the entry and exit gate, the handbrake at the action level, and the limits - why no filter closes prompt injection. With two new interactive surfaces, including the filterable concept matrix. And at the top of the page, the German-language workshop volume on the subject: 98 pages, the most extensive of the series, as a PDF for Pro members.

Benchmarks

The benchmarks building block gains a tool and a measurement series. The "input format" lab takes your own material - or one of three examples: prose, a table, a navigation menu - builds four versions of it with identical content (plaintext, Markdown, HTML, JSON) along with token counts, and runs two of them blind against the same model. Which side was which format is revealed by the server only after you have judged. Sliders for context length and the position of the material are part of it, because otherwise you measure lost-in-the-middle and call it a format effect. Beside it stands the controlled twin: the same haystack, a fixed question set with known answers, three needle depths, several seeds, temperature 0 - with confidence intervals that say so plainly when a lead is still noise. Counting tokens is free; the comparison needs an account.

workshop:fs-01-sehtest

The third workbench series has arrived: "The AI driving licence", a one-day workshop for people who operate AI rather than build it - no code, no API. Nine modules, from the eye test through the question of why the thing invents things without lying, to traffic rules, vehicle knowledge and a working day with AI. It ends with the exam, and the exam now lives on the platform instead of on paper: fifteen questions from the day's modules, marked on the server, and from twelve correct answers a record with date, scope and issuer - one that says explicitly what it is not. You can sit it without an account, via the share link of a learning journey. Two volumes come with it: the participant booklet to take home (36 pages, a double spread per module with practical steps, prompt patterns and space for notes; from member, and via the share link without an account too) and the trainer's guide with the direction for the day (78 pages, minute-by-minute plans, opening scripts, exercises, exam answers, "what to do if …"; from teacher).

Multica

New in the curated repo collection: Multica - a board on which an agent is assigned like a colleague. With one agent things stay clear; with the third they tip over. The Go part is worth reading because the operational questions that start with the second agent each sit in their own package: who gets a task, which machine it runs on, what is retried after a failure, and how a run is logged so it can be replayed.

Why your 8 GB model needs 20 GB of memory

New Aha! piece: why your 8 GB model needs 20 GB of memory. The file size is only the first item - on top of it sits the KV cache, which grows with every token in the context and again with every concurrent request. Worked out on Qwen3-VL-8B-Instruct, including the knobs that actually help.

Hardware

The hardware building block now has a VRAM calculator. Model, quantisation, context length, concurrent requests and number of cards go in; a stacked bar against the chosen GPU comes out - and the sliders show you when the KV cache overtakes the weights, and what happens when it is not one person asking but five at once.

Memory

The memory building block has a new level: below the concept there are now data sheets on the systems that implement it. Four are in place - Honcho (memory as a model of the user rather than a list of facts), Mem0 (the classic entry point: an LLM distils statements, a vector store finds them again), LLM Wiki (linked markdown pages, navigation instead of similarity search, worked out on this repository's own memory) and Google OKF (the Open Knowledge Format held against the same spec). New at the top of the page: the workshop volume on the subject, 97 pages as a PDF for Pro members, with a chapter on growth, hidden LLM costs, deletability and migration (German-language edition).

Hugging Face for beginners

New beginner course: Hugging Face for beginners. Eight chapters against the assumption that the platform is a download counter for model weights - reading Hub repos and judging whether they can be trusted, the account and the CLI that has been called `hf` since July 2025, a model on plain CPU with a pinned commit, using datasets by streaming and publishing your own. The heart of it is chapter 05: from an empty folder to a publicly reachable Gradio demo on free hardware that also ships an MCP endpoint, making it a tool for your own agent. It closes with the question of where the compute comes from - including the answer to where your data is processed along the way. Reproducible without a GPU of your own and without a paid account.

workshop:harness-09-tool-routing

The harness course now comes with a companion booklet, "Der kleine Harness": a 26-page PDF book in the workshop-book design that condenses the nine parts of the series - what was built, the core code and the discovery of each chapter. You will find it on the workshop overview and at the end of part 9 (German-language edition).

workshop:tiny-01-capability-card

The workbench gets the sequel to the harness series: "Your agent learns to delegate", five parts in which your harness becomes a host agent with a compression boundary. Part 1 gives every capability a capability card, part 2 builds the concierge that routes without an LLM call, part 3 teaches it to say no honestly, part 4 draws in the compression boundary, and part 5 makes sure nothing is lost when things are condensed. As in the harness series: copyable build prompts, built against the real API.

Build your own PyTorch

New build-it-yourself course: build your own PyTorch. Tensor, autograd, training loop - built by hand in eight steps with NumPy and without torch. From your own tensor class through the heart of the matter, autograd, layers and ReLU, loss and SGD to the training loop, the data loader and the proof: in the end your own framework separates a dataset with over 90 percent accuracy. A ninth chapter shows how to run the course as a workshop, and two skill packs for Claude Code are available for download - one that coaches you, one that drives to the goal.

Build your own tiny agents system

New build-it-yourself course: build your own tiny agents system. What the building block explains, you build here in eight steps - a concierge that routes without a single LLM call, a runner with a fresh context per assignment, a hard compression boundary in between. From measuring the problem through the capability card, the positive index, veto and abstain to brief, digest and budget, the artifact store and a closing measurement of whether any of it actually helps. No framework, no vector database, against any OpenAI-compatible endpoint.

Tiny Agents and the Compression Boundary

New building block in block II: tiny agents and the compression boundary. One floor above the individual tool call sits the question of which of two hundred capabilities a model gets to see at all - and the more expensive second one: what their outputs do to the context. The two are constantly confused, although they are orders of magnitude apart. The introduction and the chapter "Two problems, two orders of magnitude" are free; below them six chapters for Pro members: the capability card, the concierge, why abstaining is a feature, brief and digest, the artifact store - and finally the arithmetic of what all of this costs.

workshop:harness-01-llm-call

The workbench has its first coherent course: the harness series, nine chapters in which you build your own agent harness. From the LLM call through message history, system prompt, tools & loop, guardrails, memory, channels & triggers and context compaction to tool-call optimization, where a small model handles the tool calls while the big one thinks. Every chapter ships copyable build prompts, and you build against the real API instead of a mock-up. Findings from the joint trial run of the first four parts flowed back into the chapters - among them the case of the model that acknowledges without ever touching the tool, now part of the acceptance checklist.

The LLM Call

The LLM call gains two interactive surfaces. The Jeopardy-style quiz wall tests what stuck from finish_reason, max_tokens, stop words and model choice - four categories, four point values, an explanatory answer for every question, played solo, full screen, or hot seat with two to four players. In the deep dive, the tokenizer playground now offers a second mode: the BPE run from corpus to vocabulary, merge by merge.

Sidecars

Sidecars: a new section on what comes back through the process boundary. Worked through on a real session in the session viewer - three curl calls dump 52,489 characters into the context, 43.5 % of the entire history, and the most expensive single message is 25,400 characters of three error pages. A sidecar returns the result instead of the raw material. Including the honest counter-check: saving context alone is not yet a reason for a sidecar.

Tool calling in production

New building block in block II: 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. The problem and the chain arithmetic are free at the top; below it, seven chapters for Pro members: failure catalogue, constrained syntax, toolbox, repair, receipts - and finally FunctionGemma, the 270-million-parameter specialist that stands next to the large model rather than in its place. With five new interactive surfaces - and, at the top of the page, the German-language workshop volume on the subject, 90 pages as a PDF for Pro members.

Benchmarks

New building block: benchmarks. Every week a new model "beats" all the others. Benchmarks turn that noise into numbers - useful for rough sorting, dangerous when taken on faith. The block walks through the names you meet everywhere and shows what they measure, and what they do not.

Hardware

New building block: hardware. Why does everyone talk about graphics cards when the topic is LLMs? Because memory is the hard limit: VRAM decides which models you can pick at all, and what every answer costs. Worth reading even if you never buy a GPU - it explains the prices and the choices.

Inference engines

New building block: inference engines. A model file is just a bag of numbers. Turning it into an API that answers your call is the engine's job - the record player for the record. It produces the answer token by token and keeps that fast with a KV cache and batching.

What's inside a model download

New building block: what is inside a model download. "Running it locally" means, concretely: a folder with a few gigabytes in it and nothing that does anything on its own. The block walks through it file by file - and shows why the smallest one of all, the chat template, decides whether your model answers or stutters.

The model landscape

New building block: the model landscape. There is no such thing as "the LLM" - there are hundreds of models, in every size, open and closed. The first fork is not "which model" but "where does it run": at the provider, or on your own hardware. The good news: your harness stays the same, only the number it dials changes.

Sidecars

New building block: sidecars. What actually sits at the other end of a tool? Who parses the PDF, who transcribes the audio? In almost every serious setup, a sidecar: a service beside the agent that does exactly one thing and keeps nothing once it has answered. Why that is a container of its own and not a function inside the agent process.

Memory

New building block: memory. An agent never remembers - it re-sends. The block shows how information gets into the context in the first place, what travels once per session and what travels with every request, and when that calls for a service of its own beside the agent. It is the first step out of the harness.

Tools & Loop

New recap stage on the tools-and-loop building block: chat, wire and code side by side in full screen. The stage replays a complete tool round - the model requests a call, the harness executes, the result goes back - making visible that the loop lives in the harness, not in the model.

System Prompt

New recap stage on the system-prompt building block: chat, wire and code side by side in full screen. It shows where the system prompt sits in the request, that it travels along on every turn - and how the same user sentence gets a different answer under a different system prompt.

Message History

New recap stage on the message-history building block: chat, wire and code side by side in full screen. The stage shows how single calls become a conversation - which messages travel over the wire again on every turn, and what that means for context and cost.

The LLM Call

The LLM-call building block now has a full-screen stage: the harness recap shows chat, wire and code side by side and replays the first call step by step. Also new in the deep dive: the tokenizer playground - three tokenizers run entirely in the browser (our Qwen3 as byte-level BPE, cl100k_base, GPT-2), so the unit's three claims can be verified in seconds: German costs more tokens than English, every model splits differently, and "Strawberry" trips the tokenizer, not the model.

Guardrails

The Guardrails building block no longer treats prompt injection as a warning but as a course: the defence ladder from level 0 to 6 as a table, every layer with the attack it breaks on. Plus the three findings from Lakera's analysis of 279,000 real attacks (layering works, domain restriction is the single strongest measure, defence in the system prompt costs usability), the classification as OWASP LLM01 - and this site's own comment agent as an example from our own house. Finished Arena challenges now get a debrief on top: which layer caught how much, and where the dead ends were.

Get an OpenRouter key and make your first call

The introductory tutorial for your first LLM call now runs on OpenRouter instead of a direct Anthropic account: one key, hundreds of models, free variants - and no business verification. Now with screenshots for sign-up and key creation, both a curl and an SDK variant, a comparison of the response fields against the Anthropic dialect, and how to store the key in your own account.