I Built a 26-Lesson Lab for Writing a Coding Agent by Hand

A lot of agent tutorials stop at calling a chat API. When you try to build a coding agent that can read files, call tools, and stop at a permission boundary, the hard parts are usually engineering problems: when the loop should halt, how tool arguments are validated, how context is budgeted, what to do with timeouts and unknown side effects, and whether a hook or a prompt can override a rule that was supposed to deny the call.

That is why I built AI Agent Engineering Lab. The Chinese product name on the site is 「AI Agent 工程训练站」—literally a training workshop. The English subtitle in the header is AGENT ENGINEERING LAB. The site describes its aim in one sentence: write a coding agent in TypeScript and Node.js, and practice the engineering design (and the interview explanation) as you go. Each lesson is about fifteen minutes, and each one adds a verifiable capability to the same agent, from the model loop through to safe execution.

The site is live at https://agent-lab.umic.io. The UI is Chinese only; there is no English locale, and /en is not a real page.

Why it exists, and who it is for

The homepage frames the path as “from the model loop to safe execution.” Lessons are grouped by theme, last about fifteen minutes, and include an interview-style follow-up question. I wanted a place that is useful both for people implementing a runtime and for people who need to explain the mechanisms clearly.

If you already know some TypeScript or Node.js and want to write the loop, the tool contract, the context budget, and the permission boundary yourself—rather than only driving an existing product—this is the intended starting point. Early lessons are labeled foundational; later ones are intermediate or challenge-level. You do not need a particular model vendor to begin. Many exercises can be checked with a fake model.

It is probably not the right fit if you want a one-click agent generator, or if you do not want to read TypeScript. Some lessons are reading, comparison, and written exercises. Only a few include an in-browser editor.

The path: ten themes, twenty-six lessons

The catalog states the shape plainly: ten themes, twenty-six lessons, about fifteen minutes each. Lessons have prerequisites, and the site can show the dependency map. The first eight themes follow one project line. The last two are a product teardown and an architecture close reading.

The first eight themes are:

1. Agent architecture — 01, write the agent loop; 02, separate the model protocol from the runtime. A “find the failing test” task is split into a model decision, tool execution, and a result that is sent back. Fake models, a Claude API, and local inference are meant to share one runtime contract.
2. Tool use — 03, define the tool contract and error semantics; 04, scope file reads. The read_file tool gets validation and authorization, and read-only access stays inside a controlled fixture workspace.
3. Context management — 05, budget context and trim tool output; 06, compact history while keeping evidence pointers. Rules, the task, evidence, and reserved output get a budget before a request is sent, and later turns should still be able to trace the important conclusions.
4. Memory — 07, keep session state and long-term memory apart; 08, check freshness and provenance on retrieval, so a stale memory is not treated as the current configuration.
5. Workflow orchestration — 09, model a patch flow as a state machine; 10, bind approval to a patch version, so the patch that is written is the one the user reviewed.
6. Evaluation — 11, build a regression set from task end states; 12, use traces to locate the failing step, instead of scoring only the final sentence.
7. Reliability — 13, bound timeouts, retries, and cancellation; 14, design idempotent recovery for steps with side effects, distinguishing “not run,” “already applied,” and “unknown.”
8. Safety — 15, reject arbitrary commands and indirect prompt injection; 16, finish a safety regression and a system-design recap, showing that the agent can complete a task and also stop at a boundary.

The ninth theme, tearing down mainstream agent products (lessons 17–21), looks at permissions, sessions, and tickets: deny rules versus hooks, rebuilding the active branch from a JSONL tree, last-match permission rules and a sub-agent’s own table, admission rules and ticket stages, and finally a review of your own harness against those boundaries.

The tenth theme, a close reading of Super-Agent architecture (lessons 22–26), is labeled on the site as a study of a prototype, not an official product. It starts with why the design splits a Router from a Worker, then covers admission rules before the model, ticket stages and the two sessions, recording effects before they run, and the authorization boundary—including designs that appear in an article but are not implemented in the prototype.

“How mainstream products do it” is a documented comparison

Lessons 01 through 16 each include a section titled “How mainstream products do it” (主流产品怎么做). The references are four publicly documented systems: Claude Code, Pi, OpenCode, and DeepSeek Super-Agent. The last of these is labeled in the course as a research prototype, not an official product. It should not be described as a shipping official product.

Each note has a source link and a checked-on date. When I wrote this, that date on the site was 10 November 2026. The point of the section is to read the boundaries as the docs state them, then judge your own runtime against those boundaries—not to grade a product by what a model says about itself.

