Notes
Everything I have written, each with a one-line takeaway. Filter by topic or search the full text.
12 posts
October 2026
Patterns for agent tool calls you can trust in production
Most of what makes an agent safe to run happens at the tool call, not in the prompt: who the call acts for, how risky it is, what happens when it is retried, and whether anyone can see it afterwards.
Good abstractions hide complexity, not evidence
An abstraction can reduce how much infrastructure a user needs to know without reducing the evidence they need to diagnose a problem.
An agent's identity is not its permission
Knowing who an agent is answers only part of the question. Whether an action is allowed depends on the user, the scope they delegated and the resource's own policy.
Measure the journey to the first production call
Platform metrics are more useful when they cover how quickly a new team gets started, not only how the platform performs once it's running.
Gateway errors that help someone fix the problem
A blocked request is more useful when the error says what happened, where, and what to try next, without exposing sensitive details.
What a shared platform should standardise
Shared platforms tend to work best when they standardise the capabilities every team would otherwise rebuild, and leave use-case decisions to the teams.
September 2026
First users shape the platform's design
A platform's first real users show where its abstractions help and where they get in the way, which makes their feedback part of the design work.
Who chooses the model: the application or the platform?
Pinning a model version gives reproducibility; letting a platform route by requirements eases upgrades. Model retirement schedules make the trade-off concrete.
When a tool call times out, did it happen?
A timed-out tool call may still have completed, so retrying safely needs the familiar distributed-systems tools: idempotency keys, durable state and verification.
A 200 OK doesn't mean the agent succeeded
Infrastructure can be healthy while an agent's task goes wrong, so agent observability leans on execution traces, not only logs and latency.
Checking both the user and the agent
Workload identity says which software is calling; authorizing an agent's action also needs to know which user it acts for and through which chain of agents.
Deciding what not to expose
Infrastructure was largely designed for people who read docs and debug by hand; building for agents and for non-infrastructure users both raise the question of what to hide.
