Architecture on Ricky Moorhouse

API Versioning is a Contract Commitment, not a Technical Choice

Mon, 13 Apr 2026 00:00:00 +0000

Teams spend a lot of energy arguing about whether to put the version in the URL, a header, or a query parameter. That debate usually misses the point. The real question is: what is your change management discipline, and how do you protect consumers from breaking changes?

Taking a step up from the versioning question - how are you managing changes to your API contract? Ideally this would be transparent to consumers unless there is something they are looking to take advantage of in the new changes. If your API is designed well it can abstract any internal requirements and technical limitations from your clients such that you can update the implementation internally and their applications will continue to operate without even needing to know about it.

Observability as a design requirement

Sat, 28 Mar 2026 00:00:00 +0000

Observability is a design decision, not an afterthought. From the platform team to API consumers to AI agents, knowing what is happening across your API — and building that in from the start — is what gives you confidence when things go wrong in production.

Designing for Multi-Region API Deployments

Sat, 14 Mar 2026 00:00:00 +0000

A practical guide to designing multi-region API deployments - covering data consistency, auth dependencies, traffic routing, and failure modes, with real-world lessons from IBM API Connect SaaS.

The SRE Mindset in API Architecture

Sat, 07 Mar 2026 00:00:00 +0000

How my SRE experience with sizing, observability and SLOs shapes the way I approach API architecture - planning for reality, not hopes.

Building an AI Agent: From Inspiration to Implementation

Mon, 16 Feb 2026 00:00:00 +0000

I've been fascinated by the idea of AI agents for a while now - programs that can not just chat, but actually do things. A few weeks back I came across Clawdbot - now called OpenClaw and it clicked something in my brain. This had a great potential for proactive workflows with a regular trigger to identify things that needed doing and the ability to extend itself with additional code and updates to it's own configuration. Very powerful, but also very risky if not controlled. I set this up intially as it's own user account and then fairly soon moved it into an isolated VM.

I really liked the potential here but wasn't comfortable with the complexity of the code and the power I was giving it or would need to give it to do more interesting tasks - I've still not let it access calendar or e-mail for example. However if I could build something I could read all the code for and understand - with my own selection of controls and tools that are limited according to my own sense of risk level.

So rather than just using someone elses platform I embarked on building something smaller and more personal that I could tune to the things I wanted it to do. This became a great learning experience in understanding the basics at the core of what is needed in an Agent but also how this can get much more complex as you start to deal with things like memory and control.