From 9b4232593eb02f15a2b41483b6a707e80a5050b3 Mon Sep 17 00:00:00 2001
From: Brian Love <brian@liveloveapp.com>
Date: Mon, 11 May 2026 16:27:05 -0700
Subject: [PATCH 1/2] fix(web): docs/blog scroll behavior + breakpoint
 alignment

- Introduce --header-h CSS var (4.5rem) and html scroll-padding-top
  so anchor jumps land below the header instead of flush to the top.
- ReadingLayout: switch sticky asides from hardcoded top-16/h-4rem
  to var(--header-h) so the sidebars don't snap 8-9px high under
  the actual header height.
- DocsTOC: align nav breakpoint with ReadingLayout's right-aside
  reveal (lg:block instead of xl:block). Previously the aside
  appeared with its border-l from 1024-1279px but the TOC inside
  stayed hidden until 1280px, producing an empty bordered rail.
- CreamSurface: drop redundant min-h-screen (main.flex-1 already
  provides full-height) and use h-full for the inverse to keep
  parity. Prevents short pages from forcing extra blank space
  below the footer.
- PostMeta avatar normalized to 28px to match PostHeader's mobile
  byline, so the same image isn't sized differently across the
  desktop/mobile boundary.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
---
 apps/web/app/components/CreamSurface.tsx  | 2 +-
 apps/web/app/components/ReadingLayout.tsx | 4 ++--
 apps/web/app/components/blog/PostMeta.tsx | 4 ++--
 apps/web/app/components/docs/DocsTOC.tsx  | 2 +-
 apps/web/app/globals.css                  | 7 +++++++
 5 files changed, 13 insertions(+), 6 deletions(-)

