Most agent failures I’ve seen are not exotic. They are the same handful of boring problems, and boring problems have boring solutions. Here are the ones I keep coming back to.

1. Bound everything#

An agent is a while loop whose exit condition is decided by a probabilistic text generator. Read that sentence again and the first rule writes itself: never let the model be the only thing that decides when to stop.

Put hard limits on steps, wall-clock time, tokens and cost. When a limit trips, fail loudly with whatever partial state you have, rather than silently returning the last message.

2. Treat tool calls as untrusted input#

The model’s tool call is user input wearing a nice suit. Validate it with a schema, and when validation fails, feed the error back to the model as an observation instead of crashing. Models are surprisingly good at fixing their own arguments when told exactly what was wrong.

Here’s the skeleton I start from. It’s deliberately small — no framework — because the important ideas fit on one screen:

import json, time
from pydantic import BaseModel, ValidationError

class Search(BaseModel):
    query: str
    top_k: int = 5

TOOLS = {"search": (Search, lambda a: search_index(a.query, a.top_k))}

def run_agent(llm, task, max_steps=8, budget_s=60):
    history = [{"role": "user", "content": task}]
    seen = set()
    start = time.monotonic()
    for step in range(max_steps):
        if time.monotonic() - start > budget_s:
            return {"status": "timeout", "history": history}
        msg = llm(history, tools=list(TOOLS))
        history.append(msg)
        if not msg.get("tool_call"):
            return {"status": "done", "answer": msg["content"]}

        name, raw = msg["tool_call"]["name"], msg["tool_call"]["args"]
        key = (name, json.dumps(raw, sort_keys=True))
        if key in seen:  # same call twice = probably looping
            obs = "You already called this with identical arguments. Use the earlier result or try something different."
        elif name not in TOOLS:
            obs = f"Unknown tool '{name}'. Available: {list(TOOLS)}"
        else:
            schema, fn = TOOLS[name]
            try:
                obs = fn(schema(**raw))
            except ValidationError as e:
                obs = f"Invalid arguments: {e.errors()}"
            except Exception as e:  # tool failures are observations, not crashes
                obs = f"Tool error: {type(e).__name__}: {e}"
        seen.add(key)
        history.append({"role": "tool", "name": name, "content": str(obs)[:4000]})
    return {"status": "max_steps", "history": history}

Notice what the loop does not trust: the tool name, the arguments, the tool itself, the length of the output, or the model’s sense of when it’s finished.

3. Detect loops cheaply#

The duplicate-call check above catches a surprising fraction of runaway agents. It’s crude — a model can loop with slightly different arguments — but crude and always-on beats clever and never-shipped. A next step is to track whether the agent’s state is actually changing: new information retrieved, new files touched, new sub-goals completed.

4. Keep the context honest#

Long-running agents drown in their own transcripts. Truncate tool outputs (note the [:4000]), summarize old steps, and keep the original task pinned near the top. A lot of “the agent forgot what it was doing” bugs are really “we buried the instruction under 30k tokens of JSON”.

5. Make it observable before you make it smart#

Before tuning prompts, log every step: input, tool call, observation, latency, tokens. Then read the traces. Actually read them. In my experience, one afternoon of reading fifty failed traces teaches more than a week of tweaking prompts by vibes, because you start to see that failures cluster into maybe three or four categories.

6. Evaluate trajectories, not just answers#

A correct final answer reached through nine redundant tool calls is a latency and cost bug waiting to happen. Score the path too: number of steps, invalid calls, repeated calls. Those metrics are cheap to compute from the logs you already have from point 5.

The meta-lesson#

Agents look like an AI problem, but making them reliable is mostly a software engineering problem: input validation, timeouts, idempotency, observability, tests. The model is the most interesting component, and also the one you should trust least.

None of this is glamorous. That’s sort of the point.

The Stoics — Epictetus, Seneca, Marcus Aurelius — were not writing about software, obviously. They were writing about how to keep a clear head when things go wrong. That turns out to be most of debugging.

The dichotomy of control#

Epictetus opens his Enchiridion with a simple split: some things are up to us, and some things are not. Our judgments and actions are up to us. Everything else — other people, the weather, outcomes — is not.

