Previous article：AI Coding Agent Security: Approval Gates and Workspace Sandbox in TypeScript
Next article：How to Build a Mini AI Coding Agent Harness in TypeScript
中文版：AGENTS.md：把项目规则注入 Agent 上下文

Introduction

Day 13: discover project rules and add them to an agent context with bounded size and traceability. This chapter keeps the implementation deliberately small: the point is to make one boundary explicit, testable, and easy to inspect before adding more autonomy.

Project guidance belongs with the project

A coding agent is more than a model response. It needs a runtime that can turn a request into controlled work, preserve the intermediate state, and explain what happened afterwards. Day 13 focuses on that runtime boundary instead of hiding it behind a single prompt.

workspace root → AGENTS.md discovery → bounded read → rules context part → model request

Discover and bound AGENTS.md

The implementation uses explicit data structures and narrow interfaces. The model proposes the next step; the harness owns validation, execution, limits, and structured results. That separation lets the same capability work in a CLI today and in a richer product surface later.

• Discover durable instructions at the workspace boundary.
• Cap their size before they can dominate the prompt.
• Report their source and token cost alongside other context.

Inject rules with provenance

Reliability comes from treating failure paths as normal paths. Inputs are bounded, unsafe or malformed requests produce recoverable errors, and the run records enough evidence to let a developer understand the decision. This is especially important when later steps can touch a real workspace.

npm run dev -- --workspace demos/day-13/workspace --context-report "load project rules"

workspace root
  -> discover AGENTS.md
  -> validate workspace path
  -> read with size limit
  -> add to system context
  -> report rules token usage
  -> model decides

Use npm workspaces.
Never edit generated files.
Run npm run typecheck before completion.
Prefer repository helpers over new dependencies.

Keeping fixture rules isolated

With this layer in place, later chapters can add capability without weakening the boundary: tools can be registered and observed, context can be measured, writes can require approval, and every run can be replayed. The result is not a general autonomous system; it is a compact harness whose behavior remains understandable.

Key takeaways

• Build the execution boundary before adding more tools or model freedom.
• Keep model intent separate from runtime authority.
• Make limits, validation, and failure results visible.
• Use structured observations to support debugging and future extensions.

Demo

The accompanying implementation and runnable examples are available in the cli-harness repository.