Building and Deploying AI Agents

Here's my unscripted collection of things I've learned building agentic frameworks and working on agent R&D — working with models from OpenAI, Anthropic, and Google, and designing multi-agent systems for clients in insurance.

Context is the real lever

The senior engineer I report to told me this early on, when I was hitting a wall with an agent that wouldn't give me accurate outputs for specific extraction tasks: agentic performance is less about the model and more about the context you provide it.

It sounds almost too simple. But it took a few frustrating debugging sessions to fully internalize it. When an agent misbehaves, the reflex is to try a smarter model. Almost always, that's the wrong move. The model is doing exactly what it's designed to do — predicting good next tokens given what's in its window. If the window is ambiguous or contradictory, a smarter model fails in a more sophisticated way.

Orchestration patterns

When you move from a single agent to a multi-agent system, coordination becomes the primary engineering challenge. A few patterns I've found reliable in R&D and testing:

Supervisor + workers. A router/supervisor agent takes the high-level task, breaks it into sub-tasks, delegates to specialist workers, and assembles the result. The supervisor holds the global state; workers are stateless and focused. This scales reasonably well and is easier to debug than fully peer-to-peer architectures.

Tool use as the primitive. Rather than agents calling other agents directly, model every capability as a tool call. This forces clean interfaces and makes the system observable — tool calls are logged, typed, and auditable. Direct agent-to-agent calls tend to produce tangled, hard-to-inspect chains.

Explicit state passing. In multi-turn setups, state that lives "between" agents tends to evaporate. Never rely on implicit shared state. Pass state explicitly as structured objects and validate it at each handoff. A lot of mysterious agent failures are really state-loss failures in disguise.

Testing agents

Unit testing doesn't translate well to agents. The output space is too large and too stochastic for conventional assertions. What actually works for me: regression testing against curated past outputs.

Concretely — I maintain a set of outputs I've manually verified as correct. For my extraction work, that means things like symbols correctly identified in a legend or blueprint. When I modify functionality, I run the agent against those known-good cases and check for drift. It's not exhaustive, but it catches regressions reliably and keeps the feedback loop tight.

When something breaks, my go-to debugging move is to have the agent add logging to the specific pipeline steps I want to inspect, then run a live test and check the logs. On-demand instrumentation rather than logging everything upfront — it keeps the signal high.

A cautionary tale: building on OpenClaw

OpenClaw is an open-source personal AI assistant framework — a batteries-included foundation for building your own agents. Over a weekend I used it to try to build a LinkedIn monitoring agent: watching job openings, learning my background and preferences, and surfacing tailored suggestions.

I spent way too many hours that weekend trying to get a headless browser working with the framework. Eventually I pivoted — built a Telegram bot running on Claude Opus instead. That got further, but not far enough. LinkedIn's bot detection is aggressive, and the agent kept hitting walls.

The lesson isn't just "check the ToS before building." It's that the most interesting agentic applications operate at the boundary of what platforms allow — and platform risk is a real constraint on agent design that doesn't show up in the happy path. If the agent's core capability depends on automating against a platform's intended use, that's a fragile foundation regardless of how solid the framework underneath it is.

---

The infrastructure for reliable agents is still being built in real time. The teams shipping production systems today are making foundational decisions that will look obvious in retrospect and are genuinely hard right now. I'm still mostly in the R&D phase myself — but that's where a lot of the interesting problems live.