A broken system is the perfect place to practice this. The bug already exists; being annoyed about it does not make it exist less. What is up to me is the next action: reading the stack trace, forming a hypothesis, writing a smaller reproduction.

When I’m frustrated, I’ve noticed my debugging becomes random. I change three things at once, rerun, and hope. The Stoic move is to drop the emotional commentary (“why does this always happen”) and return to the only thing in my control: one deliberate, testable step.

Judgments, not events, disturb us#

Another line from Epictetus: people are disturbed not by things, but by their judgments about things.

The production incident is an event. “I’m going to look incompetent” is a judgment layered on top. In my experience the second one does far more damage, because it pushes you toward the fastest fix rather than the right one — the patch that makes the alert go away instead of the change that addresses the cause.

Separating the event from the story I’m telling about it is a skill, and like any skill it gets easier with repetition. Incidents provide plenty of repetitions.

Premeditatio malorum#

Seneca recommended imagining in advance the things that could go wrong — exile, loss, illness — not to wallow in them, but to blunt their shock and prepare.

Engineers reinvented this and called it a pre-mortem: before launching, imagine it’s six months later and the project has failed. What happened? It’s remarkable how quickly a team can list the actual risks once it has permission to be pessimistic. The rate limiter nobody tested. The model that degrades on long inputs. The data pipeline with a single owner who’s about to go on holiday.

The Stoic version adds a personal layer: also imagine your own reaction. If this fails, how do I want to behave? Deciding that in advance, while calm, is far easier than deciding it at 1am.

The view from above#

Marcus Aurelius often zoomed out — picturing the earth as a speck, his own life as a moment in a long stream of time. In Meditations it’s a tool for humility.

In debugging it is a tool for escaping tunnel vision. After an hour deep in one function, I try to step back and ask: what is the system doing? Is the bug even in this layer? More than once, the bug I spent an afternoon chasing in model code was a stale cache, a misconfigured environment variable, or a dataset that changed under me. The view from above would have found it faster.

A caveat#

Stoicism is sometimes misread as “suppress your emotions and push through”. That’s not what the texts say, and it’s not healthy advice for engineers who already overwork. Frustration is information — often that the task is too big, or that you need sleep. The Stoic practice is to notice it and choose what to do with it, which sometimes means closing the laptop.

The short version#

When something breaks:

1. Separate what happened from the story about what it means.
2. Focus on the next controllable step, and make it small and testable.
3. Zoom out before you dig deeper.
4. Next time, imagine the failure before it happens.

Marcus Aurelius wrote that the impediment to action advances action; what stands in the way becomes the way. I doubt he imagined it being applied to a NaN loss. I think he’d approve anyway.

Here are the ideas that stuck the second time around.

Two systems, two kinds of model#

Kahneman’s central framing is that we run two modes of thought. System 1 is fast, automatic and associative: it reads faces, completes “bread and…” and flinches at loud noises. System 2 is slow, effortful and deliberate: it multiplies 17 × 24 and checks whether an argument actually holds.

The tempting engineering analogy is obvious — a single forward pass of a language model looks a lot like System 1, and chain-of-thought or tool use looks a bit like System 2. I don’t want to push the analogy too far; brains are not transformers. But it’s a useful lens on my behavior: most of my judgments about a model’s quality are System 1 judgments. I look at five outputs, they feel good, and a confident story assembles itself.

WYSIATI: What You See Is All There Is#

The most useful phrase in the book is Kahneman’s acronym WYSIATI. System 1 builds the most coherent story it can from the information in front of it, and it does not stop to ask what information is missing.

In ML work, WYSIATI is the cherry-picked demo. It’s the evaluation set that quietly shares a distribution with the training data. It’s the dashboard that shows accuracy but not the slice where the model fails for a specific group of users. The story feels complete precisely because you can’t see the gaps.

My practical defense is a habit I now apply before trusting any result: write down what data would make this conclusion wrong, then go look for it.

Substitution#

When faced with a hard question, System 1 quietly answers an easier one. “Is this model better for our users?” becomes “Do I like these outputs more?” “Will this project succeed?” becomes “Does the team seem excited?”

