Close the Source, Build It Yourself

Having finished Part II · Pi in Source, Xiao A closed the pi-mono code and let out a long breath: "At last I can at least follow how a real Agent gets put together."

Lao Z turned the laptop around and showed him an empty directory. "Then now, write one yourself."

Xiao A froze. "Copy pi? How long would that take?"

"Not a copy job," Lao Z said. "Part II · Pi in Source showed you how a real project cuts its boundaries. Part III · Build It asks you to make trade-offs for your own requirements. The next step is to decide first what your Agent will not do."

What We Are Building

Xiao A: "So how big are we building it? We can't rewrite pi from scratch."

Lao Z laid out a delivery list:

What this part delivers

The code in every chapter must compose into one runnable artifact, not a set of independent fragments that never fit together. The final artifact gains these capabilities chapter by chapter:

• call a model and report streaming events, errors, and aborts;
• maintain message state, stop reasons, tool calls, and a round budget;
• run the read, write, and bash tools sequentially, each constrained by a schema and by workspace boundaries;
• let runAgent save, restore, and apply deterministic character trimming when the caller passes sessionPath / contextMaxChars, and provide diagnosable command-line interaction on top;
• trigger Hooks or approval before a risky action, and state the real boundaries of sandboxing, permissions, and secret handling.

Definition of Done: Verification, Not "Looks Reasonable"

Xiao A: "How do I know when it's finished, and that it's correct?"

Lao Z tapped the table. ""Looks reasonable" is not a definition of done. Every stage must ship an executable verification command, the expected result, and the known limits. The last chapter tests whether these parts work together, using the complete code, the tests, and actual run output. Verification covers the normal path, and at minimum the necessary error, interruption, or boundary paths too."

"Any other traps?" Xiao A pressed.

Lao Z: "One, and it has to be said up front:"

Separate library capability from entry-point assembly

Neither the current main.ts nor runCli() passes sessionPath or contextMaxChars to runAgent. Therefore npm start and the current runCli() call do not persist, restore, or trim a session; these capabilities are reachable only by calling runAgent directly and passing the arguments explicitly.

Xiao A felt a bit unsure. "So how far can I get? Won't people say 'that isn't an Agent'?"

"This part promises no production-grade general platform. Real Providers get no end-to-end acceptance; MCP, Skill, and multi-agent keep only the extension points that requirements prove necessary; capability that is out of scope gets its limits stated, and never gets faked with an empty interface." Lao Z paused. "The one implementation lives in examples/mini-agent, and the chapters fill in its code and verification steps one by one. Run results, test counts, and performance numbers that have not been verified get no forecast here."

"Then what does this part solve, and what does it not solve yet?" Xiao A asked.

What this part solves

After reading Part III · Build It, you can build a runnable, verifiable, scope-bounded Agent from scratch in TypeScript: take in one model stream, run one loop, let the tools actually land, let the session continue, give the CLI a reliable entry point, and stop risks before execution. Its value is not feature completeness: every control flow, every data type, and every test boundary is there for you to read at the same time.

Production-platform problems are not solved here yet: retry, REPL, OS-level sandboxing, network control, and multi-Provider end-to-end acceptance are out of scope; MCP, Skill, and multi-agent stay at interface reasoning and never enter src.

Xiao A added: "And these twelve chapters — does each one add a piece to the artifact?"

"Yes, and the order is the dependency order," Lao Z said. "Decide what not to do first (scope). Then connect the model stream (pipeline). Hand the next step to the loop (control). Land the tools (capability). Let the context continue (state). Give a person a reliable entry point (interaction). Put a gate before execution (safety). Leave interfaces for change (extension). Finally assemble the parts into a machine (assembly). Each chapter adds one block, each block is the precondition of the next, and reading them out of order will not connect."

Xiao A thought for a moment. "How do I confirm each chapter is really done right?"

"Every chapter ends with a Stage Acceptance," Lao Z said. "It does not accept 'I think that's close enough'. It accepts only executable verification: what the command is, what the expected output is, what failure looks like. Write the acceptance conditions first, then write the code. The code exists to satisfy the acceptance. Many tutorials teach you to write an Agent. This part writes one with you where every line has verification."

Why Read This Part Now

Xiao A cleared his desk, then asked suddenly: "Where do we start?"

Lao Z smiled. "Don't rush into writing code. Same rule as before: decide what not to do first. From here on, every choice moves forward through design discussion, pair programming, and troubleshooting: write the acceptance conditions first, then let the code and the verification results speak."

Start here: Part III Chapter 1: The Blank Sheet and the Boundary — Scope