AI Agent Is Just a Loop: Building One with TypeScript and Zero Frameworks

Skip the Framework — An Agent Is Just a Loop

Whenever AI Agents come up, most developers instinctively reach for LangChain, start learning graph APIs, and spend time wiring up configuration files. But one YouTube creator makes a striking point: an Agent is fundamentally just a loop. No framework, no graph builder, no config files — just TypeScript and a loop.

In the demo, a single question triggers two tool calls from the model, which then answers correctly using real values — all without a single framework involved. The creator's sharp observation: most so-called frameworks are just heavy machinery wrapped around a function that runs a model request.

The Core Insight: The Model Never Calls Your Code — It Only "Requests"

Understanding Agents requires a mental shift: the model never directly calls your code — it only makes a request. The model returns a message that essentially says "please run this tool with these parameters," and it's the loop you write that actually decides what gets executed.

This means the model's response isn't a string — it's a collection of "blocks": some are text blocks, others are tool-use request blocks, each carrying a tool name and arguments. There's also a stop reason that tells you whether the model considers its task complete.

Understanding this data structure is the foundation of all Agent logic. You don't need magic — you just need to read the blocks the model sends back.

This design isn't accidental; it stems from how large language models reason. When generating a response, a model is fundamentally predicting the next token — it has no ability to "actively execute" anything. Tool calling (Function Calling / Tool Use) is a capability model providers add during fine-tuning: through special system prompts and training data, models learn to output structured JSON requests at the right moment instead of free-form text. Anthropic's Claude calls this a "tool use block"; OpenAI calls it a "function call" — but the underlying mechanism is the same. The model outputs structured data, and external code is responsible for parsing and executing it.

Understanding this dispels a common misconception: frameworks don't grant models any magical ability to "call code." They simply automate the mechanical steps of parsing the response, routing to the right function, and writing results back into the message history. Writing the loop by hand makes this process transparent; frameworks turn it into a black box.

The Full Agent Flow: Send, Receive, Decide, Repeat

The author breaks down the complete Agent flow with remarkable clarity:

• Send a message to the model and get a response;
• If the stop reason is not tool_use, the model is done — return its text;
• Otherwise, the model wants to call tools. Iterate over each tool-use block, validate the arguments, run the corresponding function, and push the result back as a tool_result message;
• Then loop — let the model see what the tools returned.

And "tools" themselves are completely demystified — a tool is just a regular function that takes parameters and returns JSON. It could be a calculator, a search call, an HTTP request — each one is just a function. This grounded framing brings Agent from a lofty concept back to its engineering essence.

Two Safeguards That Make It Production-Ready

Writing the loop by hand doesn't mean being careless. The author proposes two critical guards to ensure safety in production:

Guard 1: Validate arguments before dispatching. The model might "hallucinate" a malformed argument structure. Validate before actually executing the tool — a bad call should throw immediately, not corrupt your tool function.

Guard 2: A step cap. If the model keeps requesting tools without ever saying "I'm done," the loop runs forever. Set a max steps counter — throw an exception at step 5, for instance — and you prevent the loop from running out of control.

These two safeguards address the robustness shortcomings of a hand-written loop, making it not just a demo but a solution you can actually ship.

When to Use a Framework, When to Hand-Roll It

The author is careful to clarify: this isn't an argument against frameworks — it's about matching the tool to the task.

Hand-writing the loop makes sense when you have a small number of tools, a single model provider, and want to be able to read the control flow end-to-end. But when you need to support multiple model providers, require tracing, or need shared conventions across a team, you should reach for a framework.

This pragmatic nuance is more valuable than simply arguing "frameworks are useless." It acknowledges the real-world value of frameworks in complex scenarios, while reminding developers: in simple scenarios, a loop you can read from top to bottom is often more controllable than a stack of black-box abstractions.

Where Do Real Tools Come From? MCP.

The final question: where do real tools come from? The author's answer is MCP (Model Context Protocol) servers. The loop is the brain; MCP is how that brain safely reaches your files, databases, and APIs.

This philosophy runs throughout the entire approach — no framework, no magic, just a loop you can read from start to finish. It's worth noting that the author also emphasizes doing AI engineering in TypeScript rather than Python, which is an interesting perspective shift for developers accustomed to the Python ecosystem.

MCP (Model Context Protocol) is an open standard proposed and open-sourced by Anthropic in late 2024, designed to solve the fragmentation problem in integrating AI models with external tools and data sources. Before MCP, every application needed custom integration code for every data source — an M×N maintenance nightmare. MCP simplifies this to M+N: any MCP-compatible client (such as Claude, Cursor, etc.) can communicate with any MCP server without additional adapters.

An MCP server is essentially a lightweight process that communicates with the host application via standard I/O or HTTP+SSE, exposing three types of capabilities: Tools — functions the model can call; Resources — data the model can read; Prompts — reusable prompt templates. In the context of an Agent loop, an MCP server acts as both a tool registry and an execution sandbox — letting the model discover available tools while using process isolation to limit tool permissions, preventing the Agent from directly accessing sensitive resources in the host process.

Closing Thoughts

The value of this content isn't in teaching you a new framework — it's in pulling back the curtain on Agents. Once you understand the core truth that "the model only makes requests, and the loop is the decision-maker," you'll find that many complex framework concepts can be reduced to a few dozen lines of readable code. For developers who want to truly understand how Agents work — rather than just knowing how to call an API — hand-writing this loop once will likely teach you more than ten framework tutorials ever could.