Skip to content
Chad Brown
Chad Brown
  • Choosing a Multi-Agent Topology Is Choosing How It Fails

    Once a system holds more than one agent, the design question quietly shifts. It stops being about what any individual agent can do and becomes a question about the connective tissue between them: who hands work to whom, where authority sits, and what any single node can observe about the whole. Borrowed from distributed systems, the word for that arrangement is topology, and…

    Read More Choosing a Multi-Agent Topology Is Choosing How It FailsContinue

  • The Order in Your Pipeline Is Mostly Habit, Not Dependency

    A pipeline that runs its steps in a strict line is the default most systems settle into, and rarely because the work demanded a line. A line is simply the easiest thing to write: code that calls one function, then the next, then the next, reads back as a process and mirrors how anyone would narrate the task aloud, so steps keep…

    Read More The Order in Your Pipeline Is Mostly Habit, Not DependencyContinue

  • A Tool’s Error Response Is an Interface the Model Acts On

    When a tool succeeds, its return value is data. When a tool fails, its return value is an instruction. An autonomous system reads the failure and immediately decides what to do about it: try the same call again, change the arguments and retry, hand the problem back to a person, or abandon the path and take another. That decision is made by the model, in…

    Read More A Tool’s Error Response Is an Interface the Model Acts OnContinue

  • Autonomy Is Easy to Add and Hard to Take Back

    The two directions of travel are not symmetric, and that asymmetry should decide how you start. Grafting autonomy onto a working constrained system is the easy direction: you wait until a real input exposes where the fixed logic gives out, then hand that one decision to a model. Taking autonomy back out of a running system is the hard direction, because…

    Read More Autonomy Is Easy to Add and Hard to Take BackContinue

  • The Most Dangerous Agent Failure Is the One That Looks Like Success

    Most error handling in agentic systems is built for failures that announce themselves. An exception is thrown, a non-zero status comes back, a request times out, and the surrounding code reacts. That machinery is necessary, but it defends against the least dangerous class of failure. The failure that actually corrupts an agentic pipeline is the one that raises no signal at all: a…

    Read More The Most Dangerous Agent Failure Is the One That Looks Like SuccessContinue

  • Designing Extraction Schemas the Model Can Satisfy

    A schema attached to an extraction task looks like a description of the output you expect back. It is really a set of instructions the model reads while it generates, and it presses on what comes out. That reframing is the whole subject. A schema is not a passive record of the shape you hope to receive and inspect…

    Read More Designing Extraction Schemas the Model Can SatisfyContinue

  • A Constraint Is a Design Parameter, Not a Polite Request

    Most quality standards live in your head. You know the answer should be short, or written for a non-specialist, or structured so a downstream step can parse it, and you assume that because you know these things the model will honor them. It will not, because it cannot see them. A standard you hold silently has exactly zero effect on the output. It…

    Read More A Constraint Is a Design Parameter, Not a Polite RequestContinue

  • Every Token You Add to Context Costs Money, Latency, and Accuracy

    There is a comfortable assumption behind a lot of context handling: the window has a ceiling, so anything up to that ceiling is fair game. Retrieve a few extra passages in case they help. Keep the whole conversation because trimming is work. Carry a generous system prompt because instructions feel safer when there are more of them. The window fits it…

    Read More Every Token You Add to Context Costs Money, Latency, and AccuracyContinue

  • A Subagent’s Blast Radius Is a Design Decision

    Every time an agent delegates a task, it creates a second actor with its own context, its own tools, and its own capacity to do the wrong thing. How much of the system that second actor can see, touch, and break is its blast radius, and the mistake most people make is treating that radius as a side effect of the task…

    Read More A Subagent’s Blast Radius Is a Design DecisionContinue

  • Decomposition Comes in Three Shapes, and the Work Decides Which One Fits

    Once you have accepted that a complex goal has to be broken into pieces, a second question arrives that is easy to skip past: what shape does the broken-down work run in? There are only three answers that matter, and almost every agentic system is some arrangement of them. Work can be nested, so that a high-level intent is split into…

    Read More Decomposition Comes in Three Shapes, and the Work Decides Which One FitsContinue

Page navigation

Previous PagePrevious 1 … 3 4 5 6 7 Next PageNext
  • LinkedIn