Hello, again
Ten days since Dispatch #1. The manual is no longer two articles and a header; it's a working reference. This issue is the short version of what changed, what the new pieces are for, and the one pattern from the field note this week that — quietly — saved us a noticeable amount of money.
Same rules as last time: no hype, no platform worship, no "fascinatingly," no betting analogies. Just a field manual, written in public, for the human / agent / robot triad.
The pattern: static-first prompt construction
Earlier this week, a morning cron that publishes the manual's daily editorial brief dropped from a 4-second median latency to a 1.1-second median latency. The total cost per run fell by 14%. Nothing else changed — the same model, the same context window, the same tool calls, the same output. The only difference was that a block of static content was moved from the middle of the prompt to the top. This is the field note for the week, and the pattern underneath it is one you can apply to almost any scheduled agent.
The mechanism is the prompt cache. When an LLM provider sees a prompt that starts with the same bytes as a prompt it processed recently, it can reuse the earlier computation for the prefix instead of re-reading the tokens. The cache hits when the prefix matches exactly. It misses when any byte in the prefix changes. The cache is invisible to you as the operator — you don't see it, you don't pay for it as a line item, and you don't get a per-request cache-hit signal in most APIs — but it shows up as latency and as dollars, and you control whether it fires by what you put where in the prompt.
The pattern that comes out of this is static-first: put the deterministic content at the top of the prompt, put the agent-decision content at the bottom. Deterministic content is everything the model doesn't need to think about — the system prompt itself, the role definition, the output schema, the tool descriptions, the rules-of-the-house. Agent-decision content is everything the model does need to think about — the today's task, the variable context, the user's question, the per-run data. The deterministic content is identical across runs; the agent-decision content changes per run.
The mistake you'll make the first three times is putting the variable content at the top because that's the "logical" order — describe the agent, then give it today's task. That ordering is correct for a human reader of the prompt but wrong for a cached model. The model doesn't read top-to-bottom with comprehension; it processes the prefix as bytes. If the prefix bytes change every run, the cache never hits. If you put the deterministic bytes first and let the variable bytes fall to the bottom, the cache hits every time the deterministic block is unchanged, which is most runs.
The cost of getting this wrong is not subtle. The field note in the manual this week When the Prompt Cache Saved the Morning measures it concretely. A 4-second median became 1.1 seconds. The dollar cost fell by 14% because the cached prefix doesn't count against the input tokens you're billed for. The reliability improved because the cold-cache failure mode (network blips during the first inference, occasional timeouts on long prefixes) became rarer — every run after the first now hits a warm cache for the bulk of the input. None of this is a model improvement, a tool upgrade, or a clever prompt-rewrite. It is a four-line reordering.
The pattern generalizes further than scheduled crons. Any time you have a prompt whose first N bytes are identical across invocations and whose last M bytes are variable, you have a candidate for static-first. That covers almost every system prompt that includes a task block. It covers almost every RAG prompt that includes a fixed preamble and a variable retrieved-document block — the preamble goes first, the retrieved block goes second, and the user's question goes third. It covers almost every tool-using agent whose tool list is stable and whose per-run inputs are variable. The cost of failing to apply the pattern across all of these is paid in latency and dollars and reliability, every run.
The discipline is to treat prompt construction as two separate files — a stable header you keep under version control and audit once a quarter, and a variable payload that the runtime composes per run. Most operators compose the entire prompt inline in code; that is the mistake. Inline composition makes it hard to see which bytes are stable and which bytes change, and it makes it trivial for a small refactor to invalidate the cache for everyone downstream. A two-file construction makes the prefix explicit. A version-bump on the header file invalidates the cache intentionally; a per-run variable does not.
A short worked example. Suppose your prompt today is:
You are the editorial agent for site X. Output JSON only.
Today's date: {date}. Today's task: {task}.
Today's context: {context}.
Schema: {schema}.
Tool list: {tools}.Reorder it as:
You are the editorial agent for site X. Output JSON only.
Schema: {schema}.
Tool list: {tools}.
Today's date: {date}. Today's task: {task}.
Today's context: {context}.The first version mixes static and dynamic content. Any change to {date} invalidates the prefix. The second version puts all static content first, then the variable block at the bottom. A change to {date} no longer affects the cache prefix. The cache hits on every run that doesn't change the schema, the tool list, or the agent's role. The savings compound across runs.
The pattern is small. The savings are not.
What shipped since the last dispatch
The largest single drop in the manual's history. Since Issue #1, the site has grown from a handful of anchors to a real reference. Five new articles spanning beginner to advanced, five new glossary entries, a new workflow, and a new field note.
Beginner anchors (the missing pillars)
The two pieces that complete the foundation you can hand to a non-technical collaborator.
- What Is AI? — the history of the term, the five generations it covers, and how an operator should think about the label. The piece that names the gap between "AI" as marketing and "AI" as a working tool.
- What Is an LLM? — the next-token view, the training process, why the model hallucinates, how to choose a model. The technical foundation the rest of the manual presumes.
If you haven't read the manual yet, start with these two.
Evaluation, safety, governance
The essay the manual had been missing, and the practical workflow that pairs with it.
- Evaluation, Safety, and Governance — the four-layer eval model, the three failure classes (runaway loops, prompt injection, tool misuse), the audit-log discipline, the approval-gate pattern, the operational maturity ladder, and a concrete checklist for tonight.
- An Agent Eval Workflow — the practical recipe: four layers to test, a 30-line harness in prose, what to do when an eval fails, eval cadence, and the minimum viable eval (3 prompts, 1 scenario, 1 canary).
Together: the essay explains the doctrine; the workflow explains how to ship it.
Context management and workspace hygiene
- Context Management and System Prompts — where the system prompt comes from, how the layers compose, what to put where, the common mistakes (history confused with the system prompt, tool results confused with instructions, turn-specific rules accidentally promoted to session-spanning).
- Workspace Organization and Project Hygiene — the dogfooding account of how this manual uses AGENTS.md, SOUL.md, TOOLS.md, MEMORY.md, and the daily notes. The minimum viable workspace.
Field note (the source for this issue's pattern essay)
- When the Prompt Cache Saved the Morning — the small reordering the pattern essay above is built on. If you only have ten minutes, read this issue's essay first and the field note second; together they cover both the why and the how.
Five new glossary entries
The terms that operators kept reaching for and not finding.
- MCP (Model Context Protocol) — the open protocol for connecting agents to tools. Servers, clients, the wire format, what it isn't.
- Embedding — what it is, what "close" means, where they're used, the off-by-default failure modes.
- Compaction — what happens when the context window fills. Naive vs smart, what's lost, what's preserved.
- Observability — traces, metrics, logs. The smallest signal that supports the debugging you actually do.
- HITL (Human-in-the-Loop) — when to gate a decision on a human, three patterns in increasing order of friction.
One observation: agent-platform churn is the new dot-com churn
The platforms that run agents are in a continuous state of rename, reorg, and partial deprecation. SDKs that existed in 2024 do not exist in 2026. Frameworks that were canonical in Q1 are deprecated by Q4. APIs that the manual relied on in last week's dispatch may quietly lose a parameter by next week's. The churn is real and is the central reason this manual writes at the level of patterns rather than at the level of tools. The dot-com era had the same churn — toolchains changed by the quarter, but the patterns of the web (request-response, cache, idempotent updates, separation of read and write paths) survived. Agent practice is in the same period. The patterns will survive the churn. The vendor docs will not.
Reading path for the week
If you only have twenty minutes:
1. The pattern essay above — read it twice if you can. It is the core of the issue. 2. The field note it is built on: When the Prompt Cache Saved the Morning.
If you have a Saturday:
3. How Does an Agent Think? — the LLM-in-the-loop mental model. Five minutes. 4. Inside the Agent Loop — six stages, what goes wrong at each. Ten minutes. 5. The static-first pattern in practice: audit one of your scheduled agents this week. Find the prompt. Identify the bytes that change every run. Move them to the bottom. Measure the latency before and after. The savings compound.
What's next
Two canonical topics remain uncovered; both are short and slated for the next batch. How Does an Agent Understand — the pattern-matching vs context-vs-memory companion to How Does an Agent Think. Practical Applications: Personal, Team, Business Agents — the operator's guide to picking which generation fits which use case. After that: a worked state-graph example on a real workflow, a piece on what changes when you put two agents in the same loop, and the next dispatch.
If a piece this week lands for you — or misses the mark — write back. Two sentences is plenty.
That's it for the second issue. See you next Saturday.
— Triadive Editorial
Not investment advice. Not legal advice. Not therapy for your agent loop. Just a working field manual, written in public, for the human / agent / robot triad.