Beyond the magic trick

AI agents are often talked about as if they were sentient digital beings — autonomous entities reasoning in the cloud. But if you strip away the heavy orchestration libraries, multi-agent frameworks, and marketing jargon, what’s actually happening under the hood?

To find out, I built mini-harness: an autonomous coding agent written from scratch in roughly 180 lines of TypeScript with zero frameworks. Just the raw Anthropic SDK, a few basic filesystem and web tools, and a simple loop.

Building it dispelled the mystery. An agent isn't magic; it’s an architectural pattern built on a few surprisingly straightforward principles.

1. Memory is just an array

There is a common misconception that an agent maintains a complex internal brain or an opaque neural state during a session.

In reality, session memory is just an in-memory array:

const history: MessageParam[] = []

Every user prompt, every assistant answer, and every tool result gets pushed into that single array. Whenever the agent needs to think, that entire history is sent over HTTP to the model.

When you type /reset in the terminal, all the code does is history.length = 0. The agent doesn’t undergo a deep reset process; it simply experiences instant, total amnesia. The model doesn't remember you — the prompt history does.

2. Errors are data, not crashes

In normal software engineering, when a function encounters an invalid state — like a missing file or a failed network request — it throws an exception.

In an agent loop, throwing an exception is fatal. If the agent crashes because of a typo in a filename, the whole interactive session dies.

The solution is deceptively simple: treat errors as data. If read_file can't find a file, don't throw. Return a plain string: "ERROR: file not found: config.json".

The LLM receives this string in the next turn as a tool result. Because the model understands English, it reads the error, reasons about what went wrong, and adjusts: "Oh, config.json isn't there, let me list the directory to see what files exist." Resilience doesn't require complex retry algorithms; it just requires feeding failure back to the model as context.

3. The tool catalog is the boundary

How does the agent know what it can and cannot do?

Not through magic operating system privileges, but through a catalog of JSON schemas. The model can only request tools that you explicitly advertise in its prompt definitions. If you give it read_file, write_file, list_files, and web_fetch, that is its entire universe.

The model doesn't actually "run" the tools itself. It generates a structured JSON block saying: "I would like to call read_file with path: package.json". Your host code reads that request, runs the local function, and hands the result back. The agent is always operating within the prison of its advertised catalog.

4. Understand the loop before you adopt a framework

Modern AI frameworks like LangChain, CrewAI, or AutoGen offer immense feature sets. But when you start with them, the abstraction hides the mechanics. You end up debugging complex framework classes instead of understanding how the model actually interacts with tools.

Building a minimal harness from scratch takes less than an afternoon, but it completely demystifies the technology. It shows you that an agent is fundamentally:

1. An input prompt.
2. A loop that asks: "Did the model ask to run a tool, or is it done?"
3. If it asked for a tool, run it, append the answer, and repeat.

The whole loop, end to end:

user turn ──▶ history[] ──▶ ask() ──▶ [ Claude Model ]
                    ▲                        │
                    │ stream (SSE)           │ tool_use
                    ▼                        ▼
        tool_result[] ◀── runTool() ◀── (Promise.all)
└────────── loop until stop_reason !== "tool_use" ──────────┘

Once you see how simple the foundation really is, you stop treating AI agents as black magic — and start treating them as software you can inspect, understand, and control.