<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
	<channel>
		<title>2026 on Ricky Moorhouse</title>
		<link>https://rickymoorhouse.uk/blog/2026/</link>
		<description>Recent content in 2026 on Ricky Moorhouse</description>
		<generator>Hugo</generator>
		<language>en-gb</language>
		
		
		
		
			<lastBuildDate>Mon, 06 Jul 2026 17:06:00 +0000</lastBuildDate>
		
			<atom:link href="https://rickymoorhouse.uk/blog/2026/index.xml" rel="self" type="application/rss+xml" />
			<item>
				<title>Why Human Thinking Still Matters</title>
				<link>https://rickymoorhouse.uk/blog/2026/why-human-thinking-still-matters/</link>
				<pubDate>Mon, 06 Jul 2026 17:06:00 +0000</pubDate>
				<guid>https://rickymoorhouse.uk/blog/2026/why-human-thinking-still-matters/</guid>
				<description>We&#39;re building tools to save time, yet we often find ourselves with less time to think about why we&#39;re building them. A reflection on reclaiming the &amp;quot;messy&amp;quot; human part of the development process in the age of AI.</description>
			</item>
			<item>
				<title>Machine-readable?</title>
				<link>https://rickymoorhouse.uk/blog/2026/machine-readability/</link>
				<pubDate>Sun, 28 Jun 2026 10:31:11 +0000</pubDate>
				<guid>https://rickymoorhouse.uk/blog/2026/machine-readability/</guid>
				<description>Applying metadata standards and formats to improve the readability of my blog for machines of different types.</description>
			</item>
			<item>
				<title>MCP Ponderings</title>
				<link>https://rickymoorhouse.uk/blog/2026/mcp-ponderings/</link>
				<pubDate>Sun, 21 Jun 2026 00:00:00 +0000</pubDate>
				<guid>https://rickymoorhouse.uk/blog/2026/mcp-ponderings/</guid>
				<description>Some of my thoughts around MCP and how we can use it safely.</description>
			</item>
			<item>
				<title>Securing Sensitive Payload Logging in API Connect</title>
				<link>https://rickymoorhouse.uk/blog/2026/securing-sensitive-payload-logging-in-api-connect/</link>
				<pubDate>Fri, 22 May 2026 00:00:00 +0000</pubDate>
				<guid>https://rickymoorhouse.uk/blog/2026/securing-sensitive-payload-logging-in-api-connect/</guid>
				<description>Overview of ways to handle sensitive data payloads within API Connect and controlling where that data ends up.</description>
			</item>
			<item>
				<title>Cheriton Circular</title>
				<link>https://rickymoorhouse.uk/blog/2026/cheriton-circular/</link>
				<pubDate>Mon, 04 May 2026 00:00:00 +0000</pubDate>
				<guid>https://rickymoorhouse.uk/blog/2026/cheriton-circular/</guid>
				<description>Short circular walk around Cheriton with beautiful views around the area.</description>
			</item>
			<item>
				<title>API Versioning is a Contract Commitment, not a Technical Choice</title>
				<link>https://rickymoorhouse.uk/blog/2026/api-versioning-is-a-contract-commitment-not-a-technical-choice/</link>
				<pubDate>Mon, 13 Apr 2026 00:00:00 +0000</pubDate>
				<guid>https://rickymoorhouse.uk/blog/2026/api-versioning-is-a-contract-commitment-not-a-technical-choice/</guid>
				<description>&lt;p&gt;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?&lt;/p&gt;&#xA;&lt;p&gt;&lt;img src=&#34;https://rickymoorhouse.uk/blog/2026/api-versioning-is-a-contract-commitment-not-a-technical-choice/windswept.jpeg&#34; alt=&#34;Sand in the wind, Witterings&#34;&gt;&lt;/p&gt;&#xA;&lt;p&gt;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.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Observability as a design requirement</title>
				<link>https://rickymoorhouse.uk/blog/2026/observability-as-a-design-requirement/</link>
				<pubDate>Sat, 28 Mar 2026 00:00:00 +0000</pubDate>
				<guid>https://rickymoorhouse.uk/blog/2026/observability-as-a-design-requirement/</guid>
				<description>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.</description>
			</item>
			<item>
				<title>Designing for Multi-Region API Deployments</title>
				<link>https://rickymoorhouse.uk/blog/2026/designing-for-multi-region-api-deployments/</link>
				<pubDate>Sat, 14 Mar 2026 00:00:00 +0000</pubDate>
				<guid>https://rickymoorhouse.uk/blog/2026/designing-for-multi-region-api-deployments/</guid>
				<description>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.</description>
			</item>
			<item>
				<title>The SRE Mindset in API Architecture</title>
				<link>https://rickymoorhouse.uk/blog/2026/the-sre-mindset-in-api-architecture/</link>
				<pubDate>Sat, 07 Mar 2026 00:00:00 +0000</pubDate>
				<guid>https://rickymoorhouse.uk/blog/2026/the-sre-mindset-in-api-architecture/</guid>
				<description>How my SRE experience with sizing, observability and SLOs shapes the way I approach API architecture - planning for reality, not hopes.</description>
			</item>
			<item>
				<title>Building an AI Agent: From Inspiration to Implementation</title>
				<link>https://rickymoorhouse.uk/blog/2026/building-an-ai-agent-from-inspiration-to-implementation/</link>
				<pubDate>Mon, 16 Feb 2026 00:00:00 +0000</pubDate>
				<guid>https://rickymoorhouse.uk/blog/2026/building-an-ai-agent-from-inspiration-to-implementation/</guid>
				<description>&lt;p&gt;I&#39;ve been fascinated by the idea of AI agents for a while now - programs that can not just chat, but actually &lt;em&gt;do&lt;/em&gt; things. A few weeks back I came across Clawdbot - now called &lt;a href=&#34;https://openclaw.ai&#34;&gt;OpenClaw&lt;/a&gt; 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&#39;s own configuration.  Very powerful, but also very risky if not controlled. I set this up intially as it&#39;s own user account and then fairly soon moved it into an isolated VM.&lt;/p&gt;&#xA;&lt;p&gt;I really liked the potential here but wasn&#39;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&#39;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.&lt;/p&gt;&#xA;&lt;p&gt;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.&lt;/p&gt;</description>
			</item>
	</channel>
</rss>
