DEV Community: Tyler Buell

Reliable LLM agents in TypeScript: one harness you fully control, from a local 4B model to Claude

Tyler Buell — Sat, 27 Jun 2026 00:16:49 +0000

Every agent framework demo works. You wire up a couple of tools, point it at a frontier model, ask it something, and it nails it. Looks great in a tweet.

Then you point it at a real task with a smaller model and watch it fall apart on the third tool call.

That was most of my spring. I'd get an agent working nicely against Claude, swap in a local model to stop paying per token, and it would emit a tool call that was almost right — a tool named getServiceHealth instead of get_service_health, a param called svc instead of service, a path with a stray quote — and the loop would just die. Re-prompt, retry, burn through iterations doing nothing, give up. The model could do the task. The harness around it couldn't keep the loop alive long enough to find out.

So I stopped trying to fix the model and built the harness. It's called Reactive Agents — a composable TypeScript framework for building reliable LLM agents on a harness you fully control. It's organized around three things I kept wishing the other frameworks did:

Reliability — the loop actually finishes.
Transparency — I can see and steer every step instead of guessing at a black box.
Composability — I add what I need and skip what I don't.

Reliability is the part I'm proudest of, so let me show you instead of telling you. Here's the same agent — investigate a service alert, call two tools, correlate the data, recommend a fix — running on a 4B local model and on Claude. The only thing that changes between the two runs is one line:

Same builder, two models

import { ReactiveAgents } from "reactive-agents";

const agent = await ReactiveAgents.create()
  .withProvider("ollama").withModel("qwen3:4b")              // runs on your laptop
  // .withProvider("anthropic").withModel("claude-sonnet-4-6") // frontier — same code, one line
  .withReasoning()
  .withTools({ tools: [getServiceHealth, getRecentDeploys] })
  .build();

const result = await agent.run(
  "The payments-api is alerting. Investigate with the health and recent-deploys " +
  "tools, then tell me the likely cause and what to do."
);
console.log(result.output);