Substitution is why vibes-based evaluation is so seductive. The easy question has an immediate, satisfying answer. Recognizing substitution doesn’t make the hard question easier, but it does make me notice when I’ve stopped asking it.

The planning fallacy#

Kahneman describes a curriculum project where the team estimated two years and took eight. The fix he proposes is the outside view: instead of reasoning from the specifics of your plan, ask how long projects like this usually take.

Every engineer has lived this. “Fine-tune, evaluate, ship — two weeks.” The inside view lists the steps; the outside view remembers that data cleaning alone took three weeks last time. I now try to estimate twice — once from the plan, once from the reference class — and take the uglier number seriously.

Where the book has aged#

It would be dishonest not to mention that some studies cited in the book, especially in the chapter on priming, have not replicated well. Kahneman himself acknowledged this. For me this made the book more useful, not less: it’s a reminder that even careful experts fall for compelling stories with small samples. That’s precisely the trap the book warns about, which is a strange and humbling kind of recursion.

What changed in how I work#

A few small habits came out of this reread:

• Pre-register expectations. Before running an eval, I write down what result I expect. Surprises are only informative if you recorded what you expected.
• Look at failures first. Random samples of errors before any aggregate score.
• Slow down for irreversible decisions. System 1 is fine for choosing a variable name. It is not fine for deciding which model goes to production.

The book’s most lasting gift is not a list of biases to memorize — I forget most of them. It’s a persistent, slightly uncomfortable awareness that the feeling of being sure is not evidence of anything.

This blog is an attempt to fix that, and to hold myself to a slightly higher standard than “it made sense at 2am”.

Writing as debugging for thoughts#

When I explain a system to a colleague, I usually find the bug halfway through the sentence. Rubber-duck debugging works because speaking forces you to serialize a fuzzy mental model into a linear sequence of claims, and fuzzy models do not survive serialization.

Writing is the same trick with a longer attention span. If I can’t write a clear paragraph about why an agent loop keeps failing, I probably don’t understand why it keeps failing. The paragraph is the test.

So the first audience of this blog is me. If anyone else finds it useful, that’s a bonus I’ll gladly take.

What to expect#

I work as an AI engineer, mostly around large language models and agentic systems, so a good share of posts will be about that:

• Tech and AI — practical notes on building with LLMs: evaluation, agents, latency, the unglamorous plumbing that decides whether a demo survives contact with real users. Code where it helps.
• Books — I read outside my field on purpose. Expect reflections on books like Thinking, Fast and Slow or Meditations, read through the eyes of someone who spends the day staring at loss curves.
• Philosophy and psychology — how old ideas about attention, judgment and character turn out to be surprisingly useful when you are debugging a model or yourself.
• Life and other things — the occasional post that doesn’t fit anywhere else.

You can filter by any of these on the blog page, or subscribe via RSS if you still believe in RSS (I do).

What I won’t do#

I won’t write “Top 10 AI tools you need in 2026”. I won’t summarize papers I haven’t read carefully. And I’ll try to be explicit about confidence: when something is a hunch, I’ll call it a hunch; when it’s a result I’ve reproduced, I’ll say so.

I also won’t write about the internal details of the work I do for employers. The ideas here are my own, built from public knowledge, side projects and general experience — not anyone’s confidential roadmap.

A note on being wrong#

A blog is a public record of what you believed at a certain time. Some of what I write will age badly; the field moves fast enough that a confident post about best practices can look naive within a year. I’m fine with that. I would rather leave a trail of honest, dated thinking than a polished set of opinions that never risked anything.

If you spot a mistake, please tell me — the contact links are on the homepage. Being corrected is the cheapest education there is.

The setup, briefly#

For the curious: this site is plain HTML and CSS. Posts are Markdown files with a bit of front matter; a small Python script turns them into pages, an RSS feed and a sitemap. No framework, no build step on the server. I wanted publishing to be as low-friction as writing, because friction is where good intentions go to die.

Let’s see how long I keep this up. My goal is modest: one thoughtful post a month, written carefully enough that I would want to read it a year from now.