A developer shows an AI agent can run on about 200 lines of plain TypeScript

The agent is just a loop

As dev.to reported, one developer has published a complete AI agent "harness" in plain TypeScript, with no framework and no dependencies. A harness is the code around a language model that lets it act: it holds the conversation, runs tools and decides when to stop.

The author's argument is that the agent itself is not complicated. You send messages to a model, run whatever tools it asks for, send the results back, and finish when it stops asking. Too many projects, the author says, begin with a framework install and end in a debugging session inside someone else's design.

The post puts the total at just over 200 lines. Every line can be read, tested and changed when the agent misbehaves.

What the 200 lines contain

The author lists six parts. The loop owns the message history and decides when to stop. The tool registry maps each tool's name to a description, a format for its inputs and the code that runs it. A single model interface means swapping AI providers means swapping a small adapter, not rewriting the agent.

Three more parts are about control. The limits cover maximum turns, maximum cost and a guard against repeated calls. A verifier is a function that checks the final answer before the run counts as finished. An approval gate makes actions that write data or spend money wait for a human yes, while reads run freely.

The author borrows this structure from a Thoughtworks guide to harnesses. The loop covers five of its parts directly, and the approval gate covers the sixth, human sign-off for high-risk actions.

How it fails safely

The post says the failure paths are the real design. If the model asks for a tool that does not exist, or a tool throws an error, that becomes a message back to the model so it can correct itself instead of crashing the run.

If the model makes the same call twice in a row, the run stops rather than spending money going in circles. A write tool with no approver set is blocked, not allowed. A bad final answer fails verification loudly instead of shipping quietly.

The author also chose to run tool calls one at a time, not in parallel. Parallel is faster, but sequential runs keep results in order and make a bad run easier to read. The post suggests adding parallelism only once a slow run has been measured.

• The worked example is a refund assistant with one read tool, one refund tool behind approval, and a check that the answer contains an order id.
• The sample settings cap a run at 12 turns and a cost of 0.5 dollars.

What was tested, and the gaps

The author is open about the limits of the testing. The harness was run against a stub model that returns scripted tool calls, not a live model with real money. That was enough to confirm that the turn limit, cost budget and repeated-call guard fire, that an unapproved write is blocked, and that an answer without an order id fails verification.

The sample code also has two admitted gaps. The cost figure is set to zero in the example adapter, because real cost needs a per-model price table, and a cost limit that never moves does nothing. Tool inputs are also not yet checked against a schema, so the author says to validate them before pointing this at real data.

The author's advice for a real model is to run about ten small tasks with a deliberately low cost cap and compare the spread. If one task costs far more than the typical one, read its history before raising the budget.

When a framework still earns its place

The post does not say frameworks are bad. It says they pay off later, when you need runs that survive restarts, routing between several agents, or monitoring you do not want to build yourself. On day one, with one agent and a handful of tools, the author says the framework is the biggest thing in the project.

The author cites an InfoQ piece from October 26, 2026 that traces the field from simple prompt chains to branching workflows to harnesses that check outputs by running them. InfoQ's advice, as the author relays it, is to validate model outputs and choose the simplest design that meets your needs for reliability, speed and cost. Anthropic, the post adds, argued the same month for folding subagents into one main loop.

Our copy of the post cuts off partway through the author's list of cases where a framework wins, so we have only the first of them: runs that must survive restarts, where a plain loop holds state only in memory.