No if (local) branch. No second code path. The agent runs the same think → act → observe loop, calls get_service_health and get_recent_deploys, notices that the degradation lines up with a deploy from twelve minutes ago, and says: roll it back. On a 4B model and on Claude. (The two tools are plain ToolBuilder.create(...) definitions — here's the demo source.)

Let me be straight about what this is and isn't. A 4B model is not as smart as Claude, and I'm not pretending it is. The claim is narrower and a lot more useful: the same code finishes the loop. So I build and test locally, on my own hardware, for free, and swap one line to a frontier model when the task actually needs the horsepower.

Why the small-model loop usually dies — and what keeps it alive

Two things do most of the work.

First, context profiles. Small models have a small effective context and drown in verbose prompts. So the local tier gets leaner prompts and more aggressive compaction:

.withContextProfile({ tier: "local" })   // lean prompts, aggressive compaction

Second — and this is the one that actually moved the needle — a healing pass on tool calls. Remember the getServiceHealth-instead-of-get_service_health problem from the top? A naive loop sees "invalid tool" and gives up. The healing pipeline fixes the obvious near-misses — tool names, param aliases, paths, types — before the call runs, so "almost right" becomes "ran." That one pass is the whole difference between the 4B run in that GIF finishing and stalling.

You don't turn any of this on. It's just what .withTools() does.

The part I actually trust in production: a typed runtime

The local-model thing is the fun demo. The reason I'd run this on something that matters is underneath it.

It's built on Effect-TS, which usually makes people groan, so let me get ahead of it: you don't write Effect to use this. The builder and hooks are plain async functions.

What you get for free is a runtime that's typed end to end. A failed tool call or a model timeout is a typed value in an explicit error channel — not an exception you meet for the first time in prod at 2am. Retries and fallbacks compose. Structured output is schema-checked before it lands in your hands.

.withHook({
  phase: "act",
  timing: "after",
  handler: (ctx) => {
    const last = ctx.toolResults.at(-1);
    console.log("tool:", last?.toolName);
    return ctx;            // that's the whole hook contract. no Effect.
  },
})

You can see what it's doing

This is the thing I missed most everywhere else. Every run is a fixed 12-phase lifecycle — bootstrap, guardrail, cost-route, think, act, observe, verify, and so on — and every phase has before / after / on-error hooks. I can watch and steer any step, locally, without shipping my traces off to someone's dashboard.

import { ReactiveAgents, HarnessProfile } from "reactive-agents";

const agent = await ReactiveAgents.create()
  .withProvider("anthropic").withModel("claude-sonnet-4-6")
  .withProfile(HarnessProfile.balanced())   // memory + reactive intelligence + verifier
  .withTools()
  .withBudget({ tokenLimit: 100_000 })      // hard spend cap
  .build();

Memory, MCP tools, multi-agent, durable resume — opt-in layers on the same engine. Add the ones you want.

When the process dies mid-run, it picks up where it left off

Here's the other half of reliability, and honestly the feature I'd lead with for anything long-running: agents crash. The box reboots, the container gets rescheduled, a deploy rolls your process. Usually that means starting the entire run over — and re-paying for every tool call and token you already spent.

With .withDurableRuns(), every iteration is checkpointed to disk. Kill the process mid-run, and a fresh one picks up the exact run from its last checkpoint and finishes it. The tools that already ran don't run again.

// Process A — works, checkpoints each step, then gets hard-killed.
const a = await build();                       // .withDurableRuns({ dir })
for await (const _ of a.runStream(task)) { /* ...process dies mid-run... */ }

// Process B — a fresh start, same agent, same dir.
const b = await build();
const runId = (await b.listRuns({ status: "running" }))[0].runId;
const result = await b.resumeRun(runId);       // reconstructs + finishes

The same checkpoint machinery is what makes human-in-the-loop durable too: a gated tool call pauses the run, saves it, and someone can approve or deny it from a completely different process to pick it back up.

When you should not use this

Let me save you some time.

One provider, a simple loop? Use that vendor's Agent SDK. You don't need a harness, and I won't be offended.
Want the biggest ecosystem and the most tutorials today? That's LangChain or Mastra, not me. This is early.
Need something that's been battle-tested across a thousand production deployments right now? It isn't that yet — v0.12, MIT, ~6,500 tests. I'd rather say that out loud than have you find out three weeks in.

If you're comparing, the docs have honest side-by-sides with LangGraph, Mastra, the Vercel AI SDK, and the vendor Agent SDKs.

Try it

bun add reactive-agents
# or: npm install reactive-agents

Repo: https://github.com/tylerjrbuell/reactive-agents-ts
Docs: https://docs.reactiveagents.dev
The exact demo above: apps/examples/src/demos/local-vs-frontier.ts

If you run the local-model path, I'd love to know which model you tried and whether the healing held up — that's the bit I most want people to throw real workloads at. Issues and feedback welcome; I read all of them.

Building an Agentic Framework from scratch 🚀

Tyler Buell — Fri, 16 Jan 2026 21:32:37 +0000

Building an Agentic Framework for Smart, Reactive AI Agents

AI Agents are rapidly playing a more prominent role in modern software development, but building them well is surprisingly tricky. In this article, I’ll share the design and development journey behind Reactive Agents, a framework I built to make reactive, adaptable AI agents easy to create while giving developers control, observability, and flexibility.

The Challenge: Why Build a New Framework?

I was honestly curious what it would take to build agents that can think and reason using their own strategies similar to how we go about tasks. Agentic frameworks at the time had little control over how to build decent agents with less code, so I wanted to try my take at it.

Most existing agent frameworks either:

Treat agents as simple LLM + tool loops
Require verbose or repetitive setup
Limit flexibility in reasoning or strategy

From day one, I wanted something different:

Agents that can think, act, and pivot mid-task
Clear and type-safe APIs that are easy to reason about
Composable strategies to adapt to any agentic task
Observable events so developers always know what the agent is doing and why

The goal was simple: make building smart, reactive AI agents intuitive, safe, and powerful, without sacrificing flexibility.

Core Principles of Reactive Agents

When designing the framework, I focused on several key principles:

Reactive Decision-Making

Agents respond to task inputs and intermediate results rather than following a fixed plan.
Built-in reflection allows them to pivot strategies if outcomes differ from expectations.

Tool Integration and MCP Support

Agents can execute custom Python tools or leverage MCP servers for modular workflows.
This enables distributed, multi-tool pipelines without complex orchestration.

Observability and Transparency

Every agent action emits observable events.
Developers can track reasoning, tool usage, and decision paths in real time.

Composability and Type Safety

Reasoning strategies are modular, easy to swap, extend, or combine.
Type-safe APIs reduce runtime errors and make development predictable.

Ease of Use

The builder pattern provides a clean, minimal boilerplate setup.
Quick startup time and wide model support make experimentation fast and rewarding.

Designing the Reactive Loop

At the heart of the framework is the reactive loop, which guides how an agent processes tasks:

Receive Task → Agent gets input from the user or system
Reasoning Layer → Decide which tools or strategies to use
Tool Execution → Run custom or MCP-based tools
Observe Feedback → Track events, results, and outputs
Reflect & Adapt → Update strategy if needed, then repeat

This architecture ensures agents are not static. They learn and adapt in-flight, making them suitable for a wide range of agentic tasks.

Diagram Concept:

Task Input → Reasoning → Tool Execution → Observation → Reflection → Next Action

Implementation Highlights

While building Reactive Agents, a few design choices stood out:

Builder Pattern: Simple, readable agent creation.
Composable Strategies: Swap reasoning modules without rewriting the agent.
Observable Events: Makes debugging and insight seamless.
Type-Safe APIs: Catch errors early, improve developer confidence.
MCP Integration: Supports distributed agent architectures and modular workflows.

These choices collectively differentiate the framework from simpler orchestration layers or monolithic agent implementations.

Example: Minimal Reactive Agent

Below is an accurate, documented-aligned example showing a reactive agent using both a custom Python tool and an MCP tool:

import asyncio
from reactive_agents.agents import ReactAgentBuilder
from reactive_agents.tools.decorators import tool

# Define a simple custom tool
@tool(description="Greet a user")
async def greet(name: str) -> str:
    """Use this tool to greet the user by their provided name"""
    return f"Hello, {name}! Welcome to Reactive Agents."

async def main():
    agent = await (
        ReactAgentBuilder()
        .with_name("DemoAgent")
        .with_model("ollama:qwen3:4b")          # Example model string
        .with_tools(["brave-search", greet])  # Auto-detects MCP tools vs custom tools
        .with_observable_events()              # Track events
        .build()
    )

    result = await agent.run(
        "Greet a new user and fetch latest news about AI."
    )
    print(result)

if __name__ == "__main__":
    asyncio.run(main())

Lessons Learned While Building the Framework

Design for observability early – It’s hard to debug complex agents without event tracking.
Make reasoning modular – Composable strategies allow experimentation without breaking existing code.
Keep APIs intuitive – Developers should spend more time designing agents than wrestling with setup.
Support multiple tools and providers – Flexibility is essential for real-world agentic tasks.

Looking Forward

Reactive Agents is alpha-stage, but production-ready. APIs may evolve, but the core principles are stable: reactive loops, composable reasoning, observability, and tool integration.

I hope this framework inspires developers to explore agentic AI in new ways, creating smarter applications that don’t just respond, but reason, act, and improve dynamically.

Get Involved

Try it, star the repo, or contribute:

GitHub: https://github.com/tylerjrbuell/reactive-agents

Supercharge Your Productivity with Ollama + Open Web UI and Large Language Models

Tyler Buell — Thu, 07 Mar 2024 19:45:40 +0000

As a developer, productivity is crucial in today's fast-paced tech industry. One effective way to boost your productivity and tackle challenges efficiently is by utilizing large language models (LLMs). Most developers are probably familiar with LLMs such as OpenAI's GPT-3.5 and GPT-4, however, other alternatives exist that are private (no more sending your data to OpenAI), open source, and free of cost! In this article, we will explore how to harness the power of these tools to enhance your daily tasks and problem-solving abilities.

Understanding the Tools: First, it's essential to familiarize yourself with Ollama, a lightweight service that can be easily installed on all platforms and makes getting up and running with local LLMs a breeze. With Ollama, developers can run, customize, and even create their own models. The Open Web UI interface is a progressive web application designed specifically for interacting with Ollama models in real time. You can think of the Open Web UI like the Chat-GPT interface for your local models. The Open Web UI Interface is an extensible, feature-rich, and user-friendly tool that makes interacting with LLMs effortless. Open Web UI allows you to engage in conversations with multiple models simultaneously, harnessing their unique strengths for optimal responses. They can also integrate OpenAI API for even more versatile conversations.

Setting up the Environment: To get started, install Ollama on your local machine or container using the install options for your platform of choice. Once Ollama is installed and running it's time to run the Open Web UI interface. There are many provided methods for installation, however, Docker is by far the easiest. Run the following command 👇 (assuming you already have Docker installed on your machine)

docker run -d -p 3000:8080 --add-host=host.docker.internal:host-gateway -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:main

After installation, visit the Open Web UI interface by opening your web browser and navigating to http://localhost:8000.

Create a local admin user at the login screen by clicking sign up which will then allow you to log in to the interface.

Before you can begin chatting, you must first download your first model. Go to the settings popup and under models, you can enter any model name to download from the list of supported Ollama models (see screenshot)

Boosting Productivity: Now that you have your tools prepped and ready, it's time to leverage the power of LLMs to take your daily workflows to the next level! Here are some examples of how you can use Ollama + Open Web UI to be a more productive developer:

Coding Assistant: The most obvious way to use these tools is to use code models such as starcoder to help you with code suggestions, writing boilerplate or project organization tasks.

Brainstorming Assistant: Create a custom model in the Open Web UI with a specific prompt to be your Rubber Ducky to bounce ideas off of and help you debug those pesky bugs.

Feature Requirement Analyst: Use the Open Web UI documents feature to upload feature requirement documents such as CSV or PDF files and use them in your chat conversations to easily probe into and summarize deep topics that you will need to write your features.

Dev.to Article Assistant: Add a URL into your chat conversations to let the LLM assist you in parsing real-time website data to give you ideas on your next article (kind of like I did with this one 😉)

These are just some examples of how to use these tools to make your daily workflows more productive but the sky is the limit!

In conclusion, by incorporating Ollama's seamless local platform to run open-source large language models coupled with the feature-rich and user-friendly Open Web UI interface into your daily development tasks, you can significantly enhance your problem-solving abilities and increase your overall productivity. Give it a try today and join the growing community of developers who are already supercharging their coding experiences!