One clarification: not every lesson quotes all four products. A lesson cites the documents that are relevant to that topic—the loop and model adapters in one, compaction settings in another, permissions and hooks in a third. Lesson 16 also includes a comparison table that puts the loop, tools, and permissions side by side.

Lessons 17–21 turn some of those boundaries into standalone exercises: Claude Code’s deny and ask rules still override a PreToolUse allow; Pi rebuilds the active branch from a JSONL tree, and a compaction entry only replaces the prefix the model sees; OpenCode uses last-match rules, and a sub-agent has its own permission table; in the Super-Agent prototype, events pass code-level rules before a ticket stage. Those claims are the ones already sourced in the lessons. I am not adding new assertions about those products here.

Three lessons let you write TypeScript and run tests in the browser

Lessons 01, 05, and 09 include an in-browser editor. You can write TypeScript and click “Run tests” without signing in, and without first setting up a local toolchain. The note under the editor is explicit: the code runs in the browser, cannot call this site’s APIs or the public network, and a single run lasts about three seconds at most.

Under the hood, the learner’s TypeScript is compiled in the browser, then executed inside an iframe that allows scripts only, with the tests running in a Web Worker. The iframe does not share the page’s origin and has no network access. If a run overruns the deadline, the page aborts it. I wanted the exercises to be easy to start, without executing learner code on the site’s own servers.

When every test passes, the lesson is marked complete. If you are signed in with GitHub, that status is written to your learning record. If you are not signed in, the result stays in the current browsing session; it will not survive a refresh or a new device until you sign in and save.

Only these three lessons have a runnable editor today. The other lessons still have a concept, an example, a written exercise, acceptance checks, and an interview follow-up, but you complete them in your own environment or by working through the explanation.

The screenshot above is the starter for lesson 01. The template deliberately leaves the fake models unimplemented, so a first run fails—that is the exercise, not a site error. The tests pass once the diagnosing model and the loop budget are filled in.

After you sign in, progress syncs to Cloudflare D1

You can browse the course and run the browser exercises without an account. The site says that signing in lets you sync learning records, and the header offers GitHub login. After you sign in, lesson status, exercise code, and completion records are stored in Cloudflare D1, so you can continue in another browser. Without a login, those records are not kept as durable, cross-device progress.

The stack, and a few design choices

The site is a Next.js app, running on Cloudflare Workers through vinext. Learning records live in Cloudflare D1 and are accessed with Drizzle. GitHub login identifies the learner and syncs progress; it is not required to read the lessons.

A few choices are worth spelling out.

First, the course adds capabilities to one coding agent, instead of switching to an unrelated demo in every lesson. The homepage calls this the project mainline: each lesson adds something you can verify, and later lessons hang off those dependencies.

Second, product comparisons and the architecture close reading are separate. Lessons 01–16 build the runtime and cite public docs; 17–21 turn selected boundaries into exercises; 22–26 close-read the Super-Agent research prototype, and they keep distinguishing designs described in an article from what the prototype actually implements.

Third, learner code runs in a browser isolation layer, not on the server. No network access and a three-second timeout are part of that boundary.

Fourth, DeepSeek Super-Agent is treated throughout as a research prototype. Lesson 22 explains the split: a long-lived Router (the main session) talks to the human and coordinates globally, and does not execute the task itself; a Worker isolated per ticket has its own session and directory, and is given the full tool set. That layer sits on DeepSeek Harness’s plugin architecture—model adapters, the tool registry, session logs, and the agent loop can all be plugins, and dsh-superagent is a plugin pack on that harness. The lesson also states that the article and the prototype are not the same thing, so a design from the article should not be described as a class that already exists in the prototype.

Current status and limits

The site is live, and the homepage also works at a mobile width. The interface is Chinese only.

A few other limits are worth knowing up front. Only lessons 01, 05, and 09 have runnable in-browser exercises. The product notes are dated, selective citations, not a complete review of any product. The Super-Agent lessons discuss a research prototype and a public article, not an official product manual. Completion status is not saved as durable progress unless you are signed in.

How to start

Open https://agent-lab.umic.io. You can browse all twenty-six lessons without signing in, and start the in-browser exercise in lesson 01. Use GitHub login if you want the learning record to persist.

I built the lab to break coding-agent engineering into exercises you can verify one step at a time: write the loop, then tools, context, orchestration, evaluation, reliability, and safety, and keep the public docs of existing systems in view. If you are building a similar runtime, start at lesson 01 and get the tests to pass.