career bridge
Agents in anger
Give the pipeline hands, then go hunting for what breaks, because a wrong answer has just become a wrong action.
Your pipeline answers questions and you can prove that it does. Now somebody wants it to do things: look something up, act on it, report back. The first version will work in a demo and fail in ways a question-answering system never could, because a wrong answer has quietly become a wrong action.
What you do
Give the pipeline hands, then go looking for what breaks. Add two or three tools, a database query, an internal API call, a write of some kind, and let a model decide when to use them. Start with a plain loop before you reach for any framework, so the failure modes are yours to see, not somebody else's to hide. Then break it on purpose. Feed it an ambiguous request, and a question whose answer is genuinely not in the corpus. Time out a tool. Return an error string that looks like data. Ask it to do something it should refuse. Record what it does. Most of it will be bad in a specific, nameable way: it invents an argument, retries forever, treats the error text as a fact and reasons on top of it, or takes an irreversible action on a guess. Fix them one at a time with boring answers, because boring answers hold. Validate tool inputs. Cap retries. Make failures loud. Require explicit confirmation before anything that cannot be undone. Add tracing early, because print statements stop working around step four and you will not notice the moment they do. When the limits of your own loop are real to you, and only then, try LangGraph or the Claude Agent SDK and notice what they hand you.
Done when
- An agent with at least two real tools completes a multi-step task end to end.
- A written list of at least eight adversarial inputs exists, with what the agent did on each one.
- Every irreversible action sits behind an explicit guard, and you can point at the line of code.
- Traces are recorded, and you can reconstruct any failed run step by step after the fact.
- At least four recorded failures are fixed, and the fixes are re-tested against the same inputs.
What you end up with
A running agent plus a failure log: what you fed it, what it did, what you changed, and what it does now.
If you get stuck
The usual failure is a demo that only works on the happy path, because the happy path is the only input anyone ever tried. The way out is to write the nasty inputs down before you fix anything, so you end up with a list you can re-run rather than a memory you can misremember. The second failure is reaching for an agent framework in week one and then spending your time on the framework instead of the agent. Write the loop first. The framework makes far more sense afterwards.