Previous article：AGENTS.md for AI Coding Agents: Load Project Rules into LLM Context
中文版：Mini Harness Recap：14 天架构复盘

Introduction

Day 14: connect context, tools, safety, and observability into one small, inspectable coding-agent harness. This chapter keeps the implementation deliberately small: the point is to make one boundary explicit, testable, and easy to inspect before adding more autonomy.

The completed harness

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 14 focuses on that runtime boundary instead of hiding it behind a single prompt.

context → model → bounded agent loop → tools → safety → transcript and reports

How the layers connect

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.

• Keep context assembly, execution, safety, and observability separate.
• Use the CLI to exercise the complete path end to end.
• Treat the result as a foundation for skills, MCP, and product integrations.

A practical end-to-end run

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 -- --overview

user task + AGENTS.md + project snippets + tool definitions
  -> context builder
  -> model provider
  -> agent loop
  -> tool registry
  -> approval gate + workspace sandbox
  -> tool result
  -> transcript + context report

observe -> decide -> act -> observe -> final

Where to go in phase two

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.