Previous article：Day 05 - Local File Tools
Next article：Transcript Logging for AI Agent Runs
中文版：Agent Loop：Observe, Decide, Act / Coding Agent 执行循环

Introduction

Day 06 of the Mini Coding Agent Harness series: turn manual tools into a bounded observe-decide-act loop. This chapter keeps the implementation deliberately small: the point is to make one boundary explicit, testable, and easy to inspect before adding more autonomy.

Why an agent needs a loop

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

User task → model decision → tool dispatch → tool result → next model decision → final answer

The execution protocol

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.

• Parse a proposed tool call without granting it execution authority.
• Return each tool result to the next model turn as an observation.
• Stop after a configured step count or tool timeout.

Bounded steps, timeouts, and errors

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 -- --tool list_files --tool-input '{"path":".","maxDepth":1}'

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

npm run dev -- "inspect the repo and summarize the structure"

What this enables next

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.