I write about AI agents, evaluation, and the engineering behind them — what I actually learned from my own projects. Most of it started as a way to think through a problem and look for a solution, and from there it usually turns into a full piece on Medium, with a shorter take on LinkedIn.
What building a two-agent project taught me about handoffs, hidden contracts, and evaluating a system instead of a component.
A better prompt can fix an ambiguous instruction. It can't fix missing context, an unvalidated tool interface, or a role carrying too much responsibility.
The failures that matter in multi-agent systems aren’t crashes — they’re the handoffs, the shared state, and the moments one agent quietly contradicts another.
Prompting is what you say once. Context engineering is deciding what the model should know every time — and it’s the higher-leverage skill.
The case for several small deterministic agents over one large generalist — and the point at which splitting stops helping.
Accuracy is an average. It tells you almost nothing about the tail, which is where agent behaviour actually goes wrong.
Rarely the model. Usually the data underneath it, the assumptions around it, and the review process that couldn’t keep up.
When a curated tool set helps, when it constrains, and when an agent is better off writing the thing it needs.
Session, procedural, and episodic memory are different problems. Treating them as one is the mistake I made first.
Three thousand engineers, seventeen sessions, and the ideas that were worth carrying home — written from the room.
Every session, written up in detail — plus the architecture my team built off the back of it: unified data, agent memory, and evaluation.
Publishing consistently is a workflow problem more than a writing problem.
I pick the topic and write about my own experiments myself — the agent’s job is everything around that: researching supporting material, fact-checking, and proofreading each draft before it goes out.