diff --git a/apps/web/app/components/CreamSurface.tsx b/apps/web/app/components/CreamSurface.tsx
index 3c0285cd..460e9fd2 100644
--- a/apps/web/app/components/CreamSurface.tsx
+++ b/apps/web/app/components/CreamSurface.tsx
@@ -6,7 +6,7 @@ import type { ReactNode } from "react"
 export function CreamSurface({ children }: { readonly children: ReactNode }) {
   const isLanding = usePathname() === "/"
   return (
-    <div className={isLanding ? "" : "bg-bg-primary text-text-primary min-h-screen"}>
+    <div className={isLanding ? "h-full" : "bg-bg-primary text-text-primary h-full"}>
       {children}
     </div>
   )
diff --git a/apps/web/app/components/ReadingLayout.tsx b/apps/web/app/components/ReadingLayout.tsx
index 71b605d5..867f5179 100644
--- a/apps/web/app/components/ReadingLayout.tsx
+++ b/apps/web/app/components/ReadingLayout.tsx
@@ -9,13 +9,13 @@ interface ReadingLayoutProps {
 export function ReadingLayout({ left, right, children }: ReadingLayoutProps) {
   return (
     <div className="grid grid-cols-1 md:grid-cols-[240px_minmax(0,1fr)] lg:grid-cols-[240px_minmax(0,1fr)_240px] xl:grid-cols-[280px_minmax(0,1fr)_240px]">
-      <aside className="hidden md:block sticky top-16 self-start h-[calc(100vh-4rem)] overflow-y-auto px-6 py-8 border-r border-border-subtle">
+      <aside className="hidden md:block sticky self-start overflow-y-auto px-6 py-8 border-r border-border-subtle top-[var(--header-h)] h-[calc(100vh-var(--header-h))]">
         {left}
       </aside>
       <section className="min-w-0 px-6 md:px-12 py-12 max-w-[760px] mx-auto w-full">
         {children}
       </section>
-      <aside className="hidden lg:block sticky top-16 self-start h-[calc(100vh-4rem)] overflow-y-auto px-6 py-8 border-l border-border-subtle">
+      <aside className="hidden lg:block sticky self-start overflow-y-auto px-6 py-8 border-l border-border-subtle top-[var(--header-h)] h-[calc(100vh-var(--header-h))]">
         {right}
       </aside>
     </div>
diff --git a/apps/web/app/components/blog/PostMeta.tsx b/apps/web/app/components/blog/PostMeta.tsx
index fef1fd1e..e434ce2e 100644
--- a/apps/web/app/components/blog/PostMeta.tsx
+++ b/apps/web/app/components/blog/PostMeta.tsx
@@ -51,8 +51,8 @@ export function PostMeta({ post }: { readonly post: Post }) {
           <Image
             src={author.avatar}
             alt={author.name}
-            width={36}
-            height={36}
+            width={28}
+            height={28}
             className="rounded-full"
           />
           <a
diff --git a/apps/web/app/components/docs/DocsTOC.tsx b/apps/web/app/components/docs/DocsTOC.tsx
index a000ceab..7760c1c1 100644
--- a/apps/web/app/components/docs/DocsTOC.tsx
+++ b/apps/web/app/components/docs/DocsTOC.tsx
@@ -57,7 +57,7 @@ export function DocsTOC() {
   if (headings.length === 0) return null
 
   return (
-    <nav aria-label="On this page" className="sticky top-8 w-52 shrink-0 hidden xl:block text-sm">
+    <nav aria-label="On this page" className="sticky top-8 w-52 shrink-0 hidden lg:block text-sm">
       <p className="text-xs text-text-muted uppercase tracking-widest mb-3">On this page</p>
       <ul className="space-y-2 border-l border-border-subtle">
         {headings.map((h) => (
diff --git a/apps/web/app/globals.css b/apps/web/app/globals.css
index 016a885c..ce21b8dc 100644
--- a/apps/web/app/globals.css
+++ b/apps/web/app/globals.css
@@ -29,6 +29,13 @@
   --dawn-white: #ffffff;
   --dawn-neutral-gray: #6b6b6b;
   --dawn-font-sans: var(--font-inter), "Satoshi", "Helvetica Neue", Arial, sans-serif;
+  /* Chrome height — Header has px-6/8 + py-4 + ~h-10 brand row + 1px border.
+     Used by ReadingLayout sticky offsets and anchor scroll padding. */
+  --header-h: 4.5rem;
+}
+
+html {
+  scroll-padding-top: var(--header-h);
 }
 
 /* Landing dark scope — landing-section components author against the dark token

From d2cecf296c07df72d2ffea16d68f4945ad19b6ac Mon Sep 17 00:00:00 2001
From: Brian Love <brian@liveloveapp.com>
Date: Mon, 11 May 2026 16:29:24 -0700
Subject: [PATCH 2/2] content(blog): rewrite three launch posts in Brian's
 voice

Apply Brian's voice guide to the three launch posts (origin essay, mental-model
essay, 0.4 release). Short declarative sentences, cold claim-first openings,
tl;dr bullet blocks, one-line "That is X." emphasis beats, and stakes-landing
closers. Preserved frontmatter and intra-site links; reused existing code
blocks (without-Dawn / with-Dawn comparison, route tree, createSubAgent).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
---
 .../blog/2026-05-12-why-we-built-dawn.mdx     |  99 ++++++++++++----
 .../2026-05-19-app-router-for-ai-agents.mdx   | 111 ++++++++++++++----
 .../blog/2026-06-02-dawn-0-4-release.mdx      |  80 ++++++++++---
 3 files changed, 221 insertions(+), 69 deletions(-)

diff --git a/apps/web/content/blog/2026-05-12-why-we-built-dawn.mdx b/apps/web/content/blog/2026-05-12-why-we-built-dawn.mdx
index cbf62c43..9c4c97c5 100644
--- a/apps/web/content/blog/2026-05-12-why-we-built-dawn.mdx
+++ b/apps/web/content/blog/2026-05-12-why-we-built-dawn.mdx
@@ -7,35 +7,62 @@ type: post
 author: brian
 ---
 
-Dawn started as a folder of helper scripts that kept showing up in every LangGraph project we touched. By the third project, it was clear the helpers were a framework wearing a trench coat.
+Agent codebases are becoming one of the harder shapes in TypeScript right now.
 
-This post is about the friction those scripts were absorbing, and why we decided to make that work explicit.
+Not because the runtimes are bad.
+And not because the model providers have failed us.
+
+The runtime is fine. LangGraph holds up. What does not hold up is the *code around* the graph.
+
+That is the gap Dawn was built to close.
+
+## tl;dr
+
+- dawn is a meta-framework for LangGraph, not a replacement for it
+- the runtime, the channels, the checkpointer, LangSmith — all unchanged
+- `dawn build` emits a `langgraph.json` that deploys to LangSmith without translation
+- the thing dawn replaces is the boilerplate, the registry files, and the implicit project layout
+- agent code should feel like Next.js code: filesystem routes, inferred types, a real dev loop
 
 ## The moment it stopped scaling
 
-LangGraph is excellent at what it does. The runtime, the channels, the checkpointer — they all hold up. What didn't hold up was the *code around* the graph.
+Dawn started as a folder of helper scripts that kept showing up in every LangGraph project I touched.
+
+By the third project, it was clear the helpers were a framework wearing a trench coat.
+
+The trigger was a single project. Four graphs, eleven tools, and a `langgraph.json` that nobody wanted to touch. Graphs in one folder. Tools in another. State shapes in a third. A `registry.ts` gluing them together. Every new feature touched all four locations.
 
-Our second production agent project had four graphs, eleven tools, and a `langgraph.json` that no one wanted to touch. The graphs lived in one folder, the tools in another, the state shapes in a third, and a `registry.ts` glued them together. Every new feature touched all four locations.
+I started writing internal docs explaining where things were supposed to go.
 
-We started writing internal docs explaining where things were supposed to go. That was the moment. If the framework is making you write a memo about file layout, the framework is missing a piece.
+That was the moment.
+
+If the framework is making you write a memo about file layout, the framework is missing a piece.
 
 ## The friction list
 
-The same pain showed up in every project. None of it is LangGraph's fault — these are just things LangGraph leaves to you.
+The same pain shows up in every LangGraph project past the second graph. None of it is LangGraph's fault. These are things LangGraph leaves to you.
+
+- **graph boilerplate.** every route involves the same `StateGraph` plumbing — `addNode`, `addConditionalEdges`, `bindTools`, an exported `compile()`. the interesting code is twenty lines; the wiring is sixty.
+- **no project structure.** langgraph has no opinion on where graphs, tools, or state live. so every team invents a layout, then re-invents it six months later.
+- **hand-written tool schemas.** every tool means a function, a zod schema, and a `tool()` wrapper. the schema duplicates the typescript types you already wrote.
+- **no local dev loop.** `langgraph dev` works but is heavyweight. iterating against a route meant pushing to staging.
+- **lost types at the boundary.** tool inputs, state shape, dynamic routing parameters — none typed across the graph boundary by default.
+
+Each item is solvable on its own.
+
+The trouble is that every team solves them slightly differently, and the solutions do not compose.
+
+That is the real cost. Not the boilerplate. The lack of a shared shape.
 
-- **Graph boilerplate.** Every agent route involves the same `StateGraph` plumbing — `addNode`, `addConditionalEdges`, `bindTools`, an exported `compile()`. The interesting code is twenty lines; the wiring is sixty.
-- **No project structure.** LangGraph has no opinion on where graphs, tools, or state live. So every team invents their own layout, then re-invents it six months later when the first one stops working.
-- **Hand-written tool schemas.** Every tool means a function, a Zod schema, and a `tool()` wrapper. The schema duplicates the TypeScript types you already wrote, and drifts the moment you forget.
-- **No local dev loop.** `langgraph dev` works but is heavyweight. Iterating against a route meant pushing to staging, watching the deploy, and waiting on traces. Tight loops aren't tight.
-- **Lost types at the boundary.** Tool inputs, state shape, dynamic routing parameters — none of these are typed across the graph boundary by default. You learn at runtime what a misspelled key costs.
+## What "meta-framework" actually means here
 
-Each item is solvable on its own. The trouble is that every team solves them slightly differently, and the solutions don't compose.
+Dawn is not a competitor to LangGraph.
 
-## What "meta-framework" means here
+It is the layer above it.
 
-Dawn is not a competitor to LangGraph. The runtime, the graph compiler, the checkpointer, LangSmith — all unchanged. The output of `dawn build` is a `langgraph.json` that LangSmith deploys without translation.
+The runtime, the graph compiler, the checkpointer, LangSmith — all unchanged. The output of `dawn build` is a `langgraph.json` that LangSmith deploys without translation.
 
-What Dawn replaces is the *code around* the graph. Concretely:
+What Dawn replaces is the *code around* the graph.
 
 Without Dawn, a hello-world tool-calling agent looks like this:
 
@@ -76,7 +103,7 @@ export const graph = new StateGraph(MessagesAnnotation)
 
 Plus a hand-maintained `langgraph.json` pointing at the export.
 
-With Dawn, it's two files:
+With Dawn, it is two files:
 
 ```ts
 // src/app/(public)/hello/[tenant]/index.ts
@@ -93,24 +120,44 @@ export default agent({
 export default async ({ name }: { name: string }) => `Hello, ${name}!`
 ```
 
-`dawn build` produces the `langgraph.json`. The `greet` tool is bound to the agent because it lives under `tools/`. The `[tenant]` segment becomes a typed field on state. Same deploy target; roughly a quarter of the code.
+`dawn build` produces the `langgraph.json`. The `greet` tool is bound to the agent because it lives under `tools/`. The `[tenant]` segment becomes a typed field on state.
 
-The point isn't lines saved. The point is that every concept — route, tool, state, middleware — has *one place* it lives, and that place is on disk where your editor can find it.
+Same deploy target. Roughly a quarter of the code.
+
+The point is not lines saved.
+
+The point is that every concept — route, tool, state, middleware — has one place it lives. And that place is on disk where your editor can find it.
+
+That is the difference between "we wrote some helpers" and "we built a framework."
 
 ## The bet: agent code should feel like Next.js code
 
-The Next.js App Router did one thing extraordinarily well: it gave every concern a coordinate. A route is a folder. A layout is `layout.tsx`. A server action is a function in a route file. You can point at a thing, search for it, refactor it, write a test next to it.
+The Next.js App Router did one thing extraordinarily well.
+
+It gave every concern a coordinate.
+
+A route is a folder. A layout is `layout.tsx`. A server action is a function in a route file. You can point at a thing, search for it, refactor it, write a test next to it.
+
+Agent codebases lack that. The runtime is reasonable, but the codebase shape is whatever you negotiated with your team last quarter.
+
+My bet is that agent code should feel like Next.js code. A route is a folder under `src/app/`. The folder path is the agent endpoint. Tools, state, middleware, and tests live next to the route they belong to. Types are generated from the file tree, not maintained by hand.
+
+That is the whole framework.
+
+Filesystem routes. Inferred types. A real dev server. A build step that emits the artifact LangSmith already understands.
+
+## Where Dawn is now
 
-Agent codebases lack that. The runtime is reasonable, but the *codebase shape* is whatever you negotiated with your team last quarter.
+Dawn 0.3 ships the route conventions, the typed tool inference, the dev server, and the build step.
 
-Our bet is that agent code should feel like Next.js code. A route is a folder under `src/app/`. The folder path is the agent endpoint. Tools, state, middleware, and tests live next to the route they belong to. Types are generated from the file tree, not maintained by hand.
+The mental model is documented at [`/docs/mental-model`](/docs/mental-model). The route conventions live at [`/docs/routes`](/docs/routes). If you have a working LangGraph project, the migration walkthrough at [`/docs/migrating-from-langgraph`](/docs/migrating-from-langgraph) covers the construct-by-construct move.
 
-That's the whole framework. Filesystem routes, inferred types, a real dev server, and a build step that emits the artifact LangSmith already understands.
+What is next is Deep Agents — composable sub-agents — and a deeper streaming story. Both ship in 0.4.
 
-## Where we are now
+If you have felt the friction described above, the [getting started](/docs/getting-started) guide takes about a minute end to end.
 
-Dawn 0.3 ships the route conventions, the typed tool inference, the dev server, and the build step. The mental model is documented at [`/docs/mental-model`](/docs/mental-model) and the route conventions at [`/docs/routes`](/docs/routes). If you have a working LangGraph project, the migration walkthrough at [`/docs/migrating-from-langgraph`](/docs/migrating-from-langgraph) covers the construct-by-construct move.
+That is the right way to evaluate whether Dawn matches the mental model you already have.
 
-What's next is Deep Agents — composable sub-agents — and a deeper streaming story. Both are coming in 0.4.
+The runtime is becoming policy. The framework around it is becoming product behavior.
 
-If you've felt the friction described above, the [getting started](/docs/getting-started) guide takes about a minute end to end. That's the right way to evaluate whether Dawn matches the mental model you already have.
+That is what makes this interesting.
diff --git a/apps/web/content/blog/2026-05-19-app-router-for-ai-agents.mdx b/apps/web/content/blog/2026-05-19-app-router-for-ai-agents.mdx
index d8c0c1b4..cc52f777 100644
--- a/apps/web/content/blog/2026-05-19-app-router-for-ai-agents.mdx
+++ b/apps/web/content/blog/2026-05-19-app-router-for-ai-agents.mdx
@@ -7,28 +7,55 @@ type: post
 author: brian
 ---
 
-The Next.js App Router did something subtle but important. It didn't introduce a new runtime, and it didn't change how React rendered. What it changed was the *answer to the question "where does this code go?"*.
+The Next.js App Router did something subtle and important.
 
-Every concern got a coordinate. A page is `page.tsx`. A layout is `layout.tsx`. A server action is a function in a server file. Middleware lives at `middleware.ts`. There is one place each concept lives, and that place is a file on disk.
+Not because it introduced a new runtime.
+And not because it changed how React rendered.
 
-Agent codebases don't have that yet. Dawn is an attempt to fix it.
+What it changed was the answer to the question *"where does this code go?"*.
+
+A page is `page.tsx`. A layout is `layout.tsx`. A server action is a function in a server file. Middleware lives at `middleware.ts`. One place each concept lives, and that place is a file on disk.
+
+Agent codebases do not have that yet.
+
+Dawn is an attempt to fix it.
+
+## tl;dr
+
+- agent codebases need a coordinate system, not just a runtime
+- file-system routes give every concern a folder, not a registry entry
+- co-location is a feature: refactors work, search works, tests do not drift
+- typescript function signatures are the tool contract — no zod, no `tool()` wrapper
+- the win is not the first agent. it is the tenth.
 
 ## The missing coordinate system
 
-If you've worked on a LangGraph project past the second graph, you know the shape of the problem. You have graphs in one folder, tools in another, state definitions in a third, and a registry that ties them together. The connections between those files are implicit — a tool is "for" a graph because it's imported by it, not because it lives next to it.
+If you have worked on a LangGraph project past the second graph, you know the shape of the problem.
+
+Graphs in one folder. Tools in another. State definitions in a third. A registry tying them together.
+
+The connections between those files are implicit. A tool is "for" a graph because it is imported by it, not because it lives next to it.
 
-That works fine at the kitchen-table scale. It stops working when you need to answer questions like:
+That works at the kitchen-table scale.
 
-- Which tools does the `support` graph have access to?
-- If I rename `lookupOrder`, what else needs to change?
-- Where do I add the tenant-aware auth check for the `triage` route?
-- Can I delete this tool? Who calls it?
+It stops working when you need to answer questions like:
 
-These are all answerable, but the answer lives in your head or in a wiki page, not on disk. The codebase doesn't know its own structure.
+- which tools does the `support` graph have access to?
+- if I rename `lookupOrder`, what else needs to change?
+- where do I add the tenant-aware auth check for the `triage` route?
+- can I delete this tool? who calls it?
+
+These are all answerable.
+
+The answer just does not live on disk. It lives in your head, or in a wiki page, or in the import graph you have to trace by hand.
+
+That is the gap. The codebase does not know its own structure.
 
 ## File-system routes as the answer
 
-The fix is borrowed wholesale from web frameworks. A route is a folder. The folder path is the endpoint. Everything that belongs to the route lives next to it.
+The fix is borrowed wholesale from web frameworks.
+
+A route is a folder. The folder path is the endpoint. Everything that belongs to the route lives next to it.
 
 A real Dawn project tree:
 
@@ -53,27 +80,41 @@ my-agents/
             └── state.ts
 ```
 
-Read that tree out loud and you've read the architecture. `support/[tenant]/` is a parameterized route. It has its own state shape, its own auth middleware, and two tools the agent can call. `support/internal/` is a separate route — a different endpoint, a different graph. `triage/` is unrelated to either.
+Read that tree out loud and you have read the architecture.
+
+`support/[tenant]/` is a parameterized route. It has its own state shape, its own auth middleware, and two tools the agent can call. `support/internal/` is a separate route — a different endpoint, a different graph. `triage/` is unrelated to either.
+
+There is no registry. There is no `tools: [...]` array.
+
+The connection between a tool and the route that uses it is the *folder it is in*.
 
-There's no registry. There's no `tools: [...]` array. The connection between a tool and the route that uses it is the *folder it's in*.
+That is the whole trick.
 
-## Co-location as a feature, not aesthetics
+## Co-location is a feature, not aesthetics
 
-Putting files near the thing they belong to isn't a style preference. It changes what your tools can do.
+Putting files near the thing they belong to is not a style preference.
 
-**Refactoring works.** Move a folder, move the route. Delete a folder, delete the route. There's no central registry whose edits you'll forget.
+It changes what your tools can do.
 
-**Search works.** "Find references" on a tool finds the route that uses it because the route imports it directly. "Find references" on a state field finds the agent prompt that mentions it.
+**Refactoring works.** Move a folder, move the route. Delete a folder, delete the route. There is no central registry whose edits you will forget.
 
-**Tests don't drift.** A scenario test for `support/[tenant]/` lives in `support/[tenant]/run.test.ts`. When you change the route, the test is right there in the same diff. The chance of test rot drops a lot when the test is sitting next to the thing it tests.
+**Search works.** "Find references" on a tool finds the route that uses it, because the route imports it directly. "Find references" on a state field finds the agent prompt that mentions it.
+
+**Tests do not drift.** A scenario test for `support/[tenant]/` lives in `support/[tenant]/run.test.ts`. When you change the route, the test is right there in the same diff.
 
 **Onboarding works.** New engineers can open the tree and read the surface area without a Loom video. The structure is the documentation.
 
-Frameworks that hide structure behind a builder API give all of this up. Once your routes are constructed at runtime from a `.register()` call, your editor cannot tell you what your codebase looks like — only the running process can.
+Frameworks that hide structure behind a builder API give all of this up.
+
+Once your routes are constructed at runtime from a `.register()` call, your editor cannot tell you what your codebase looks like. Only the running process can.
+
+That is a real cost. It just shows up late.
 
 ## Types as the route boundary
 
-The other half of the coordinate system is types. A route is a contract, and the contract should be checked at the boundary.
+The other half of the coordinate system is types.
+
+A route is a contract. The contract should be checked at the boundary.
 
 In Dawn, a tool is just a TypeScript function:
 
@@ -90,18 +131,38 @@ export default async (
 }
 ```
 
-There's no Zod schema. There's no `tool()` wrapper. The parameter type *is* the schema — `dawn typegen` reads it at build time and emits both a JSON schema for the LLM and a typed `ctx.tools.lookupOrder` for any code that calls it directly.
+There is no Zod schema. There is no `tool()` wrapper.
+
+The parameter type *is* the schema. `dawn typegen` reads it at build time and emits both a JSON schema for the LLM and a typed `ctx.tools.lookupOrder` for any code that calls it directly.
+
+This sounds like a small convenience.
+
+It is actually a forcing function.
 
-This sounds like a small convenience. It's actually a forcing function. Because the type is the contract, drift is impossible. If you change the tool's signature, callers fail to typecheck. If you misspell a tool name in a workflow route, the editor underlines it. The route boundary is checked the same way the rest of your TypeScript is checked.
+Because the type is the contract, drift is impossible. If you change the tool signature, callers fail to typecheck. If you misspell a tool name in a workflow route, the editor underlines it.
+
+The route boundary is checked the same way the rest of your TypeScript is checked.
 
 Generated types live in `dawn.generated.d.ts`. Commit it or regenerate on the fly — both work, the same way `next-env.d.ts` works.
 
 ## What this unlocks at scale
 
-The interesting thing isn't the first agent. It's the tenth.
+The interesting thing is not the first agent.
+
+It is the tenth.
+
+A codebase with ten agents, forty tools, and a dozen middleware files needs the same code-intelligence features a web app does. Go-to-definition that works. Refactors that do not break things in production. Tests that run on a tight loop. Deploys that do not require a memo.
+
+Those features do not show up by accident.
 
-A codebase with ten agents, forty tools, and a dozen middleware files needs the same code-intelligence features a web app does — go-to-definition that works, refactors that don't break things in production, tests that run on a tight loop, deploys that don't require a memo. Those features don't show up by accident; they require the codebase to have a *shape* the tools can reason about.
+They require the codebase to have a *shape* the tools can reason about.
 
-That's the whole pitch. Dawn isn't asking you to learn a new graph runtime. The graph runtime is fine. Dawn is the coordinate system around it — the answer to "where does this code go" — and the type machinery that makes the answer load-bearing.
+That is the whole pitch.
+
+Dawn is not asking you to learn a new graph runtime. The graph runtime is fine. Dawn is the coordinate system around it — the answer to "where does this code go" — and the type machinery that makes the answer load-bearing.
 
 If the mental model resonates, [`/docs/mental-model`](/docs/mental-model) is the one-page version, and [`/docs/routes`](/docs/routes) is where the conventions are spelled out in full.
+
+A runtime is becoming a routing problem. A routing problem is becoming a type problem.
+
+That is what makes this interesting.
diff --git a/apps/web/content/blog/2026-06-02-dawn-0-4-release.mdx b/apps/web/content/blog/2026-06-02-dawn-0-4-release.mdx
index c352e4f2..b3a573e3 100644
--- a/apps/web/content/blog/2026-06-02-dawn-0-4-release.mdx
+++ b/apps/web/content/blog/2026-06-02-dawn-0-4-release.mdx
@@ -8,15 +8,35 @@ version: 0.4.0
 author: brian
 ---
 
-Dawn 0.4 is out. The headline is a preview of **Deep Agents** — composable sub-agents with their own routes, tools, and state — plus a tighter streaming story and a stabilized middleware API.
+Sub-agents are becoming one of the more important boundaries in agentic software.
 
-This is a backward-compatible release for projects already on 0.3.x. The upgrade is a single `pnpm` command.
+Not because chaining LLM calls is new.
+And not because "agent calls agent" is a fresh idea.
+
+It matters because the boundary between a parent agent and a specialist is starting to look like a route boundary. And route boundaries deserve to be first-class.
+
+That is what Dawn 0.4 ships.
+
+## tl;dr
+
+- deep agents preview: composable sub-agents declared with the same `agent({...})` ergonomics
+- a sub-agent is a folder under the parent, with its own tools, state, and middleware
+- token-level streaming now flows through sub-agent boundaries, tagged by route id
+- `/runs/stream` is byte-identical to the langsmith production protocol
+- middleware api is stable; the experimental flag is gone
+- backward-compatible upgrade from 0.3.x
 
 ## Deep Agents preview
 
-Real agent systems are rarely one agent. A support assistant calls a research sub-agent. A triage flow hands off to a domain specialist. Until now in Dawn, "sub-agent" meant "another route you invoke via `ctx.run()`" — workable, but the boundary wasn't first-class.
+Real agent systems are rarely one agent.
+
+A support assistant calls a research sub-agent. A triage flow hands off to a domain specialist.
 
-`createSubAgent` makes the boundary first-class. A sub-agent is a route under the parent, declared with the same `agent({...})` ergonomics, and reachable as a typed call from the parent.
+Until now in Dawn, "sub-agent" meant "another route you invoke via `ctx.run()`". That worked. But the boundary was not first-class.
+
+`createSubAgent` makes the boundary first-class.
+
+A sub-agent is a route under the parent, declared with the same `agent({...})` ergonomics, and reachable as a typed call from the parent.
 
 ```ts
 // src/app/support/[tenant]/index.ts
@@ -43,25 +63,39 @@ export default createSubAgent({
 })
 ```
 
-The parent route's prompt can reference `research` by name. Dawn binds it as a callable from the parent agent — the LLM picks when to delegate, just like a tool call, but the sub-agent runs with its own state, its own tools (under `research/tools/`), and its own middleware.
+The parent route's prompt can reference `research` by name. Dawn binds it as a callable from the parent — the LLM picks when to delegate, just like a tool call.
+
+But the sub-agent runs with its own state, its own tools under `research/tools/`, and its own middleware.
+
+That is the difference. The sub-agent is not a function call. It is a route.
+
+Each sub-agent is a folder. You can test it in isolation with `dawn run "/support/[tenant]/research"`, deploy it as its own `assistant_id`, and reuse it from a different parent by referencing the path.
 
-Why this matters: each sub-agent is a folder. You can test it in isolation with `dawn run "/support/[tenant]/research"`, deploy it as its own `assistant_id`, and reuse it from a different parent by referencing the path. The boundary is on disk, not in a config file.
+The boundary is on disk. Not in a config file.
 
-Deep Agents is a preview. The shape of `subAgents` and the streaming contract for delegated calls may shift before 0.5. We'll call out breaking changes explicitly in the changelog.
+**A sub-agent is a route, not a function. That is the whole shift.**
+
+Deep Agents is a preview. The shape of `subAgents` and the streaming contract for delegated calls may shift before 0.5. Breaking changes will be called out explicitly in the changelog.
 
 ## Streaming improvements
 
-Three concrete changes:
+Three concrete changes.
+
+**Token-level streaming through sub-agent boundaries.** In 0.3, a delegated call buffered until the sub-agent finished. In 0.4, the parent's stream interleaves the sub-agent's tokens, tagged with the sub-agent's route id.
+
+**`/runs/stream` matches LangSmith verbatim.** The event names, ordering, and payload shapes are byte-identical to the production protocol. Dev-server output and deployed output line up in any tooling that consumes both.
 
-- **Token-level streaming through sub-agent boundaries.** In 0.3, a delegated call buffered until the sub-agent finished. In 0.4, the parent's stream interleaves the sub-agent's tokens, tagged with the sub-agent's route id.
-- **`/runs/stream` matches LangSmith verbatim.** The event names, ordering, and payload shapes are now byte-identical to the production protocol, so dev-server output and deployed output line up in tooling that consumes both.
-- **`dawn dev` shows streamed events in the terminal.** The local dev server prints tool calls, state mutations, and token deltas as they happen. No more attaching a curl to watch progress.
+**`dawn dev` shows streamed events in the terminal.** The local dev server prints tool calls, state mutations, and token deltas as they happen. No more attaching a curl to watch progress.
 
-The streaming work also shaved roughly 30% off cold-start time for the dev server on projects with more than 20 routes — a side effect of moving route metadata into a lazy import path.
+The streaming work also shaved roughly 30% off cold-start time for the dev server on projects with more than 20 routes. A side effect of moving route metadata into a lazy import path.
 
 ## Middleware API stabilized
 
-The middleware shape that landed in 0.3 behind a flag is stable as of 0.4. The flag is gone. `defineMiddleware`, the `allow` / `reject` helpers, and nearest-ancestor resolution are the supported API.
+The middleware shape that landed in 0.3 behind a flag is stable as of 0.4.
+
+The flag is gone.
+
+`defineMiddleware`, the `allow` / `reject` helpers, and nearest-ancestor resolution are the supported API.
 
 ```ts
 // src/app/support/middleware.ts
@@ -75,7 +109,9 @@ export default defineMiddleware(async (req) => {
 })
 ```
 
-If you were using the experimental flag in `dawn.config.ts`, remove it. The behavior is the same; the gate is just gone.
+If you were using the experimental flag in `dawn.config.ts`, remove it.
+
+The behavior is the same. The gate is just gone.
 
 ## Upgrading
 
@@ -84,10 +120,18 @@ pnpm add @dawn-ai/cli@0.4.0 @dawn-ai/sdk@0.4.0
 pnpm exec dawn verify
 ```
 
-`dawn verify` will regenerate `dawn.generated.d.ts` against the new SDK types. If your project compiles after that, you're done.
+`dawn verify` regenerates `dawn.generated.d.ts` against the new SDK types. If your project compiles after that, you are done.
+
+The runtime is unchanged. The output is still a `langgraph.json` that LangSmith deploys without translation. That contract has not moved.
+
+If you are coming from a raw LangGraph project and have not moved yet, the migration walkthrough at [`/docs/migrating-from-langgraph`](/docs/migrating-from-langgraph) is the construct-by-construct guide. Nothing in 0.4 changes the path described there.
+
+## What is next
+
+0.5 will lift the Deep Agents preview flag, ship a typed evaluations API, and add the durable-execution story for long-running workflows.
 
-If you're coming from a raw LangGraph project and haven't moved yet, the migration walkthrough at [`/docs/migrating-from-langgraph`](/docs/migrating-from-langgraph) is the construct-by-construct guide. Nothing in 0.4 changes the migration path described there.
+The tracking issue is in the repo. Feedback on the sub-agent shape is especially welcome while it is still in preview.
 
-## What's next
+Sub-agents are becoming routes. Routes are becoming the unit of composition.
 
-0.5 will lift the Deep Agents preview flag, ship a typed evaluations API, and add the durable-execution story for long-running workflows. Tracking issue in the repo; feedback on the sub-agent shape is especially welcome while it's still in preview.
+That is what makes this interesting.