TypeScript meta-framework · for LangGraph.js
Build LangGraph agents like Next.js apps.
Dawn adds file-system routing, route-local tools, generated types, and HMR to your existing LangGraph.js stack. Keep the runtime. Drop the boilerplate.
import { agent } from "@dawn-ai/sdk"
export default agent({
model: "gpt-4o-mini",
systemPrompt: "Answer for {tenant}.",
})
Why Dawn
LangGraph is powerful. Writing real agents in it is tedious.
LangGraph.js gives you a graph runtime, durable state, and a production-grade execution model — the right primitives. What it doesn't give you is structure. Real agents drift into a single file, hand-rolled tool plumbing, types that don't follow the data, and a dev loop that means restarting the graph every time you change a prompt.
Dawn is a meta-framework for LangGraph in the same shape Next.js is for React. File-system routes for agents, route-local tools with inferred argument types, end-to-end generated types from your state schema, and an HMR dev server that doesn't lose graph state between edits.
Dawn is not a runtime, an LLM router, or a hosting product. Your graphs stay valid LangGraph code. Your model calls stay your model calls. Your deployment target stays yours. Dawn is the scaffolding between you and the runtime.
Routing
Routes for agents, not just pages.
Every agent in your app is a directory. Drop in an index.ts, a state.ts, and a couple of tool files — Dawn wires it into the graph at build time. No registry, no boilerplate orchestration code, no central switch statement that grows every time you add a capability.
- File-system routing the way Next.js does it for pages
- Route groups for organizing public vs. internal agents
- Nested routes for multi-step workflows
- Cold-start safe — routes compile to plain LangGraph at build time
// src/app/(public)/support/index.ts
import { agent } from "@dawn-ai/sdk"
export default agent({
model: "gpt-4o-mini",
systemPrompt: "Answer for {tenant}.",
})
// src/app/(public)/support/state.ts
import { z } from "zod"
export default z.object({
tenant: z.string(),
question: z.string(),
})// src/app/(public)/support/tools/lookup-order.ts
export const description = "Fetch order details by order ID."
export default async (input: { readonly orderId: string }) => {
return await db.orders.find({ orderId: input.orderId })
}Tools
Tools that live next to the route that uses them.
Tools live as files inside the route directory that consumes them. Their argument types are inferred from TypeScript source — no string-typed JSON blobs, no manual type wiring. Co-located tools mean each agent is a self-contained unit you can move, copy, or delete without hunting through a central registry.
- Route-local tools — discovered automatically
- TypeScript-inferred argument types with full IntelliSense
- Tool handlers are plain typed functions
- Easy to test in isolation
Types
Types that follow the data.
Define your agent state in one Zod schema. Dawn generates types that flow into route handlers, tool handlers, and your client code — so the editor catches an out-of-shape state mutation the moment you type it, not at 3am when the graph throws on a missing field.
- Single Zod schema → typed agent state everywhere
- Tool input/output types inferred and propagated
- Generated types refresh on save (HMR)
- Works with your existing tsconfig.json
import { z } from "zod"
// state.ts — single source of truth
export default z.object({
tenant: z.string(),
question: z.string(),
history: z.array(z.object({
role: z.enum(["user", "assistant"]),
content: z.string(),
})),
})
// inside a tool handler — state.history is inferred end-to-end
async function summarize({ state }) {
return state.history.map((m) => `${m.role}: ${m.content}`).join("\n")
}$ pnpm dev
▲ Dawn dev server
- Local: http://localhost:3000
✓ Compiled in 412ms
✓ Graph state preserved across reload
‒ Watching for changes…
✓ Updated route /support in 87ms
✓ Tool tools/lookup-order updated in 31ms
✓ Schema state.ts compiled in 22ms
Dev loop
Edit, save, reload — without restarting the graph.
Dawn's dev server keeps your graph state across edits. Change a prompt, save, and the next conversation continues from where you left off. Tool handlers, system prompts, route files, and Zod schemas all hot-reload — only schema-incompatible state changes cost a graph restart.
- HMR for routes, tools, and prompts
- Graph state preserved across compatible edits
- Type errors surface in the terminal and in your editor
- First compile in ~400ms; incremental in tens of ms
Compatibility
Your bet on LangGraph.js stays your bet.
Dawn compiles to LangGraph constructs. Routes become nodes, tools become callable bindings, state becomes a typed channel. You can read the generated graph, drop into raw StateGraph for any node, or swap a Dawn route for a hand-written one without touching the rest of your app.
If Dawn disappears tomorrow, your raw graphs are still valid LangGraph.js. Your provider clients in graph and chain routes are still your provider clients. Dawn is the scaffolding between you and the runtime — not a replacement for it.
What Dawn does not do
- Dawn is not a runtime — your graphs run on LangGraph.js, full stop.
- Dawn does not proxy provider calls — raw graph and chain routes use the clients you instantiate.
- Dawn does not host your agents — it emits artifacts for your deployment target.
- Dawn does not lock you in — eject to raw StateGraph at any time without rewriting.
Ecosystem
Plays well with your stack.
Dawn keeps the LangGraph.js ecosystem close: built-in agent providers where supported, bring-your-own providers in graph and chain routes, plus observability, vector storage, and deployment targets.
Try it
Three steps to know if Dawn fits.
Scaffold
One command. You'll get a working Dawn app with a typed example route and the dev server running.
Run an example
Open the support route, fire a request, and watch the graph state flow through the tool handler in your terminal.
Port a graph
Bring one of your existing LangGraph.js graphs and rewrite it as a Dawn route — keep the logic, drop the orchestration boilerplate.
FAQ
Things people ask before adopting Dawn.
Dawn is pre-1.0. The framework's surface API is stabilizing, and the types and dev-loop layers are in active use on internal projects. We recommend running an evaluation against a representative graph before adopting Dawn for production work. The runtime — LangGraph.js — is production-grade today, and Dawn does not change its execution model.
Dawn is a meta-framework. LangGraph.js is the runtime that actually executes your agents. Dawn discovers routes, tools, and state, then writes LangGraph-compatible deployment artifacts at build time. You can drop into raw LangGraph by named-exporting a graph route whenever you need direct control.
Routing, tools, types, the dev loop, planning, skills, memory, and subagents are shipped. Durable evaluation harness work is still on the roadmap. Expect concrete proposals before implementation; everything ships incrementally on main with semver-honest releases.
Dawn is maintained by Brian Love and the contributors listed on the GitHub repo. Releases ship under changesets on main; minor releases roughly every two to three weeks, patch releases as needed. Breaking changes go through deprecation periods documented in the changelog.
MIT. Free for commercial and non-commercial use. See the LICENSE file for the full text.
Yes, with the deployment target doing the runtime work. `dawn build` produces LangGraph-compatible entry files and `langgraph.json`; LangSmith can consume those directly, and self-hosted setups should run the generated artifacts in their own LangGraph runtime. Dawn doesn't introduce a hosting dependency.
Dawn does not proxy LangSmith. Raw graph and chain routes keep whatever tracing setup you already configure through LangGraph or LangChain. The local Dawn dev server also loads LangSmith tracing env vars when present.
Nothing. Dawn is MIT-licensed open source with no paid tier, no usage meter, no hosted service to sign up for. The built-in `agent()` route materializes to a LangChain chat model and can infer known provider families; raw graph and chain routes can instantiate providers directly. Provider and deployment costs are yours and flow directly to the services you choose.
Most migrations move state into a single Zod schema, then re-express nodes as route files and tool functions inside a route directory. The migration guide walks through a representative example; the dev loop is forgiving enough to iterate one node at a time.
Start building.
Scaffold a Dawn app, open the example, and see whether the shape fits your team in under five minutes.