# Rafe Blandford — full text

> Product, technology and AI — systems thinking, out loud.

Every post below is labelled by authorship (human / with AI / AI-authored) on the site; see /ai-provenance/.

---

# An e-ink screen on the wall with TRMNL X
_https://rafeblandford.com/e-ink-screen-on-the-wall-trmnl-x/ · 2026-07-27_

The panel

There's a new screen in my flat, which is an odd thing to be pleased about, especially when I'm sort of trying to spend less time looking at screens.

It's a TRMNL X: a 10.3-inch e-ink panel, 1872 × 1404, sixteen levels of grey, sitting on a magnetic USB-C dock with a touch bar along the bottom of the frame. A full refresh takes around a second. The big plus point is it's battery powered (up to 90 days), meaning it can be mounted almost anywhere. All of this makes it ideal for a passive, glanceable screen for RafeOS.

If you've arrived here as a TRMNL owner and don't know RafeOS: it's an agentic-first layer to help run my life, including an API that wraps health, calendar, email, messaging, home, transport and weather in verbs any client can call (longer introduction here), enriched by AI-powered triage, cross-referencing, and judgement. It already has a progressive web app dashboard, but a dashboard is a place you go. The panel is simply there. Always on, nothing to open, glanced at as I bumble around my flat. If done well, it should mean the phone stays in the pocket.

So what goes on it?

Currently, five screens: the daily briefing, health, home, weather, and, as a bonus, a self-indulgent "measure" screen (currently showing traffic to my web sites). The rule that shaped all of them has three parts, all of it driven by the constraints of the device and the wish to prioritise glanceability.

 1. Anything I'd act on somewhere else collapses to a count. "4 priority emails to reply" is the useful minimal signal.
 2. Purely informational things keep more of their detail, because reading them is the whole action. A note that readiness is holding while sleep drifts is complete in itself, as is an alert about transport delays. Nothing follows except knowing it and making a better decision.
 3. Exceptions are prioritised, but carry minimal explanation. "3 windows open" at dusk needs no sentence about why it matters. Presence and awareness are the message.

Every surface has an action budget

RafeOS is very deliberately multi-surface. Probably the biggest lesson from this mini-project is that every surface has an action budget: how easily you can do something about what it just told you. A phone's is high, so queues and buttons belong there. A watch gets counts and alerts. A panel on a wall has almost no budget at all, so it should describe the state of things and trust you to go and act somewhere.

At first, I also had the space instinct backwards. E-ink feels precious, so I treated the screen as something to fill. Exactly wrong, less is definitely more, even on a 10-inch display. The panel works if a glance is sufficient, and a glance is only sufficient when there's little enough to take in as you walk past it.

Using e-ink definitely stretched my product thinking and design skills, mainly because the context and the constraints were unfamiliar. I rather enjoyed the exercise of simplification, and of creating around the feature-set of an e-ink display (size, greyscale, refresh rate, viewing distance). My self-discipline wasn't very good here; I suspect I'll be removing stuff, rather than adding it as time goes by.

Worth seeing more than once

Five screens on a fifteen-minute rotation means each one comes round roughly every 75 minutes. In practice I might glance at the panel a dozen times a day, but I'd only catch any given screen once or twice unless I went looking for it. That changes the question. "Would I want this when it happens to be up?" is a different test from "is this interesting?", and it did kill off a couple of ideas I had.

Thankfully, TRMNL's platform has some clever features, including playlists that take per-plugin time windows, which means you can prioritise certain screens at certain times of the day. The screen also has a touch bar that steps through screens with one tap on the frame, which is genuinely convenient (along with the accompanying platform, it's one of the reasons I chose the TRMNL X). The screens stay passive; you just get a little say in which passive thing you're looking at.

It's going to be interesting to see if the TRMNL X earns its wall space. I think this will be about whether key information gets absorbed in passing and I'm rather hoping it will mean less time looking at screens, courtesy of a screen.

How the five screens got built (quickly, and with Claude Code doing the heavy lifting) is the next post.

---

# Developer experience with TRMNL
_https://rafeblandford.com/developer-experience-trmnl/ · 2026-07-27_

Five screens, one day

There's a TRMNL X e-ink panel on my wall now, showing five screens from RafeOS, the system I am experimenting with to run my life (and better understand AI). What belongs on an e-ink panel is an earlier post, this one is more some notes from the story of the build.

I was able to go, in a single day, from never having used TRMNL's platform to having a device on the wall showing five custom screens. The speed came from three things meeting: using the APIs (verbs) RafeOS already had, a platform (including a framework, design system, and documentation) that TRMNL has deliberately made legible to machines and agents, and Claude Code as the harness joining them and doing the execution. I don't think any one of the three gets there alone.

Nothing new underneath

The RafeOS layer didn't change. All the information on all five screens came from APIs that already existed. The briefing screen alone reaches into a dozen or so sources (Oura, Withings, Apple Health, Google Calendar, Gmail, WhatsApp, Tasks, Home Assistant, Octopus Agile pricing, TfL, Open-Meteo), so this clearly saved a lot of time (and was a satisfying validation of a composable approach to my personal ecosystem).

What did get written: renderers, templates, shared transport code, push endpoints, a CLI verb for TRMNL, tests, and a preview harness. Presentation, end to end. Delivery of data from RafeOS into TRMNL's platform is intentionally push (webhook approach) rather than poll because the RafeOS API isn't reachable from the public internet and I wasn't going to change that for an e-ink screen.

The preview harness really earned its place, repeating a lesson I've had elsewhere in agentic development. Each screen can be rendered locally in headless Chrome against a real payload, so reviewing a change, whether by agent or human, took seconds rather than a device refresh. Being able to see the thing without touching the wall is one of the reasons the loop was fast, and a key for fast validation (TRMNL does have their own system for this too, but Claude opted to use tools it already had access to).

What Claude got wrong, and what it kept

Claude made mistakes along the way and the interesting thing about them is their shape. Mostly plausible rather than random: an icon drawn from memory that came out almost right, template constructs that looked idiomatic and silently did nothing. A human wouldn't make most of these errors, but would make different ones (lots, if you're me). What stood out for me is that the loop caught the machine-shaped mistakes the same way it caught mine, and iterated through them. This working method has its own post; for me this build just added evidence.

Another observation: as we went along, Claude Code created its own notes, including the ubiquitous CLAUDE.md file. Some of the workflows were saved into a skill, and the lessons into memory. The last screen took maybe a third of the time of the first, and I'm confident it will be even easier to create more screens or edit what's already there. Like the models, the harnesses are improving rapidly, a notable step up from earlier this year.

Documentation and tools written for machines

TRMNL's documentation serves a Markdown version of every page, with an index at the root. Claude fetched the index, pulled the pages that mattered, and had a working model of the platform in about twenty minutes. I've onboarded onto a lot of platforms. Twenty minutes is not a human number. A person coming to a new system skims and guesses, and reads a fraction of the documentation; the agent read the whole relevant tree and held it. Scary fast and scary good, even allowing for failure modes a human wouldn't have.

TRMNL also provide an MCP server for agents to create, edit and interact with plugins (which are what render the screens). This included a linter that validated markup and explained any mistakes, a canonical example fetchable as a tool call, and a render log that was helpful for troubleshooting.

The lesson? Agent-friendly documentation orients you; agent-accessible feedback is what makes it quick. I've argued that the web is splitting into one for people and one for machines. TRMNL has also given a great deal of attention to the human side too (and the hybrid version). This build is what it looks like when a company has built both, and it definitely caught my attention.

So a shoutout to TRMNL. They've opened the platform up about as far as they could and made things very agent friendly (I also like their approach to self-hosted BYOS and BYOD). I'm not surprised that AI is changing the expectations and requirements of developer experience (DX), but it was still startling to see it in action.

Which is the part I'd take into any other product, internal or external. If your documentation, your examples and your error messages are all things an agent can reach, you get built on. If they aren't, you are going to be behind.

---

# Modernising the archive: what the search data says
_https://rafeblandford.com/modernising-the-archive-search-data/ · 2026-07-24_

In late March I migrated three mobile technology sites — All About Symbian, All About Windows Phone, and All About Mobile, 24,000 articles across roughly 145,000 pages — from a dying legacy server and LAMP code base to a modern static archive. I've written about how the migration was done, the optimisation passes that followed, and adding structured data at scale. This post is about what happened next: whether any of that work shows up in Google's treatment of the sites.

What changed, in SERP-signal terms

Preservation was the goal, but the side effect was a full modernisation of everything Google's documentation says it cares about:

 * Static delivery. Dynamic CMS pages on ageing PHP became pre-rendered HTML behind a CDN. Time-to-first-byte and reliability improved overnight, and there is no longer an application layer to fall over mid-crawl.
 * Core Web Vitals and Lighthouse. The first optimisation pass took a representative page from Performance 71 / Accessibility 66 / Best Practices 73 / SEO 83 to 93 / 91 / 96 / 100. Subsequent passes pushed further: today the All About Symbian homepage audits at 96 / 100 / 100 / 100 on mobile emulation.
 * Structured data at scale. From basic Article microdata to comprehensive JSON-LD across six content types — 4,504 review pages with proper Review schema, 81,117 forum threads with DiscussionForumPosting and comment markup, breadcrumbs on 23,000 pages.
 * Crawl hygiene. Sitemaps resubmitted, thousands of 404s and deprecated-schema warnings worked through as Search Console flagged them.

None of this changed a word of content. The archive is frozen — no new posts, no updates, no promotion. Which makes it an unusually clean setting for the question: does technical quality alone move search performance?

What Google did

Search Console was set up the day after cutover, so the data starts with the modernised archive's first day — sixteen weeks of it now.

Three things stand out in the All About Symbian data:

 1. Clicks ratcheted up and held. From 1,114 in the first full week to a sustained ~1,430 average over the last six weeks — up 29%, with no new content to explain it.
 2. Click-through rate rose from 1.06% to 1.26%. When the pages appear in results, more people choose them. That's consistent with what richer snippets and faster pages are supposed to do — the listing itself got better, not just more frequent.
 3. The impressions curve tells a re-evaluation story. Google spiked impressions to a peak in early May — around 177,000 in a week, plausibly re-testing the re-crawled pages across many queries — then settled roughly a third lower. Clicks held through that settling. Google showed the archive less, but better.

Same treatment, three outcomes

The section above tells a simple, positive story, but here's the slightly messier reality. All three sites got identical treatment. They did not get identical results.

All About Mobile — the smallest site — grew the most, roughly 1.7× on both clicks and impressions, but I would take that with pinch of salt, given the low volume. All About Symbian gained steadily. All About Windows Phone drifted down 12%, though is now showing upward signs. Same schema scripts, same performance work, same infrastructure. The difference is presumably demand and competitive context per topic: technical quality changes how Google evaluates your pages, not how many people care about Windows Phone in 2026.

Why this matters

For a frozen archive, technical quality is the only lever there is — no new content, no outreach, nothing else to pull. What the data shows is that Google demonstrably re-evaluates: a site that will never publish again can still improve in search, because the ranking systems keep re-reading the signals you send. Twenty years of accumulated authority is an asset, but it pays out through a technical surface that either helps or hinders.

For living sites the implication is sharper. These signals — speed, structured data, crawl hygiene — are the floor under everything else you do. And the cost of getting them right has collapsed: this entire modernisation, 145,000 pages, was days of agentic work rather than a quarter of engineering. The excuse for a slow, schema-less, error-ridden site is gone.

The other quiet enabler is the measurement itself. The charts above come from programmatic Search Console access feeding a weekly analytics digest — the same instrumentation that flagged the trends in the first place. Modernise the site, but modernise the measurement with it.

---

# High standards and high humanity
_https://rafeblandford.com/high-standards-and-high-humanity/ · 2026-07-22_

On my last day at Digitas, I tried to compress twelve years into a single line for my team: high standards, high humanity — ambitious for the work, and generous with each other. I'd never actually used the phrase before that day, although it consciously echoes Simon Gill's "hard on the work, kind to the people" mantra, which had long been something of a north star. It took leaving to find my own version of the words for what I'd been trying to build all along.

It's the closest thing I have to a leadership belief. I spent a decade building and leading a product and technology capability of 200+ people across the UK, India and Europe, and the pattern held consistently: the teams that did the best work were the ones where the bar was high and the people setting it visibly cared about the humans clearing it. Not one or the other. Both, at the same time, all the time.

The reason this is worth writing down is that most organisations don't behave as though they believe it. They'd never say so... every values deck has a slide about excellence and a slide about people... but watch how they actually behave under pressure and you'll see the two treated as a dial. Turn it towards the work and you get "high-performance culture" (too often a euphemism for burning people). Turn it towards the people and you get "supportive culture" (sometimes a euphemism for not having hard conversations). Too frequently, there is a quiet assumption that standards and humanity trade off against each other, and leadership is about picking your position on the dial.

I think that's wrong. Moreover, it's the assumption that produces much of the mediocre work and many of the miserable teams I've encountered.

What each looks like on its own

Standards without humanity is the easier failure to spot, because it's loud. You've seen it: the team that ships impressive work while quietly haemorrhaging its best people. The deadline culture where late nights are a badge rather than a warning light.

Early in my time leading a large team on Formula 1, I wrote an email to senior leadership that I can still more or less quote: "we appear to be promising things and pursuing timelines that are not sustainable, and I need to consider morale, wellbeing, and retention" and then articulated steps that would be necessary "if we are to successfully complete this programme". I was fortunate to be heard and given the autonomy to act. It came down to plain pragmatism: resetting expectations on scope and people; explaining why the deadlines needed to move back; and making an intentional, sustained effort to value the team under heavy pressure. It was a formative experience for my leadership style, although I still regret not acting earlier because some great people had already been used up. However, the lessons stayed with me for years and I think the trust and safety earned in that time compounded invisibly for years afterwards.

High standards without humanity always looks like winning right up until the moment the people who made the winning possible stop believing you'll look after them. Then you get fear, defensiveness, quiet attrition and eventually the standards go too, because frightened people don't tell you the truth about the work.

Humanity without standards is quieter and, I'd argue, more insidious, because it feels virtuous while it's happening. For me, it's the difference between being nice and being kind. When everyone is nice, nobody gets the hard feedback, low-value projects or initiatives are allowed to persist, nobody is clearly accountable for outcomes or missed opportunities. The result is comfortable mediocrity and it's a decision to fail more slowly. Kindness means being clear about what is needed, having difficult conversations early and considering the consequences for the whole team, not simply avoiding discomfort for one person.

So the trade-off framing fails in both directions. Which raises the more interesting question: what happens when you refuse it?

How they compound

Held together consistently, the two reinforce each other in ways that are hard to see from inside either failure mode.

High standards give people work worth committing to. Capable people generally don't want work emptied of challenge. They want to do work they're proud of, alongside people who help them improve. A genuinely high bar is a form of respect: it says I believe you're capable of this.

High humanity gives people the safety to actually clear that bar. Hard problems require people to say "I don't know", "I got this wrong", "this estimate is fiction" and they'll only say those things out loud if they trust that honesty won't be punished. Psychological safety isn't the opposite of high standards. It's the operating condition for them.

Two examples from my own experience, one fast and one slow.

The fast one: when the previous supplier pulled out, we designed and built the Glastonbury Festival app from scratch — live in seven weeks, three weeks before the gates opened. The deadline was as immovable as deadlines get; the festival happens whether your app is ready or not, with a couple of hundred thousand attendees expecting to rely on it. The conventional response to that kind of pressure is a big team, long hours and a command-and-control delivery structure. We did roughly the opposite: a small, empowered product trio – product, design, and engineering — with clear outcomes, genuine authority to make decisions without escalating, and leadership whose main job was absorbing pressure rather than transmitting it. In all honesty, there were some long hours, but it was a choice made by a team, and we supported each other (including not cancelling holidays during the period). I don't think either half of that was optional: the standards made the scope decisions honest; the humanity kept an exceptional period of intensity bounded, supported and voluntary rather than allowing it to become the operating model.

The slow one: our Honda partnership ran for more than a decade: through platform consolidations, commercial negotiations, the introduction of e-commerce, car-and-bike launch deadlines and the occasional genuinely bad week. Client relationships don't survive that long on standards alone (plenty of technically excellent agencies get rotated out) or on relationship warmth alone (plenty of well-liked agencies get rotated out too). What compounds over a decade is the combination: work that keeps earning its place, delivered by a team stable and trusted enough to hold years of context. And team stability is a humanity outcome. People stayed on that account for years, during a period when moving jobs every couple of years was the default, because the work was worth doing and the environment was worth doing it in. Both the business and the client earned compound interest from the combination.

The hard bits

The reason the combination is rare is that it's hard to hold both simultaneously and the rewards emerge over a longer horizon than many companies allow for.

Hard feedback is the everyday case. Telling someone their work isn't meeting the standard, kindly, is a skill most leaders never properly develop, because two common failure modes are more comfortable: soften it until the message disappears, or deliver it bluntly and call it honesty. The version that works — direct on the work, generous about the person, and collaborative about the path forward — takes real effort every single time. It should also be tuned to each individual wherever possible (adapt the delivery, not the standard) because there is no one strategy or playbook that works with everyone.

Positive feedback is equally underused – not praise for its own sake, but specific reinforcement of the behaviours that lift the wider team. Turning high-performing individuals into catalysts and stewards for the wider team and system takes deliberate coaching and a lot of trust. It is too often underdeveloped, partly because it requires trust that such behaviour will be rewarded, rather than exploited; and partly because it carries a risk of temporarily reducing their individual output. Nurturing that instinct has paid some of the greatest dividends of my career: an individual contributor who went on to become an outstanding leader, loved by the team and the client; a Tech Director who cross-mentored a Designer in accessibility and championing their success; a brilliant product person who applied their skills to team ownership and being an advocate for product thinking beyond their own discipline.

Redundancies are an interesting case. I've had to make roles redundant, and I've been made redundant myself as part of a leadership restructure and a change in priorities. I won't pretend either side of that conversation can be made painless. But there is an enormous difference between a hard decision executed with genuine care — honestly explained, properly supported, the person's dignity intact — and the same decision executed as an administrative or cost process. The decision tests your standards; the execution tests your humanity. People watch both the decision itself and how you handle it, and what they learn shapes how safe your organisation feels for years afterwards.

And saying no – to a timeline that requires burning the team, to a commercial opportunity that risks compromising standards – is where the belief gets expensive. It's easy to hold "high standards and high humanity" when they're free. The test is whether you'll pay for them when they're not.

There's also a responsibility in how you embody the belief as a leader. I see a parallel with what Jim Collins, in "Good to Great", calls "Level 5 Leadership": the "paradoxical combination of personal humility and professional will". Professional will supplies the resolve to protect the standard; personal humility stops that resolve becoming about the leader’s ego. It isn’t exactly the same formulation, but it expresses the same productive tension. The practical test is whether people experience both: a leader who will look after them and who will not pretend mediocre work is good enough.

Why this matters more now

I’m wary of every post in 2026 becoming AI-linked, but we cannot ignore what AI is changing. It is making the production of plausible output dramatically cheaper. Ideas, first-pass strategies, designs, solution options and code iterations can all be generated faster and in far greater volume. That is not the whole of execution – integrating, adopting and operating what gets produced remain difficult – but it changes where the constraint lies.

AI makes output abundant, not automatically good. That increases the value of judgement: knowing what good looks like, understanding which problems are worth solving, and caring enough to insist on a better answer. The human system that sustains that judgement is made up of people who trust each other enough to say “this isn’t good enough yet” and hear it as help rather than attack.

It also creates uncertainty for people whose work, skills and roles are changing. Humanity without standards risks reassuring people while leaving them unprepared. Standards without humanity turns transformation into something done to people, with little honesty about the consequences. Leaders need to give people room to learn, speak candidly about what is changing and still raise the bar for what the team can achieve.

The trade-off was always false; AI is about to make it more obviously so. Teams that learn to hold both will compound. Teams that pick one will produce more mediocre output, faster than has ever been possible – and probably won’t even realise they are doing it.

High standards, high humanity. Ambitious for the work, generous with each other. It was the last thing I said to my team, and I meant it as a beginning rather than an ending.

---

# Loops within loops
_https://rafeblandford.com/loops-within-loops/ · 2026-07-15_

The phases were always a fiction

Ask anyone who builds products whether the work is linear and they'll say no, obviously not. Discovery never really stops. Prototypes expose the problem you misunderstood. Delivery teaches you things that send you back to the drawing board. Growth feeds new audiences and new use cases back into the product.

Every serious framework of the last thirty years says the same: the double diamond loops back, continuous discovery loops, plan–do–study–act loops for continuous improvement, build–measure–learn is the lean startup loop, scrum loops every sprint, CI/CD loops every commit, growth compounds through loops. The textbooks are full of circles.

Strip the labels off and every one of those frameworks is the same shape: sense where you are, work out what to do, do it, look at what happened, go again.

And yet we keep drawing plans (and even roadmaps) as sequences of boxes. We run "discovery, then delivery". We plan in quarters and ship in phases. The loops live in the theory; the phases live in the calendar.

There’s a reason for that, and it isn’t stupidity. Loops are harder to articulate and look more expensive to run. Phases are legible: they have a start, an owner, a date and a deliverable. They fit on a Gantt chart and into a budget. Loops done well are messier. They have a cadence rather than an end. They ask you to keep paying attention. They require a different team mindset.

A common failure is that rationed loops collapse back into phases. You do discovery once, up front, because you can’t afford to keep doing it. You test once, near the end, because that is when there is something to test. You optimise after launch, if there is still budget. The loop survives as language, but too often the operating model is still linear.

This was always an uncomfortable compromise. We knew product work should loop, but loops were expensive to run and hard to govern. AI changes that equation.

The unit of work was always the loop

A recurring pain for product delivery teams has been getting organisations to stop treating discovery, design, delivery and growth as stages you pass through, and start treating them as parts of one continuous product loop. That is how you get to better outcomes: not by making the phase boundaries cleaner, but by tightening the feedback between what you observe, what you decide, what you make and what you learn.

I have lived this inside a full-service digital marketing agency, where lean was sometimes something you did against a wall when there were too many people in a meeting; where linear process inherited from campaigns was always close to hand; and where risk-aversion could easily become decision paralysis. I certainly wasn’t perfect. I was lucky to be educated by brilliant colleagues and by the lived experience of many different transformation and product delivery cycles. The point is simply that you can always do better.

The useful shift is to stop asking, "Which phase are we in?" and start asking, "Which loop are we trying to improve?"

There is the big product loop: observe, plan, act, reflect and learn. But inside it are many smaller loops. A research loop. A prototype loop. A prioritisation loop. A design loop. An architecture loop. A test loop. A deployment loop. A growth loop. Some turn daily, some weekly, some quarterly. Some are mostly human, because they depend on judgement, taste, relationships or accountability. Some are increasingly machine-shaped, because they involve repeatable analysis, generation, testing, monitoring or optimisation. Most are becoming a blend.

That is where AI starts to matter. Not because it magically replaces the product process, but because it changes the cost, speed and shape of the loops inside it.

Reading the model

The diagram is not meant to be a new methodology. It is a way of making visible what already happens when product work is done well.

At the outer level there is one continuous product loop. I use observe, plan, act and learn because they echo the family of feedback-loop models that run through control theory, OODA, plan–do–study–act and, more recently, agentic loops: sense the world, decide what to do, do it, and learn from what happened. 

The words are deliberately more generic than discovery, design, delivery and growth – or discovery, alpha, beta, live. They preserve the reality that different kinds of work happen at different moments, without pretending those moments are always clean phase gates. You observe the world, customers, systems, markets and constraints. You plan what to do next. You act by making, testing, shipping or changing something. Then you reflect on what happened and feed that learning back in.

Inside that outer loop are many smaller loops that have the same basic shape. Research loops, prototype loops, design loops, architecture loops, test loops, deployment loops, optimisation loops, growth loops. They are related, but they do not run in lockstep. Some turn in hours, some in days, some in weeks or quarters. Some depend on other loops. Some should be deliberately slowed down because the stakes are high. Others should be made as fast and cheap as possible.

The second thing the model tries to show is that every loop now has a different human-machine mix. Some loops are still mostly human, because they depend on judgement, taste, trust, relationships, ethics or accountability. Some are increasingly machine-shaped, because they involve repeatable generation, analysis, testing, monitoring or optimisation. Most sit somewhere in the middle.

That is the bridge to AI. The interesting question is no longer simply, “Can AI help with this task?” It is, “Which loops can AI compress, which loops can AI keep alive, and where do human attention, judgement and accountability need to move when more of the loop becomes machine-run?”

What AI actually changes

Two things, and, in my judgement, they aren't equally important.

The first is the one everyone talks about: AI compresses loops, especially when agents let work that used to run in sequence run in parallel. You can go from a problem to a working prototype in an afternoon; discovery and delivery start to blur. I have mixed feelings about this. Compression is real and often wonderful, but it's also the easiest thing in the world to mistake for progress. A loop you got round quickly is not the same as a loop you learned anything from. And the compression is asymmetric: agents are brilliant at building-to-learn and still patchy at building-to-last, so the gate between "prototype" and "production" matters more, not less.

The second change is quieter and, I think, far more important: agents let you run more loops. Where before you could afford one discovery loop and one delivery cadence, you can now afford many more: a research spike here, a validation loop there, a tight build-test-fix loop, a monitoring loop that watches production and feeds itself back in. The number of loops you can keep alive at once can rise dramatically. That is the change that reshapes the work.

Cheap loops create more loops

Loops get cheaper because you no longer have to run every turn yourself.

Each loop, and each stage of each loop, can sit at its own point on a dial between fully human and fully machine. This is not a new idea; human-factors researchers have been describing levels of automation for decades. The key point is that automation is not one setting for the whole task. It can vary by step. You might gather information automatically, analyse it together, decide as a human, and act automatically. Karpathy's "autonomy slider" is the same idea for AI: a control you move to the right as trust is earned, not a switch you flip.

So some loops run almost entirely human: talking to a customer, making a values call, deciding what not to build. Some can run almost entirely by machine: regenerating tests, redeploying, watching dashboards. Most sit somewhere in between, with the human and the agent handing work back and forth within a single turn of the loop. The diagram shows this directly: each ring is coloured by who mostly turns it — human, agent, or both.

And once a loop is cheap to run, you run loops you'd never have bothered with. There is a Jevons-like effect at work: make a resource cheaper and you often consume more of it, not less. Cheaper loops don't necessarily buy you fewer loops and more idle time; they buy you more loops, and a pile of work that was never worth doing suddenly becomes worth doing. That's the part I find most exciting, and it isn't really about AI — it's about what becomes possible when the cost of a feedback cycle falls through the floor.

This doesn't remove the human. It moves them.

Here's the conclusion I keep coming back to: human work is moved, not eliminated. Push a loop hard to the right, let the machine run it, and the human doesn't disappear. They relocate. They stop being the operator and become the supervisor of a verification loop, and the load there goes up, because machines generate far faster than humans can check.

So the binding constraint moves. It used to be production — how fast can we build or create a thing. Now, increasingly, it's verification — how fast can we trust what's been analysed, created or built. The bottleneck moves from writing to reviewing (which is exactly why the companion piece to this one was largely about reviewing code you didn't write). The failure modes are the classic automation ones: the hand-off problem — an agent that runs autonomously and then drops a decision on a human who has stopped paying attention — and over-trust, sliding the dial right faster than the thing has earned it.

None of that is an argument against giving loops more autonomy. It's an argument for being clear about where the human goes when you grant it, and for designing the verification loop as deliberately as you design the work.

What keeps it from flying apart

If you're going to run dozens of loops inside one product loop, a few things hold it together. I've put them on the diagram as guiding principles, but I'm confident these are not really new, just best applied with a systems mindset:

 1. Separation of timescales. The inner loops have to run much faster than the outer one. This isn't a preference, it's a stability condition — it's how cascade control works in any nested feedback system. Stick a slow human approval inside a fast agent loop and you get exactly the instability you'd predict.
 2. Conservation of human attention. Automation moves attention; it does not abolish it. Plan for where the attention goes, not just where it's saved.
 3. Match autonomy to stakes. Reversible, cheap work can run autonomously; irreversible, expensive work stays human-guided-and-gated.
 4. The substrate compounds. Context, memory, relationships and tooling make every future loop cheaper. Every loop that writes something down makes the next loop faster. The substrate – human and machine – is the real moat, not any single clever loop.

What it means for how you organise

I'm least certain here, so take it as provocation rather than prescription. If the unit of work is the loop and not the phase, a few things follow that sit awkwardly with how most teams are built.

You stop managing phase-gates and start managing a portfolio of loops — which are running, at what cadence, at what mix of human and machine, and which ones need more human attention than they're getting. Roles stop mapping so cleanly: a product person ends up working inside what used to be "delivery", an engineer inside what used to be "discovery", because the loops don't respect the old boundaries. And the senior job changes shape — less reviewing the output of each loop, more designing the system that produces reliable loops: the substrate, the guardrails, the verification, the decision about where the dial sits.

That's a bigger change than "we adopted some AI tooling". It's a change in what you're managing.

What I’m watching next

I'm working this out as I go. The model in the diagram is as much a description of what I noticed happening as a theory I set out to prove. I don't think it's finished and, in particular, I'm still watching what this does to team shapes and organisational design.

The things I'd watch out for: whether the verification load quietly swamps the gains; whether "more loops" turns into motion that merely looks like progress; and whether the quality of what gets built actually improves, or just the quantity.

But I'm fairly convinced of the shape. Product development was always loops pretending to be phases. The interesting thing about this moment isn't that the machines can build. It's that, for the first time, we may be able to afford to run the loops for real.

---

# Living on the agentic frontier
_https://rafeblandford.com/rafeos-agentic-edge/ · 2026-06-30_

There are two settled opinions about personal AI agents, and they can't both be right.

One says we're a release or two away from a digital chief of staff that runs your life while you get on with the important things. The other says it's autocomplete with better marketing. I've spent months running agents over my own data (my real calendar, my real health figures, my actual messages) in a system I call RafeOS, and I've ended up somewhere that fits neither camp.

Both sides are arguing about a place most people haven't actually been yet. I've been living there for months, further in than most, so this is the dispatch: what's been good, what surprised me, what quietly didn't work, and what it means for the way work gets done.

Am I using agents?

It's the first thing people ask, and I used to fumble the answer, because "agent" has come to mean many different things. I think the cleaner way to articulate it is as a spectrum.

At the simplest end, a plain passthrough (just showing data, with no model at all), then simple automations (deterministic rules, still no model), in the middle automatic workflows (a model doing one or more fixed steps in a path I've laid out), and, at the far end, genuine autonomous agents (a model handed a goal that works out the steps and the tools for itself, looping until it's done).

The first two sometimes get counted as agents, but it's the latter two, where there is model-backed reasoning, that I would count as AI agents. This still clearly encompasses a wide variety of complexity and sophistication, so the level of delegation and autonomy is still important to understand.

So, yes, by this definition, I'm using lots of agents. There are multiple workflows built into various parts of RafeOS, with varying levels of complexity (e.g. message triage, reading ranking, briefings). I have more of these workflows that I can call on-demand to do certain tasks (a lot of these are encapsulated as skills) and more that run as unattended scheduled tasks, some with quite complex goals.

My custom Claude Cowork setup behaves like an agent in itself and runs multiple sub-agents (including being home to some of the workflows mentioned above). The general RafeOS-enabled assistant I reach from within Claude and ChatGPT, or my messaging apps on my phone, is another. The coding harnesses that I use to build personal projects like RafeOS are agents. And then lots of the software I use also have agents in them, though my focus here is on the custom stack.

What I don't really have is the thing people usually picture: a fleet of named bots with personalities, a little family of agents. I treated that absence as a gap for a while, then stopped, because it's the cosmetic version of the question.

The skill isn't running the most agents. It's matching the level of autonomy to the task: a rule where a rule will do, a workflow where the path is known, a full agent only where the work is genuinely open-ended. An agent is the most capable and the least predictable option, and a lot of what a personal system does all day doesn't need one.

What's been good for me

The biggest win for me is that an agentic harness that's fully wired into my own context (and tools) is dramatically better than the out-of-the-box version of the same model. Working in Claude Code, Codex, or Claude Cowork, where the assistant is inside my substrate (a unified personal knowledge/data layer with project maps, curated context about my work and my life, session logs, plus access to local files) is something that still feels magical to me.

And it compounds. Every well-curated piece of knowledge, every project map, every tool you connect, and every pointer you write down is a thing you generally don't have to explain again, so the system gets quietly more useful the longer you live in it. Not because the model improved (though that's happening too), but because the ground it's standing on got richer. It's a slope, and it only tilts one way.

Anthropic and OpenAI know this well, which is why the project, tool and memory features bundled into their desktop and mobile apps have become increasingly impressive over the last 12 months. As an aside, this also means the lines between agentic interfaces have become increasingly blurred, though personally I still find it helpful to split things into agentic chat (ChatGPT, Claude Chat, Gemini, which act as conversational windows) and agentic harness wrapper (Codex, Claude Cowork/Code, Gemini Spark/CLI, OpenClaw, which wrap the model in a persistent local environment and give it direct tool-execution privileges).

Build less interface, not more

There's a pattern that runs through the whole system, and it's the opposite of what I assumed this would feel like. The goal turns out to be less interface, not more.

With hindsight this is obvious when building on top of a conversational interface (and is part of a bigger trend that is seeing more and more apps collapse into AI apps like Claude and ChatGPT), but it's a principle that goes further.

The morning briefing is where that pays off most visibly. Every input is mundane on its own; I could get the weather, the calendar and the train status myself in three apps and ninety seconds. The point is that I don't, and that the briefing has weighed them against each other before it reaches me.

The same shape governs the rest of RafeOS. Messaging doesn't show me every message; it floats the handful of important ones or the ones I've forgotten to reply to. Transport doesn't ask me to check it; it pushes a Tube delay to the top only when there's a disruption and it knows I'm about to head out, so the alert is prominent precisely when it's relevant. Somewhat embarrassingly, I spent some early time building perfectly nice transport and weather modules; I rarely open either (though both still feel super useful when I do need them because they are micro-personalised to me). Not because they're bad, but because the briefing made them redundant for the common case. The win is a quieter system, not a busier one.

The interface assembles itself around the moment, rather than waiting for me to come and find it — and because it’s built on my own context, what it surfaces is mine, not a generic feed. Less an app to navigate, more a system that’s already done the looking. This is what an adaptive user experience really means: a surface that reshapes itself around the person and the moment, instead of showing everyone the same fixed thing. I doubt this is where it stops.

Sparks across domains

One evening I was using Claude to think through the week ahead (planning agent), which included a visit to my parents, and it suggested I make time to relax with the kitten. A strange thing for a planning conversation to say.

Why it could is the interesting part: days earlier, in a completely separate context, I'd been using Claude to explore what you need for a new kitten, and that research was sitting in my shared substrate (I may have also later mentioned that Merlin had arrived, I honestly don't remember). In a different frame of mind entirely, it reached from the one domain into the other and made a sensible, human suggestion. It was kind of magic at the time (...after the fact probably predictable as it was likely reading context about my parents and also linking back to me saying it had been a stressful week).

These cross-domain sparks are the most striking thing I've seen and they keep happening (some joyful like Merlin, some genuinely thought provoking, others obvious-in-hindsight; and yes, some just wrong). It's surprised me because I keep my projects and domains fairly disciplined in my second-brain setup, but the moments of delight appeal to my systems-thinking heart, so I have started seeking them out more deliberately.

Sparks across tools

The kitten was the substrate reaching across two domains in memory. The same thing happens a layer down, in the tools — except there it isn’t memory doing the reaching, it’s an agent composing capabilities I never wired together by hand. The morning I got into SXSW London sessions I’d otherwise have missed is a good example.

I’d had an agent research the sessions — which talks, when, where — and at the end it offered to set up a scheduled task to re-check, because these events shuffle the schedule on the day. I said yes without thinking. What I hadn’t done was wire up any notification. But when the re-check ran, it reached for the RafeOS notify tools on its own and sent me a Telegram summary the next morning of what had changed, schedule-aware. I read it over breakfast, saw two sessions had shifted, and caught ones I’d have walked straight past.

Three things composed there (research, scheduling, and notification across a messaging channel) and I'd explicitly arranged none of that combination. Each capability already existed; the agent reached across them because they were all reachable from one place. The value isn't in any of the three tools, it's that they sit over one substrate and an agent can join them up without me drawing the lines first.

Memory reaching across domains, tools composing across a task: the same coherence showing up at two different layers.

The bit nobody demos

This stuff is jagged. It's brilliant in places and wrong in others, and the line between the two is not always where you'd predict.

An example I have: the weekly health briefing once told me, with total confidence, to "seek advice on your blood pressure at the ENT appointment." It had taken an unusually high blood-pressure reading and a grommet-related ear-nose-and-throat appointment that happened to fall around the same time, and stitched them into a single instruction. Two related, but separate health issues. There was no hedging in the tone. Just a clean, confident, and ultimately useless instruction.

That's the failure mode that matters, and it isn't "the AI doesn't know things." It's that the AI is generally designed to be exactly as fluent when it's right as when it's nonsense. The confidence is constant; the correctness isn't. The fix wasn't more intelligence, rather it was updated instructions (a lesson against conflating a health finding with an unrelated appointment).

The other half of the jaggedness is me, not the model. I've done some of these tasks by hand for years, and handing them over is a behaviour and mindset change before it's a technology one. Behaviour change runs on trust, and trust is earned slowly. The system has to be coherent often enough that I stop double-checking it, and that coherence over months, not any single clever output, is what is shifting how I work. I trust the briefing now the way you trust a new colleague (which, if I'm really honest, is not 100%... so still in the trust, but verify stage).

You only find out what sticks by living with it, and "what sticks" is a far better measure of value than "what demos well." A lot of what demos well doesn't survive a normal Tuesday.

Where RafeOS sits, and why it's early

Taken one at a time, my modules are commodity — a task list is a task list, a messaging bridge is a messaging bridge, and, even with some extra AI smarts, none of those pieces would impress anyone who's built one.

What's rare isn't the parts. It's assembling them into one coherent thing you actually live inside — everything over a single store, reachable from a dozen surfaces. This is what makes the joins I described earlier (the kitten, the SXSW notification, the briefing) possible. Coherence is the hard part, the valuable part, and the part you can't buy as a component.

This is the exact wall enterprise AI is hitting right now. Most companies are buying isolated AI point-solutions from an AI writing assistant here to a customer service bot there. But the real enterprise frontier isn’t buying more tools; it’s building a unified context substrate. Until a company's data, across Slack, Salesforce, and internal wikis, is reachable from a single layer, their agents will remain blind. The winner won't be the company with the smartest model, but the one with the most coherent internal graph.

RafeOS is interesting mostly because it's early. Plenty of capable people are converging on this shape, and the platforms are racing to make it easy — but relatively few have actually built it and lived in it yet. I'm reporting from a little further in than most have gone, before the map is drawn.

And there are things other people's versions do that mine doesn't. I'm a geek at heart, so seeing what others have done, standing on their shoulders, and iterating is part of the fun. Or put another way, it's learning about the future by trying to live five minutes in the future.

What I think happens next

The near-term thing I'm watching most closely is local models. RafeOS has deliberately been built so the model underneath can be swapped out, and for my set up a local LLM is the next real test of that. So far it's been no more than an experiment, but the architecture was designed to allow it. Why it matters is partly economic and partly about timing. There's roughly a nine-to-twelve-month lag between what the frontier models can do and what you can run locally (leaving hardware constraints to one side), and that gap, combined with the token economics, is closing the case for personal use.

My best guess is that local LLMs in personal set-ups like this become more common in the back half of 2026 and into 2027. It’s already happening in enterprise, where the logic is identical, just magnified. For a corporate CEO, the calculation isn't about novelty; it's about margin and sovereignty. Moving to open, local, or hybrid infrastructure is the only way a business can aggressively run millions of agentic loops across proprietary corporate data without leaking intellectual property or getting crushed by API token costs. Or maybe this is just an excuse for me to stick another machine in the infrastructure cupboard!

The surface follows the job

The other signal is about interfaces — or rather, that there’s no single right one. Different jobs want different surfaces: a dashboard for the glance (“is everything roughly fine?”), messaging for running things on the go, an agentic harness for the dive (“help me think this through”) and the execution (“run this on auto”). And increasingly a fourth kind that’s barely an interface at all — scheduled tasks, embedded workflows and loops running in the background, surfacing only when they’ve something to say or a question to answer. The trend isn’t a single interface; it’s the surface following the job.

Flatter networks and evolved craft

This isn’t just a shift in interface design; it is a preview of an architectural pivot that challenges how we structure companies. The steadier, consistent win of this entire experiment isn't a specific automation, but the fact that the system-wide integration of context quietly absorbs the coordination tax; the checking, the cross-referencing, the keeping of plates spinning.

If this generalises, and the economics of the frontier suggest it should, the shift at work won't be about AI stealing jobs. It will be about redesign of craft workflows and the overhead of internal coordination compressing drastically. When ambient, cross-domain context becomes reachable from any point in an organisation, the structural justification for rigid tiers and roles reduces.

In an enterprise setting, this fundamentally redefines what we value in talent and how we structure organisations.

For team members, it doesn't imply we no longer need expert engineers, designers, or domain specialists; rather, their core craft must evolve. The premium shifts toward professionals who marry deep execution discipline with the ability to integrate and orchestrate agentic workflows. Their hard-won expertise becomes the ultimate quality filter; the structural backbone ensuring the system isn't just fast, but contextually and architecturally right.

For leadership, this forces a new kind of collaboration. Traditional, rigid hierarchies, which are essentially just manual networks built to route information up and down a chain, will struggle to keep pace. When status-chasing is absorbed by agents, a leader’s job moves from managing tasks to architecting the environment. It becomes a flatter, more fluid and integrative style of leadership: ensuring the team's underlying substrate and system is clean, encouraging a culture of psychological safety and inter-connectedness, while also guiding people through the messy behavioural transition of learning when to trust the automation and when to pull back.

Ultimately, stripping away the organisational and craft friction doesn't diminish the human role, it elevates it. It clears the field so we can focus on the work that always required genuine human judgment: the complex orchestration, the deep relationships, and the high-stakes decisions. Not a threat and not a utopia.

The baseline of the frontier

The agentic frontier is not a chief of staff and it's not a parlour trick. The occasional cross-domain spark and cross-tool synchronisation is real and helpful; the steadier, consistent win is that a system this wired into your own context compounds, getting more useful the longer you feed it. You learn to trust it at the speed trust is earned, you fence off the places it goes confidently wrong, and you need less interface rather than more.

That's less exciting than the pitch and a great deal more useful than the dismissal. Most of this will be ordinary in a year or two, which is exactly why it was worth living here first. After months of it, I'd take useful.

On how this was made: RafeOS is built collaboratively with AI, and this post was written by me, with some editing support from Claude. The nature of this post means it has a higher human proportion.

---

# What a personal AI system costs
_https://rafeblandford.com/rafeos-what-it-costs/ · 2026-06-29_

Whenever I describe RafeOS to people, the first question is almost always the same. Doesn't all of this cost a fortune in AI? Agents reading your email, ranking your reading, writing your morning briefing: surely the token bill runs away from you.

The honest answer is no, and the reason is more interesting than the number. An agentic personal system is genuinely affordable, but that isn't luck. It's the product of a few deliberate decisions about which calls are allowed to be expensive. Treat everything as a job for a full agent and you would overpay handsomely. Get those decisions right and the spend is small and, more importantly, bounded.

This is the post where I show the working. Every figure is early state and indicative, and I'm still firming the numbers up, but it's the shape of the discipline, which transfers directly to anyone wiring AI into a product (and it is also one I can talk about it publicly, which is not true with some of my other work).

The cheapest call is the one you don't make

If there's one idea to take from this post, it's this. Most of the conversation about cost assumes the only question is which model you reach for. The sharper question, the one I had to design around, is whether you need a model at all.

A lot of what a personal system does all day isn't a judgement call. Has a measurement not been logged in three days? Is this Tube line reporting anything other than good service? Has this thread been sitting unanswered past my two-week boundary? None of that needs a model. It needs a few lines of plain code with a clear rule, and plain code is free, instant, and rarely wrong.

So the real spine of RafeOS cost isn't one boundary but three tiers, and the discipline is pushing every job to the cheapest tier that can actually do it:

 * Deterministic rules (no model at all). Anything that can be expressed as a rule over data I already hold: thresholds, dates, status flags, presence. The cheapest call is the one you don't make.
 * A cheap, fast model (classification and ranking). The narrow judgement calls. Is this email action-needed or noise? Which of these reading items earns a slot today? Real judgement, but narrow judgement, and a small model like Claude Haiku does it well for almost nothing.
 * A frontier model (genuine reasoning and voice). The work that needs depth, or has to read as if a thoughtful person wrote it. Claude Sonnet territory: the weekly briefing's one reflective pass, the rare thing that earns the big model's money.

The mistake I sometimes see is treating every job as the top tier because "it's all agents now". That's a lovely demo and a terrible budget. Most of what the system does sits in the bottom two tiers, and a fair chunk doesn't touch a model at all.

When I built the messaging triage, model-based scoring on its own wasn't reliable enough. The fix wasn't a bigger model. It was a salience layer of deterministic rules underneath the scoring, doing the cheap, obvious filtering before anything reached a model. Cheaper and better. That pattern recurs across the system: rules first, model only for the bit that genuinely needs reasoning.

Library call or session

The three tiers tell you whether to use a model and which one. A second, narrower line decides how you call it, and this is relevant in a subscription versus per-call costing scenario.

The question is whether the calling code already knows what it needs the model to do. If it does (a known step with a known shape, like "classify this message" or "summarise this thread"), it doesn't need a whole agent. It needs a single model call: one prompt in, one structured answer out, no session, no tools, no reasoning loop. There's a small rafeos_llm helper for exactly that.

If it doesn't (the task is open-ended, might take several steps, might need to choose its own tools), it gets a session. Interactive when I'm there to drive it (subscription-covered, so I don't watch the meter), or headless (e.g. claude -p) when it's a remote or scheduled one-shot, which costs pennies.

A session is a powerful, general thing, and you pay for that generality. A library call is a function that happens to use a model. Most of what a personal system does all day is the second kind, and reaching for a session every time is another way the bill runs away.

What the actual envelopes look like

Here are some of the real numbers, with a firm caveat: this is an alpha system, so the figures are indicative. The orders of magnitude are the most interesting thing.

 * Email and message triage. The dominant line by a clear margin, not because each call is dear but because of the sheer volume going through email and messaging. The action-needed ranker runs on Claude Haiku with a hard daily cap. It's where I'd look first if costs ever crept up. I also need to work out how to be more efficient on token volume.
 * The morning briefing. A handful of model calls a day. It isn't regenerated every time I glance at it; it's built once per block of the day and reused (more on that below), which keeps a composite-of-everything surface from being expensive. Its top section, the few things to do and to know, is assembled deterministically from tools I already have, so the most-looked-at part of my day costs almost nothing.
 * The weekly health briefing. This one earns a single call to Claude Sonnet: its one genuine depth pass, where the reflective, joined-up reading is worth the money. One deliberate expensive call, not a hundred cheap ones dressed up as a session.
 * A remote headless query. When I fire claude -p from my phone to ask the system something, a typical query costs a few pence. Cheap enough that I never think twice about asking.

To put rough numbers on it (estimates, mid-build; the proportions matter more than the pennies):

Tool / jobModelIndicative £/monthEmail + message triageHaiku, daily-capped~£12–18Reading ranking + other classificationHaiku~£3–5Daily briefing (~5 calls/day, snapshotted)Sonnet~£3–6Weekly health briefing (1/week)Sonnet~£0.50–1Headless claude -p queries (~3p each)Sonnet~£1–3Metered total~£20–30

Triage dominates not because any single call is dear but because of the volume going through it. The daily briefing's phrasing runs on a better (more expensive) model, but it's snapshotted, so a handful of calls covers the whole day.

One small operational nicety: each tool has its own API key, so each tool's spend shows up as a separate line in the dashboard. I can see at a glance which part of the system is costing what, and that view tells me unambiguously that triage is the line that matters. It's good enough up to four or five tools.

Deciding what runs, and when

The envelopes above are the per-call story. The bigger cost decision is about the regularly-scheduled background jobs that run without me asking. Each one is a standing cost, so you have to actively decide what's allowed to run, and how often.

You could run everything on-demand, only making calls when there's an automated or human interaction. It would keep costs down, but it's not really practical as the multi-second response time makes for a terrible "live" experience. So pre-warming makes sense (forecast when you'll need it), as does smart caching.

A couple of compromises fall out of this in practice. I don't run things overnight; there's no point paying for a briefing at 3am that I'll never see. And I've made the schedule morning-heavy, partly because that's when I use it and because some of the input data only arrives at a certain time. A lot of the health context lands after I've slept, on the Oura sync, and running the health pass before that data exists would be paying for a worse answer. The schedule isn't "run everything as often as possible". It's "run each thing once, at the moment it can actually be useful".

There's a safety net under all of this: daily caps on the metered jobs. They've never tripped, because I haven't been aggressive about scheduling, but I keep them precisely because I can see how quickly this could add up if I stopped paying attention. A loop that misfires, a job set to run every five minutes instead of every morning, a triage pass let off its lead. The caps are there so a mistake costs me a fenced amount, not an open-ended one.

Generate once, reuse all day

The briefing points at one more lever, almost embarrassingly simple: don't regenerate what hasn't changed.

The morning briefing is built on a snapshot cadence. It's generated once every few hours for a block of the day and then served from that snapshot (to the dashboard, to my phone, wherever) rather than freshly composed on every page-load. If I open the Cockpit five times before lunch, I'm not paying for five briefings. I'm paying for one and reading it five times.

It sounds trivial written down, but caching the output of an expensive call is one of the highest-leverage things you can do to control AI cost, and it's the one most easily forgotten in the rush to make things feel live. Most personal data doesn't change minute to minute. Your model spend shouldn't either.

So what does it actually cost?

Here's where I have to be honest rather than tidy, because there isn't one clean number. There are three, and the gap between them is the whole point.

The direct cost of RafeOS (the cockpit and the tools it calls, the metered machinery that runs by itself) is roughly £20 a month. That's the figure most people mean when they ask what RafeOS costs, and it's small.

If I'm fairer and allocate a proportional share of the broader setup to RafeOS (some of the interactive building, the substrate it leans on, the bits that overlap with everything else I do) I'd put it nearer £80 a month. Reasonable people could argue that number up or down; the boundary between RafeOS and "the way I work now" is genuinely fuzzy.

And my total personal AI spend is around £200 - £250 a month. Most of that is not RafeOS. It's Anthropic and OpenAI subscriptions, some per-use costs (including the £20 above), a clutch of AI-first productivity tools (I love Wispr and Granola), the odd experimental thing I keep around to learn or compare. There's probably more adjacent spend (e.g. Google Gemini comes through my wider Workspace subscription).

RafeOS is a beneficiary of this spend, not the cause of it. If RafeOS vanished tomorrow, the £200 would barely move.

What this means for anyone building with AI

Add it up and the conclusion is almost anticlimactic. RafeOS runs for a small, bounded amount because the architecture refuses to let cheap jobs cost expensive money. Four habits do most of the work, and none of them is exotic:

 * Don't call a model if a rule will do. The cheapest, fastest, most reliable tier is plain code. Reach for a model for genuine classification or reasoning, not for things a threshold can answer.
 * Tier the models you do use. Narrow judgement on the small fast model, depth and voice on the frontier one. The model choice, not the call count, is where the money goes.
 * Decide what runs and when. Scheduled background jobs are standing costs. Run each one once, at the moment its data exists and you'll actually use the output. Cap them so a mistake is fenced.
 * Cache what you generate. Produce expensive outputs once and reuse them across surfaces. "Feels live" is rarely worth regenerating what hasn't changed.

That's the part that generalises, and it's the same restraint that makes any system affordable: know which operations are expensive, and only spend there when the job actually earns it.

There's a wider point underneath the numbers, and it's the honest answer to "should you do this too?". Cost discipline is, I think, what will hold some people back from building something like RafeOS. Not the engineering, but the running cost and the fear of it. My own stance is that it's an investment in understanding how this actually works: the real economics of agentic services, where model costs land, what the constraints and pressure points are. The value is genuinely there for me.

And paying attention to the bill is exactly what surfaced the next two moves: running a local LLM for the cheap, high-volume tiers, where the token economics start to favour it, and the data-and-privacy upside that comes with keeping more of this on my own hardware. You don't see either clearly until you've felt where the money goes.

This post was drafted with Claude and edited by me. The figures here are from June 2026 and a system still under active development, so treat them as indicative.

---

# Agentic product development, up close
_https://rafeblandford.com/rafeos-collaborative-ai-engineering/ · 2026-06-29_

RafeOS is my personal agentic layer, reading and (carefully) acting on my own data and services. I’ve written elsewhere about what it is, why I’m building it, and the product shape it is starting to take.

This piece is about what sits underneath it: a real, non-trivial codebase (a modular API, a command-line tool, a progressive web app, multiple agent integrations, and associated infrastructure) built and maintained over several months almost entirely through collaboration with AI.

I'd say 99% of the code has been generated by Claude Code or OpenAI's Codex, and I've leaned on AI almost as heavily for discovery, product strategy, specification, experience design, technical solution design, testing and deployment.

The interesting lesson is not “AI writes code”. We know that now. The more important lesson is that AI can compress the whole product-development lifecycle. You can move from a vague need to a working feature at a speed that still feels slightly unreal.

But that compression leaves gaps.

An agent can research, propose, design, implement and test against the world it can see. But it still needs you to know which use cases matter, which risks are unacceptable, and which features should not exist at all.

That is where the human still earns their place; not by typing every line of code, but by shaping the conditions under which good code is likely to be produced.

RafeOS wouldn't exist if I weren't building it this way, because I'm probably not a good enough developer to build it any other way. What's changed is the speed, the scope and the breadth of what I can now attempt. I can now build something genuinely personal, across a dozen domains, at a pace I couldn't otherwise manage.

The why and the what are still mine. The how is increasingly agentic. And the how is genuinely impressive.

The thesis: compression, and the gaps it leaves

When you build for yourself, with an agent, you can compress, or even skip, most of the stages a textbook process would tell you to do in full. Discovery becomes an interview. Specification becomes a working plan. Design becomes a set of generated options. Implementation happens in loops measured in hours and minutes. Testing is created alongside the code. Iteration starts almost immediately.

This is the gift.

The risk is that everything becomes plausible too quickly. Prototype is not production. Spike is not solution. The messy middle of any build is still there: the real behaviour nobody wrote down, the integration weirdness hidden behind a login flow, the edge case you forgot to mention, the assumption that seemed safe until it met reality.

It just arrives sooner. AI really doesn't know what it doesn't know.

Discipline context closes the gaps: the strategy explainer (useful context in PROJECT.md), the solution spec document (PLAN.md), the decision log (DECISIONS.md), the written conventions, lessons and architecture (in a CLAUDE.md), the tests, and (most powerfully) the decision not to build something (BACKLOG.md).

None of that is exotic AI tooling. It's ordinary product development rigour, restated and reframed for the AI-first world. Doing it well takes time.

Where that rigour used to keep a human team coherent, now it stops a fast, confident, slightly amnesiac collaborator from compressing your build into something that mostly works.

The clearest way to show this is one feature, end to end.

One feature, end to end: messaging

Messaging is the most complete worked example I have. I wanted RafeOS to help me with messages across email and chat, because that was where things were genuinely falling through the cracks: missed replies, fragmented context, and the small but accumulating cost of checking too many places.

Starting with the problem, not the implementation

I started by having the AI interview me: what are the pain points, what would good look like, where does the current mess hurt?

Out of that came a small set of jobs (triage; catching replies I'd missed, email especially; pulling context from previous conversations; occasionally getting a draft for a reply). Letting the agent run a discovery interview is a technique I used previously in knowledge work. It's a fast way of drawing out the problem space, but you need decent self-awareness and a goal in mind.

The most important decision was what to leave out

Fully automated replies were off the table from the start: anything going to an external person needs my explicit approval, however good the draft.

Choosing not to do something is consistently the more powerful choice, and it's the one a token-munching agent will rarely make for you. For me, this is the phase that is most human-centric.

Choosing a backbone, not a pile of integrations

With a clear value hypothesis (triage and surface what needs a response, unified across email and chat) I looked at a couple of solution routes.

Email was the easy half: I built on Google Workspace tools, wrapping their primitives into verbs that match the rest of the RafeOS API.

Chat was harder. I evaluated Matrix as the backbone, alongside a patchwork of thin clients, ran a few spikes to find the right homeserver and test other risky assumptions. I settled on Conduit, then built a thin RafeOS wrapper around it following the same conventions as everything else.

The important choice was modularity. Matrix bridges made it possible to add new messaging services without turning RafeOS into a one-off monolith. That is exactly the sort of thing that is easy to miss when an agent can produce a working version in one session.

Designing the interface in parallel

Running in parallel to the discovery and specification work, I used Claude Design to think through the front-end and explore design options. For the Messaging feature this was relatively simple because it drew on conventions already established for Cockpit.

But, in general, the same coherence and consistency discipline applies (design system as a foundation, be clear and bounded in what you are exploring, start high-level and move to implementation spec).

From spec to implementation

Working collaboratively with Claude, I generated a high-level brief document drawing on the wider project context, research agents, the solution and design routes described above, plus third-party documentation. It's best to think of this as meta-context, with pointers to other artefacts and references.

This was passed into Claude Code's plan mode to validate, add detail, and create an execution plan. And then, for the most part, I let things run on auto mode, making decisions and granting permissions as needed.

I find this iterative stepped approach stops the agent racing ahead of a decision, and makes you feel like you are steering more.

Testing, quicker simulation, visual testing

Testing and deployment were almost entirely Claude Code's domain too — close enough to the build that, here, they felt like part of it. For Messaging, the best value came from testing against simulated states. This won't be novel to a QA engineer; it's the familiar world of test harnesses and simulated data. However, generating synthetic data for the states you actually care about and running through tests is something AI is particularly good at.

The right tooling and orchestration is important. I used to do a lot of the checking by eye. Giving Claude Code a headless browser via Playwright changed that for the routine checks — a reminder that a lot of what looks like a capability ceiling is just the agent not having been handed the right instrument.

The messy middle: LinkedIn

The gaps still appeared. I assumed I could bridge LinkedIn the way I'd bridged the others. WhatsApp, Signal and Telegram were straightforward; LinkedIn was not.

Its login and session-checking are restrictive enough that the bridge technically worked but wouldn't stay logged in, and after a fair amount of effort I concluded it wasn't possible.

That is a good example of the messy middle: the place where a plausible solution meets an awkward reality. The difference was that I could explore it and draw a conclusion in hours rather than days.

Living with the first version

The first version of the Messaging feature triaged messages with a model deciding what mattered. It didn't work well enough; the scoring was mushy and the real-world results mixed. So I both tweaked the classification prompt and added a salience layer of deterministic rules: plain logic, no model call, doing the part that doesn't need a model.

I could make that change quickly because the previous architecture and the reasoning behind it were already written down, in the CLAUDE.md files and the session records. The agent read what we'd decided and why, and built on it, instead of re-doing the design from cold. The discipline from the last build is what made the next change fast... and is, I think, one of the key advantages over one-shot or vibe engineering approaches (though I do like these for prototyping or rapid visualisation).

Shipping the foundation, then learning from use

The whole thing was five or six sessions: research, planning, design, a first implementation, polishing, then a couple of iterations once I'd lived with it. That last part is the other half of the truth about compression. You ship the foundation in v1, and then using it tells you what you actually needed (sometimes just config, Matrix has a lot of dials; sometimes a tweak to the wrapper).

A stack chosen for the collaboration

For Cockpit the front end is React and Next.js, with shadcn/ui and Tailwind, all in TypeScript. I picked the popular, conventional stack not because it's well-trodden for humans but because it's well-trodden for the model. The more familiar the stack, the more often the agent gets it right first time, and the less of my day goes on the “wrote it slightly wrong, fix it, try again” round-trip tax. With a niche framework the agent guesses more often; with a well-established one it is operating in familiar territory. I was optimising for the collaboration, not just the code.

The same instinct produces the single best reliability move in the system. The API publishes an OpenAPI schema and the front-end’s types are generated straight from it — so the front-end can’t quietly invent an endpoint or field that isn’t in the schema: if it tries, the types don’t match and the build fails. It only binds the front-end to the contract, and only while I keep the types regenerated. But within that it turns a whole category of confidently-wrong output into an error the agent catches before I ever see it.

Version control plays the same enabling role. With an agentic builder, Git stops being the tax you pay for safety and becomes the thing that lets you move fast: reverts, branches and merges mean I'll happily let an agent attempt something ambitious, knowing I can cleanly undo it. When reverting is cheap, a clean undo button is what lets you use the speed.

The guardrails that make a flaky agent reliable

The generated-types pattern above is one example of a wider habit. The model is, by default, a brilliant junior who sometimes states a wrong answer with total confidence, and the skill is scaffolding its output into something dependable. Two more that have earned their keep for me in this project (there are many others):

 * Strict typing as a net the agent falls into. Tight types mean a class of mistakes fails at compile time instead of quietly at runtime. The type checker is an automated reviewer that never gets tired.
 * A CLAUDE.md per project, the single highest-leverage artefact in the system. I lean on tips from Karpathy and others here. It's the difference between an agent that drifts and one that stays on the rails.

None of this is exotic. It's contracts, types and documented conventions, applied to constrain a probabilistic collaborator. I find that quite reassuring about the future of the discipline: the rigour that was always good practice is now the thing that separates working from not.

Reviewing code you didn’t write

There’s a question lurking under all of this: how do I review code I couldn’t have written? I don’t read most of it line by line, and if I did, I couldn’t reliably spot a subtle bug. Given how long it's been since I worked with code day-to-day, and how fast engineering is changing, I can really only judge quality at a high level.

What I trust instead is the scaffolding around the code: types that won’t compile if a shape is wrong, an API contract the front-end can’t drift from, tests against the states I actually care about, and above all the behaviour — does it do the right thing when I throw the awkward cases at it?

Ultimately, I’m reviewing and directing the system that produces the code more than the code itself. That moves where the risk sits, and significant risk remains: on a personal project, I'm OK with this because a miss costs me an annoyance, not anything more serious. On something with sharper consequences, I'd want a review from an experienced senior developer (and, frankly, I wouldn't put me in the engineering seat).

The underplayed stages

Echoing back too "things becoming plausible too quickly", here are two areas where compression creates silent, structural vulnerabilities that require aggressive human reinforcement:

 * Security, compliance, scale, and trust as design-time concerns: decisions around robustness, rules about data storage and retention, and adherence to non-functional-requirements in general; plus balancing between them all feel particularly fragile under compression. This is not a new issue, but gaps here are particularly susceptible to human fallibility. This is not a new issue, but AI introduces a dangerous asymmetry here: an agent can generate outputs at blistering speed while remaining entirely blind to downstream compliance risks. For example, if security isn't explicitly hardcoded into the initial prompt substrate, the agent will optimise purely for feature completion, baking vulnerabilities directly into the foundation.
 * Maintenance and operations: the first version, ends at "it works", but the real life of a system is the months afterwards. AI compresses the build phase without reducing the long-term operating burden; in fact, it frequently inflates it. Human technical debt accumulates through time-pressure, shortcutting, or fatigue. AI technical debt, what I think of as hyper-debt, accumulates through frictionless velocity. Because the marginal cost of generation is near-zero, an agent will happily output thousands of lines of verbose, slightly off-pattern code without ever feeling the design strain. The system functions today, but a little while later, you realise you are maintaining a vast, automated house of cards. I can already see the early patterns of this debt in my own follow-up work and ongoing maintenance efforts.

Loops

Going through this end to end has also got me thinking about the wider shape of product development itself. Everything above was, in effect, a stack of loops — research, spec, design, the salience-layer fix, the iterations once I had lived with it — each run at a different blend of me and the agent and very much intersecting or bolting on to each other (note that agentic engineering loops, a hot top right now, are part of this, but here I'm thinking wider).

Product loops (various guises) should be a familiar concept. Good product development is rarely linear: the frameworks all say so, even if time-boxed phasing never quite vanishes in practice.

What changes with agents is twofold. First, they collapse phases together, or at least lets them run in parallel more easily — partly through the compressed loops, which I do have mixed feelings about; and partly by encouraging a real redesign of workflows, which I am much happier about.

Second, and more far-reaching: you can run more loops — human, hybrid, or agent — inside one wider product loop. That follows from the two threads this whole piece keeps circling: who does what (the autonomy continuum), and how much capacity you have (human and machine). It does not replace people; it reallocates them to higher-value, more interesting work, and makes things that were never worth doing suddenly feasible (Jevons’ paradox).

I sense this is good for the quality of outcomes, even if — like everyone — I am still working out the details. The diagram below is a first attempt to map it; I am developing the argument properly in a separate piece.

An important field note

One caveat before I extrapolate too far: all of the narrative above comes from a project with a single creator, a single user, a blast radius of one, and a blank page to start from. That sidesteps most of what makes team software hard: shared ownership of code no one person wrote, brownfield complexity, compliance, security review, operational accountability, and the cost of a confident mistake landing on a customer rather than on me.

However, drawing on my wider experience, I do not think that changes the direction of the argument. If anything, it sharpens it. At scale, the guardrails I can treat as optional become mandatory. “I don’t read most of the code” is a luxury that does not survive shared ownership. The written context, contracts, tests, review habits and human/AI gates matter more in a team setting, not less.

Which is rather the point.

What this tells me about engineering teams

The value does not disappear. It migrates away from typing code and towards everything around it: the spec, the contracts, the written decisions, the conventions, the choice of stack, the tests, the review model, the choice of what not to build. The teams that thrive will be the disciplined ones, and the discipline compounds, because last build's written record is what makes this build's change fast. The senior person's job shifts from reviewing the output towards designing the system that produces reliable output in the first place.

You cannot lead that shift from the audience. You don't have to become a full-time engineer again, but a technology leader who hasn't run a real build this way, end to end, is now reasoning from a model of software development that's quietly going out of date.

The shift is not visible from demos, conference talks or vendor decks. It becomes visible when you have to decide what to trust, what to constrain, what to test, what to reject, and what to live with after the first version works.

The detail is where the lessons are.

On how this was made: RafeOS is built collaboratively with AI, and this post was drafted in conjunction with Claude and edited by me.

---

# What it runs on
_https://rafeblandford.com/rafeos-home-infrastructure/ · 2026-06-28_

I've written a fair bit about what RafeOS is and why I built it: the platform, the surfaces, the agents that act on my data. This post is about the floor it all stands on. Borrowed and boring, on purpose.

Nothing here is novel, but I've had a few questions about the setup, following on from earlier posts.

The right box for each job

 * My Mac is the workshop and where I run the interactive agent sessions. I'm also using it to run local LLMs for the time being.
 * Anchor is the always-on workhorse: a dedicated server that never sleeps, running the bulk of the self-hosted services, the scheduled agent jobs, and some archive sites I keep online (including this one). It's also used to run interactive agent sessions.
 * Crucible is another small always-on node, isolating some of the more experimental stuff (e.g. OpenClaw) and providing some useful redundancy.
 * Mimic is a small, low-power box that lives in a quasi-infrastructure cupboard in my flat. Home Assistant lives here, talking to the Zigbee and Matter devices around the house (I may write about these more in a future post). It also houses some of the more sensitive services and personal data (Influx, Grafana).
 * Wisdom is a NAS, also living in flat cupboard, and is the backup and cold-storage end of things. It's not somewhere I run services anymore. Technically, there's also a B2 backup location, fulfilling an offsite option, but this is not something I have to maintian.
 * My iPhone / mobile devices get used for "remote" sessions. I've ended up doing this more than I thought, even when I'm not physically remote (i.e. sitting on the sofa, wandering around the garden, etc.). There's an interesting behaviour change here in that with AI and agents you can be in supervise mode, signing off on the actions of running interactive sessions and agents.

The network is the trick

All these devices are connected together by Tailscale. Tailscale is a zero-config mesh VPN built on the WireGuard protocol that links your devices into a secure, private network (tailnet) without exposing them to the public internet or requiring complex port forwarding.

It acts like a secure virtual local network (LAN), but one that spans across the globe, connecting all your authorised devices together. With it, they behave like one system with several parts. The laptop can talk to the always-on server as easily as to itself. My phone can reach the whole thing from a café. Anchor can pull a backup to the NAS without any of it being open to the wider internet.

The software, and the services behind it

The always-on boxes run Linux; Mimic runs Proxmox so one small node can hold several isolated machines. Almost everything self-hosted lives in Docker containers behind Caddy, which handles routing and certificates, with Portainer and Uptime Kuma for management and a simple “is it still up?”. Home Assistant runs the house, Ghost runs this blog, and restic copies backups both to the NAS and offsite.

Most of those containers are RafeOS itself — the API, the MCP server and the per-domain modules described in the other posts. The handful that aren’t are off-the-shelf apps filling specific gaps: Miniflux for the RSS feeds behind the reading layer, a self-hosted Matrix server behind the messaging layer.

The hard and expensive things are rented in:

 * The models and associated services — Anthropic’s Claude does most of the reasoning and generation, with OpenAI’s models also in the mix.
 * The critical plumbing — OVH hosts the always-on server, Cloudflare handles DNS, Mailgun sends the email (Tailscale, above, is the network).
 * Durable storage — Backblaze B2 holds the offsite backups, so a flat-wide disaster doesn’t take my data with it.

Infrastructure you don't think about

The version of this that feels notable compared to previous endeavours is that most days, I don't think about any of it.

Robust, well-supported software, updates that are dull, and backups that just happen. A network I set up once that stays low-maintenance. The aim throughout is that the foundations stay quiet so the interesting layer (the agents, the platform, the daily use) has something solid and silent to stand on.

That restraint is the same instinct that runs through the rest of RafeOS: do the boring thing well, automate what you can, and reserve your attention for the parts that genuinely need it.

---

# An agentic harness on swappable layers
_https://rafeblandford.com/rafeos-agentic-harness-setup/ · 2026-06-27_

If you work with AI for any length of time, you end up with one or more versions of an agentic harness (or a personal AI system): typically combining a runtime (powered by a frontier model), a set of tools (connectors and integrations), and a shared substrate (personal knowledge management).

There's a lot of thinking out there on this and it's a fast moving space. I've borrowed from a lot of different patterns. RafeOS isn't a rival to any one; it sits across several of them at once. So this is "here's mine", not "here's the answer". What follows is the part I think is transferable: how it's put together so the pieces can be pulled out and replaced.

The bet, and the hedge against it

Right now, the bet for me is that a combination of Claude Cowork and Claude Code is the right harness setup for me. It's where I do the heavy, think-alongside-me work, and it's good enough that I reach for them daily.

The hedge is that I've tried hard not to build around it. Years of composable architecture teaches you one reflex above all others: don't couple the thing that changes fast to the thing that should outlast it. Agent runtimes are changing monthly. My data shouldn't have to.

So RafeOS is built with consideration for three independent layers:

 * The runtime is the agent doing the reasoning. Anthropic-centric today and, in theory, replaceable.
 * The substrate is where memory and notes live: plain markdown in a Git repo. A human can read it, and so can any agent that can read a file. There's nothing Claude-specific about a .md file.
 * The tool platform is how the agent reaches my data: a plain HTTP API with predictable verbs (/v1/<module>/<verb>). Accessible directly, through the CLI, and via an MCP.

It's not quite this simple because Anthropic, OpenAI etc. have their own memory too (various guises, depending on harness), but the way they operate does encourage you to have your own to provide wider and longer-term context.

Has the bet actually held up?

A few months ago I'd have called this "untested insurance". It's now partially proven. RafeOS runs across more than one runtime: I use both Anthropic and OpenAI harnesses regularly, on multiple devices, and the separation has held (and both companies have been iterating very rapidly). I'm also experimenting with things like OpenClaw (see below) and Hermes and can get going faster on these thanks to shared substrate and tools.

The substrate and tools have also been through multiple iterations, and through that churn things have mostly carried on working. That's the bet doing its job: each layer has changed and they didn't drag the others with it.

What the substrate carries best is context across the two places I work. Planning and knowledge work happen in Claude Cowork (and sometimes in ChatGPT), building and execution in Claude Code or Codex. Everything sits on the same markdown substrate, so a decision reasoned through in one is already known to the other. I don't re-explain a project when I move from one to the other, and that continuity is quietly one of the most valuable properties of the whole system.

Running more than one runtime did surface a problem I haven't cracked: how do separate runtimes share memory without colliding? Two agents writing to the same markdown substrate is mostly fine until they both want to write at once, or one acts on a note the other just changed. Git gives me the audit trail and a way to merge after the fact, but it isn't a real-time coordination layer, and I haven't built one.

For now I manage it by discipline rather than design, careful to use each runtime for a different kind of work so collisions stay rare. But "managed by being careful" is a polite way of saying unsolved. It's the honest frontier of this setup, and the bit I'd most like to see someone else's good answer to.

On a related note, what's also somewhat unsettled is syncing the substrate across devices cleanly. Git helps (it's the closest thing I have to a shared source of truth several machines can pull from) but it isn't a finished answer and, in practice, I've ended up using harnesses less on remote servers than I originally thought I would (I do use them for always-on headless one-shot queries).

So: held under real conditions, not yet bulletproof.

Aside: OpenClaw experiments

There's more than one runtime in play. Besides the multiple flavours of Claude and ChatGPT, I've been trialling OpenClaw running on a remote server. I set it up mostly to understand how OpenClaw works, and right now the verdict is that it may be less useful for me than for someone starting fresh. The reason is faintly funny. OpenClaw's whole pitch is wiring a capable agent into your tools and your life, and I'd already done a lot of that. So much intelligence already lives in my RafeOS tools and APIs that the agent layer has less to add. Right now it's mainly teaching me about loops (how an always-on agent paces and re-checks itself) rather than something I lean on.

The next real test of it

The real test of "keep the runtime swappable" is still ahead of me, and it's a local LLM. I built RafeOS to allow for it from the start (a model on my own hardware is just another runtime behind the same tools and substrate) but so far I've done little more than experiment. The swap is designed for, not exercised. Running the whole thing against a local model in anger is something I haven't done yet.

I think that changes in the back half of 2026. There's roughly a nine-to-twelve-month lag between frontier capability and what runs locally, and the token economics keep pulling the same way. Enterprise is already shifting the distribution, and I'd expect personal use to follow. When it does, the layer separation stops being a tidy idea and becomes the thing that lets me move a real workload onto a local model without rebuilding around it.

Aside: where it should learn its own shortcuts

There's a deeper version of self-improvement RafeOS doesn't do yet: skill distillation. When I walk the agent through the same multi-step workflow for the fourth or fifth time, nothing notices the repetition and promotes it into a reusable, named capability. The loop is entirely manual. Mostly it's me spotting that we're doing the same dance, and prompting the co-creation of a skill or an equivalent.

Nous Research's Hermes is the system I'd point to as an interesting pattern: an agent that watches its own behaviour, distils recurring patterns into skills, and improves its memory without a human in the loop. That's the direction I expect a mature personal harness to head, the substrate learning its own shortcuts.

I also want to spend time looking at dreaming, more on that another time.

Why the seams are the point

Strip it back and the claim is small. Almost none of these pieces is novel on its own. Markdown stores, headless agent calls, a tool API, an agent with its own inbox all exist elsewhere, often done better. What I'd stand behind is the coherence: they sit on shared, swappable layers, so the whole thing bends with the field instead of being rebuilt every time the field moves.

Once again this is the composable-architecture lesson, applied to a personal system. You can't predict which runtime wins, or how pricing might have an impact, or which of today's tools or projects survives two years. So you don't bet on any of them. You keep the layers apart, make the seams boring, and let the parts you can't predict be the parts you can replace.

This was drafted with Claude and edited by me, fitting for a post about a system built the same way.

---

# The second brain
_https://rafeblandford.com/rafeos-substrate-memory/ · 2026-06-26_

In common with a lot of other personal AI setups, I keep knowledge as plain markdown in a set of local folders. This is also synced to a repo to make it easier to use on multiple machines. This post is about how I'm trying to keep it a curated knowledge base rather than a collection of files, why I didn't reach for a vector database, and where it's drifting on me.

A note on scope. This is the knowledge layer, the second brain, the substrate. How the runtime itself is wired, why runtime, substrate and tools are kept as separate swappable layers are all points I've discussed in the harness post. It is effectively part of RafeOS, but it's really part of my broader setup for the use of AI and agentic harnesses.

Three tiers

The knowledge substrate has three tiers, each with a clear job.

 * Durable, curated knowledge: projects, decisions, reference material, the things future sessions should treat as settled. Interlinked, deliberately maintained, small enough to be read in full.
 * Transient working files: session handovers, research notes, drafts, the running log of what a session did. Useful in the moment, mostly disposable after.
 * Operational state: the live data (tasks, calendar, health figures, messages). This doesn't live in markdown at all. It sits behind the API, in its proper store, queried on demand.

That third tier is really a story of unification, integration, and query coherence. The knowledge story is the first two tiers, and specifically the line between them.

What’s actually in there

The durable tier isn’t one big document; it has a deliberate shape:

 * About me — who I am, how I work, my preferences and standing context, so a session starts already knowing me rather than asking.
 * Domains, with projects inside them — areas of life and work (home, health, finances, career, family), each holding its settled decisions, reference and notes. Projects live inside a domain rather than in one flat list, which is exactly why the maps matter.
 * Maps — a few one-page indexes sitting over the folders: what exists, which domain it’s under, how far along it is. They’re how the agent (and I) get oriented before diving into the detail.

The transient tier is mostly organised by time and task rather than topic: dated session handovers in a fixed shape (what was done, files touched, what’s next), research notes and drafts, and an outputs area where generated files land, filed by domain. They earn their keep for a day or a week, even a month, and then mostly get deleted or archived.

Claude Cowork projects do overlap a little here. You can achieve some of the above using only a Cowork project folder (it's designed to bring in files after all). So it's accurate to say Cowork integrates and to some extent intermixes with the substrate.

Similarly, technical execution projects are ordinary Claude Code or Codex project folders and Git repos, with the CLAUDE.md, or equivalent, having a pointer to the shared substrate. The difference, compared to Cowork, is the transient tier tends to get folded into the claude Code project folder (it's implementation-first usage for me means this is more structured than it sounds). In practise, this means that Claude Code and Codex reference rather than integrate with the substrate.

The graduation rule

The key convention is what I call graduation, and it's one sentence: if a file holds decisions that future sessions should treat as authoritative, it graduates to the durable tier; if it's context for a single moment, it stays in the working tier.

A handover note from one session to the next is moment-context. It stays working, and it can be deleted without anyone mourning it. A research dump while I'm weighing two options is working. A draft is working. But the decision that comes out of that research ("we went with X, for these reasons, and here's what that rules out") graduates. It moves into durable knowledge, gets linked to the things it touches, and becomes something the agent can rely on next time instead of re-deriving.

Why I pre-compile instead of retrieving

The obvious way to give an agent access to a big pile of personal knowledge is retrieval: embed everything into a vector store, and at query time pull back the chunks that look relevant. RAG. It works, and for some problems it's the right tool.

For a working personal knowledge base I think other routes are worth exploring, and Andrej Karpathy put the reason better than I would in his "LLM Wiki" piece. Retrieval rediscovers your knowledge on every single query. Each question starts from a pile of raw documents and reconstructs an answer from scratch, at the mercy of whatever the similarity search happened to surface.

A curated wiki (set of documents) does the opposite. The thinking is done once, when knowledge graduates and gets written down properly, and from then on it's there to be read. The work of deciding what matters and how it connects has already happened, by hand or by a deliberate pipeline, before the agent ever opens the file. The agent reads it directly, the way you'd read a good internal wiki, rather than reassembling it from fragments every time.

I notice it most in the small things. A lot of the second brain is just well-documented context I’ve written down once, and a good deal of it is markdown pointers — a short note that points at the thing rather than restating it.

That's also where the everyday gap between tools shows up. Claude Code and Claude Cowork are noticeably stronger for me than plain Claude chat or ChatGPT, and the reason isn't the model. It's that those two are fully into this substrate. A harness wired into your context beats the out-of-the-box version every time. The more you write down properly, the less you have to say, and the better the answers get.

The trade-off is honest: pre-compiling costs effort up front, and it doesn't scale to millions of documents. But a personal knowledge base isn't millions of documents. It's a few hundred files that benefit enormously from being curated.

One set of files, two ways in

The substrate is plain markdown, which means I get a good human interface for free. I can opt to navigate and edit it in Obsidian: the graph view, backlinks, the local-first canon that Steph Ango (Obsidian's CEO) sums up as "File Over App", the idea that your knowledge should outlive any particular tool that displays it. Geoffrey Litt and the Ink & Switch crowd have been making the deeper version of this argument for years under "malleable software" and local-first: the file, not the app, is the durable thing.

Obsidian is a view, not the source of truth. I also sometimes use Typora for editing files. The agents interact with the substrate as plain files, reading, writing and moving them through pipelines. In other words the human gets a lovely interface; the files stay boringly readable by anything.

Memory and the wiki are not the same store

One distinction to note. There's the durable shared wiki I've been describing, and separately, each runtime has its own working memory: session-derived, runtime-specific, the stuff it picks up in the course of doing a job. This comes out of the box with Claude and ChatGPT and has grown increasingly sophisticated.

There's obvious crossover. Claude encourages the creation of CLAUDE.md and other runtime and project-specific files. I do use these and will also point them at the substrate.

The bit that isn't solved

A single shared substrate is lovely until more than one agent is writing to it at once, and RafeOS has more than one runtime. How separate agents share this memory without colliding is a real problem, but it's a runtime problem, not a knowledge-layer one, so I've made that argument where it belongs in the harness post rather than re-running it here. For the knowledge layer, the point stands: curate it, graduate into it, get the maintenance honest, and keep it in a format that will still open in ten years.

This post was drafted with Claude and edited by me — which is also, more or less, how the substrate it describes gets written.

---

# AI-powered briefings
_https://rafeblandford.com/rafeos-ai-powered-briefing/ · 2026-06-25_

Most of what I've written about RafeOS so far is modules. Each is useful on its own, but I wanted something that offered a summary and a cross-cutting opinion, and let me play around with the AI-powered synthesis.

Daily briefing

The briefing was the answer to that. It's the layer that reads everything else and brings me the handful of things that matter. I get sent it once a day via messaging, it's always present in Cockpit, and I can request it from the CLI too.

The AI bit, and what it's trying to do

The daily briefing is short. A few lines of what's happening, what's needed, and what's moving. The first part is an AI-powered summary (probabilistic) that regenerates four to six times through the day and focuses on decisions. The second part is rules-powered (deterministic) that regenerates in real time and focuses on awareness. Both read from a lot of the system at once: calendar, tasks, messaging, weather, transport, health and so on.

The AI-powered daily briefing is a well-established pattern, but everyone has a different version. I want the briefing to make a decision and tell me the answer. Not "there's rain forecast and you have a meeting in town"; rather "take a jacket, leave fifteen minutes early, the line you'd normally use has delays".

It doesn't always land that cleanly. The prompt that generates the prose is something I'm still tuning. Sometimes it over-explains, sometimes it hedges, sometimes it tells me three things when one would do. Getting a model to be decisive without being recklessly confident is harder than it sounds. But the direction is right.

The rules-based bit

At the bottom of every briefing sits a short, fixed-shape status block: roughly the four things to do today and the four things to know. It's assembled by ordinary code from tools already in place, pulling the top tasks, the messages awaiting a reply, the calendar's next commitments, anything flagged as out of the ordinary. Each item is a deep link straight into the right RafeOS module, so if I want the detail on one of them I'm one tap away.

It's a good example of knowing when not to use AI. That said, it works, and can be somewhat opinionated, because the modules underneath are doing classification and inference using AI.

The added benefit is a briefing that degrades gracefully. Even if the model half of it is having an off day, or I've broken the prompt while tuning it, the bottom block is still correct, still useful, still there. I see this as right tool for the right job, but it's probably also a personal reaction against AI-ing everything.

The weekly health briefing

The daily briefing is a glance, but it's necessarily relatively shallow. I wanted to explore what AI might be able to do in a longer and more reflective format, something meant to be sat with rather than skimmed.

The weekly health briefing is effectively a cached reply to a set of questions I haven't asked yet.

Like the daily briefing, the shape is fairly fixed: an overall summary, then last week with its short-term trends, then the longer view across one to three months (is VO2 max creeping up, where's the body-mass line going), then correlated factors where it tries to join things up across the different health sources. It deliberately finishes on a single nudge. One thing to try this week. For example, a recent one noticed I've been doom-scrolling far too late into the evening and suggested a hard screen-off at half nine.

It's entirely AI-generated off a single prompt, which describes the desired format, has multiple instructions, and includes the "raw" health data. The primary source is RafeOS' unified health data, but it does use some of the other modules too for wider context (e.g. looking ahead using the calendar). Because there's more reasoning involved it currently uses Sonnet (contrasting with use of Haiku elsewhere).

The thing that makes it feel smooth to use is that it's already there when I want it. Asking a model to look across that much health data and reason about it properly takes a real moment, up to 30 seconds. So it's generated in the background once a week, which also keeps costs reasonable.

Keeping it honest

A lot of what the daily briefing tells me is, frankly, common sense. Take a jacket. You slept badly the week you were drinking more. Dressed up as a personalised intelligence brief, common sense can start to feel grander than it is, and I've pulled it back since the earlier versions (living with it, you soon work out what's useful and what's not).

I've been quietly fascinated by the health briefing. I like the weekly format... a deliberate slow down in daily quantified self obsession, but I'm also aware of the limitations here and I would draw a distinction between health measurement and health actions.

But the defence for both daily and health briefings is that presentation and timing matter too. I feel like I'm getting relevant information, plus some useful synthesis... and it does shape in-the-moment decisions and provides useful nudges. What it doesn't do, yet, is shape things much beyond that.

If you want the wider argument for why the meta-layer beats the modules, it's described more thoroughly and runs through what RafeOS is and why I'm building it.

On how this was made: the briefing is part of RafeOS, which is built collaboratively with AI; this post was also drafted with Claude and edited by me.

---

# An attention layer, not a feed
_https://rafeblandford.com/rafeos-reading-attention/ · 2026-06-24_

Note: the Reading module of RafeOS is one of the first things I built and one of the least finished, so this is as much about the open questions as the answers.

Every feed I've ever used has the same conflict of interest baked in. It aims to keep you scrolling, generally optimising for engagement and attention spent.

I see this as an incentive problem, and incentive problems are systems problems. If you want a different result, you have to change what the system optimises for, not bolt a "focus mode" onto something that's fundamentally trying to hold you.

So when I built the reading layer in RafeOS, I wanted to give it a different job. It's an attention layer, not a set of feeds: surface what's worth my attention, get rid of the noise.

What an editorial stance actually means

The closest comparison is an editor, not an algorithm. A good editor has a view. They'll tell you these five things matter today, this one's worth twenty minutes, ignore the rest. And crucially, they leave things out.

My reading layer takes the editorial stance literally. It runs once a day, early morning, and produces a digest with four sections, each doing a different job:

 * Ranked — five to seven items, scored from my own subscribed feeds. The closest thing to "here's what you should actually read today".
 * External curation — a top-N from each aggregator I trust (Techmeme, Hacker News, a couple of selected subreddits), kept deliberately scan-shaped rather than deep-read-shaped. A glance at what the wider world is talking about, not a reading list.
 * Serendipity — exactly one item, chosen to be a bit sideways. A small, deliberate dose of the thing a tight filter otherwise kills.
 * Saved — something resurfaced from my own unread queue. The article I genuinely meant to read three weeks ago, brought back before it's lost.

Each section answers a different question: what should I read, what's everyone talking about, what might surprise me, what did I promise myself I'd get to.

Underneath, the layer pulls from three kinds of source and unifies them. Miniflux handles the RSS firehose (all my subscribed feeds). External aggregation comes from Hacker News, Techmeme, Reddit, and selected newsletters. Readwise Reader holds the things I've saved to read later. All three are combined into one normalised store.

The same store drives two surfaces. The digest is the passive one: it comes to me, once a day via email. The Reading module of Cockpit is also there when I want to go and look live.

AI ranking as judgement

The Ranked section scores each item in all my subscribed feeds on several signals at once (source, topic, freshness, how much it overlaps with things I've cared about before, a few others) and orders by the combined score. This includes a Haiku-powered AI classification as well as some deterministic rules-based scoring and is what reduces 100+ daily items to fewer than 10.

The weighting of the combined score is not perfect: tuning it is ongoing, and I suspect always will be. However, doing it this way means the digest can put a thoughtful, low-traffic blog post above a high-engagement hot-take.

Where the humans are still winning

I would say the human-run newsletters still beat my digest. Techmeme, Hacker News, the better Substacks: the mix of human judgement and wisdom-of-the-crowds means the curated-by-people surfaces are ahead on both quality and experience, especially for the wide view, which is really why they get their own section.

So why build my own at all? Because I think there are two different jobs hiding under the word "reading".

One job is quick cognition and nudging: what's happening, what's worth a glance, what should float up before I head out. That's the same job my briefings and status surfaces do, and it's the job a digest is genuinely good at.

The other is deep engagement, sitting with something long enough for it to change how you think. That's a different problem, and I don't think anyone (me included) has worked out what "agentically assisted deep reading" even means yet. Pointing me at the right long thing is easy to say and hard to do well... so something to work on!

Aside: the unexpected verb

The RafeOS layer exposes a small vocabulary of verbs. reading_digest_today gives me the day's digest – it is what's described above.

reading_surface_for_topic is a bit different – it pulls together what I've been reading on a given subject (essentially a search, with strong preference given to items marked as a favourite in the ranked or curated lists or bookmarked in Readwise).

I've found it useful both when I'm about to write or talk about something (and want to know what's already shaped my view) and when I want to get back to something I know I've read. Because it's sitting on the unified store that combines RSS feeds, external curation and bookmarks, it is more useful and powerful than a search across any one of the sources.

Once again the benefits of RafeOS are most apparent when you combine things together. I ended up adding a search bar at the top of the Reading module in Cockpit because I was using it enough that I wanted it more readily available.

On how this was made: RafeOS is built collaboratively with AI, and so was this post — drafted with Claude, edited by me.

---

# Health, unified
_https://rafeblandford.com/rafeos-health-unified/ · 2026-06-23_

Oura, Withings, Apple Health and an Apple Watch don't talk to each other. Each has its own app, its own walled garden of numbers. RafeOS puts one view over all of them, makes it available to agents, and curates briefings rather than a wall of figures.

The problem is fragmentation. I wear an Oura ring, which knows about sleep, readiness, heart-rate variability and stress. I stand on a Withings scale, which knows about weight, body composition, vascular age and visceral fat. My blood pressure lives in Apple Health, recorded from a connected cuff. The Apple Watch adds richer exercise data on top. Four or five sources, each with its own app, each a perfectly good set of charts that's entirely unaware of the others. If I want to know whether a bad night's sleep, a creeping resting heart rate and a slightly off blood-pressure reading are three coincidences or one story, no single app can tell me. Each only holds a slice.

One surface over the silos

So RafeOS has a health module, and everything to do with my body comes out of it the same way regardless of where it originated. On the command line that's the health.* verb family (rafeos health summary, rafeos health readiness, rafeos health weight, and so on). I don't have to remember which vendor owns which metric. I ask the system about my health; it knows that readiness comes from Oura, weight from Withings, blood pressure and workouts from Apple Health, and I don't have to.

There are two composed views I reach for most:

 * health_summary rolls up the daily signals (readiness, sleep and activity) into one read. This is "how am I doing today, broadly".
 * health_body_metrics_summary rolls up the slower-moving ones: weight, body composition and the cardiovascular markers. This is "how are the longer trends looking".

Underneath those sit the raw primitives, one per upstream metric, mirroring each vendor's data fairly closely. The composed views answer the obvious question in one call; the primitives are there for when I (or an agent) want to dig into a specific thread. That split, a few opinionated summaries on top with faithful raw data underneath, runs all the way through RafeOS. It earns its keep here especially, because "give me the picture" and "let me investigate this one number" are genuinely different jobs.

Every source, one shape

The thing that made this tractable was deciding, early, that every metric would come out in the same shape no matter where it came from. Oura's API, Withings's API and an Apple Health export behave nothing alike. But by the time anything reaches me, each metric is reduced to the same small structure: the latest value, and a little sparkline of where it's been. Readiness, weight and blood pressure are wildly different things, yet on the surface they read identically. Current figure, recent trend, done.

That consistency is quietly what makes the whole thing usable. Once every metric has the same handle on it, I stop thinking in terms of "the Oura number" and "the Withings number" and start thinking in terms of my numbers. The vendor boundary, an accident of which company made which device, disappears from how I experience the data.

The interpretation is the value

Pulling several services into one screen is integration. Useful, but fairly ordinary; plenty of dashboards aggregate. The bit no single vendor app can do is read across the services and tell me something. Oura can interpret Oura. Withings can interpret Withings. Neither can tell me the three are one story.

The connections it has actually surfaced for me are, I'll admit, mostly common sense once they're in front of you. But I hadn't joined them up myself. That how well I sleep tracks with my blood pressure. More recently, that late-night screen use shows up in the next night's sleep. Seeing the line drawn is what nudges the behaviour.

This is the pattern I keep coming back to across RafeOS: the value is in the things that combine. Any one metric is a number. The cross-service read (does this collection of signals add up to a story, and if so which one) is the part worth noting. Nowhere else puts sleep, weight, activity, readiness, blood pressure and my digital-wellbeing score in a single view. The integration is the cost of entry; the convergence is the point.

The weekly briefing is the real win

I don't sit and run rafeos health summary every morning. The daily "shape of the day" briefing I've written about elsewhere ([#]) folds a sensible line about how I'm doing into the wider narrative: if readiness is low it might suggest an easier day, if things are steady it stays quiet. But the part I'd point to as the genuine win is a separate, weekly health briefing.

It's longer, more considered, and meant to be read rather than glanced at. The shape is fairly fixed. An overall summary, then last week (what happened, with the short-term trends), then the longer view across roughly one to three months (is VO2 max creeping up, where's the body-mass trend going), then correlated factors: the cross-service reads, some obvious, some less so, of the "higher screen minutes track with lower sleep" variety. It looks ahead using the calendar, so if there's a heavier day coming it might suggest banking some rest beforehand. And it finishes on a single nudge, not a list of them. One thing to try this week.

What makes it work is that it's generated in the background. Asking a model to look across this much data and reason about it takes a real moment, anything from a couple of seconds to half a minute, and the health view is the slow one because it reaches across the most sources. Generating it ahead of time means the answer is simply there when I want it, a pre-computed reply to "give me a weekly health brief" waiting rather than spinning.

I'd stress this is still experimental. A lot of what it surfaces is common sense, and dressed up as a weekly read it could easily tip into self-importance. But common sense I'm actually shown, in context, has shifted my behaviour in a way the same fact buried in one of four apps never did.

When it's confidently wrong

An interpretation that's wrong is worse than none at all, and large language models are very good at being wrong with total confidence. Early on, mine welded a blood-pressure reading to an unrelated ENT appointment and produced calm, plausible, nonsensical advice from the two.

There's a recurring shape to it: the model likes to group things together. It will see two event types near each other in the calendar and assume one is preparation for the other, or take two readings and infer a relationship that isn't there.

The fix wasn't a cleverer model. It was the same discipline I use when writing code with these tools: put the lessons in place. The conventions, the rules about what it may and may not connect, live in the equivalent of a system prompt or CLAUDE.md file. It can mention a health signal, it can mention an appointment, it may not causally join the two. Reliability comes not from trusting the model more but from drawing firm lines around where it's allowed to improvise.

Has it changed anything I do?

Honestly, yes. Modestly, and in ways I can point to. I take more measurements, because the system reminds me when one's gone stale. The progress charts, weight and body composition moving over months, turned out to be a real motivator. And when I sat down with my GP about my blood pressure, having cross-source data, I could show, very quickly, what had happened and that things had stabilised. A small thing, but the kind of small thing that's genuinely useful and needs no AI cleverness at all. Just the data, consolidated, in one place.

The bit I didn't expect to value is the permission to rest. The nudging cuts both ways: it will suggest some exercise, but it will also say "it's fine, you don't need to today." Being told you've earned a rest day, with the readiness data behind it, is as useful as being told to move. Possibly more, because I'm worse at giving myself that permission than I am at finding reasons to push. A lot of that rest intelligence is really coming from Oura, to be fair, not RafeOS. The system's job is to put it in front of me at the right moment.

Which leads to the tension I haven't resolved: helpful versus nagging. Most of the nudging is deliberately passive. The view shows a measurement's gone stale, or a number hasn't been logged in a while, and leaves it at that. It doesn't interrupt. I'm introducing the more active, notify-me-now kind slowly, because the line between a useful prompt and one more thing buzzing at you is thin, and I'd rather err on the quiet side. I'm also not duplicating notifications other things handle well; Apple Health already nags me about some of this, and a second nag adds nothing. What's helpful and what's nagging is, genuinely, still an open question.

What it deliberately leaves alone

A note on restraint, because it would be easy to keep building here and shouldn't. RafeOS doesn't try to out-analyse Oura on sleep, replace Apple Health's history, or recreate Withings's body-composition trends. Those apps are good at the deep dive, and there's no sense in rebuilding them worse. The job RafeOS does is the one none of them can: the unified glance, the cross-service read, and feeding that read into the briefing so it shows up where I'll actually see it. For anything beyond that, the answer is a link out to the native app. Knowing what not to build is most of the skill.

And the line I won't cross: this is a consolidation-and-nudging tool, not a medical one. It won't be as good as a specialised health assistant, and I'm wary of trusting it for anything genuinely health-critical. It's very good at showing me that I haven't weighed myself in a week, or that two trends seem to move together. It's not the thing I'd ask whether a symptom matters. That's what the GP is for, and the most useful thing the system did on that front was hand me a clean history to take to the GP, not to play one.

On how this was made: the health module is part of RafeOS, which is built collaboratively with AI; this post was also drafted collaboratively with Claude. The figures named in the text are illustrative; the dashboard screenshot is my own data.

---

# An agentic hybrid to-do list
_https://rafeblandford.com/rafeos-agentic-tasks/ · 2026-06-23_

Every to-do system I've ever used has the same quiet defect: it accuses you. Open it after a busy week and there's the backlog, sitting there like an unpaid bill. The tool was meant to help, and instead it became one more thing to manage (capture the item, triage it, file it under the right project, remember to look at it, feel slightly bad about the eleven things you didn't get to). Most "productivity" software is, in the end, admin about admin.

I wanted to find out what happened if I stopped treating the to-do list as something only I write to.

In RafeOS, tasks aren't my private list. They're a shared store that multiple agents and I all write to, and every change is recorded with the name of whoever (or whatever) made it. The list keeps itself mostly up to date. I keep the judgement, and I'm experimenting with where the agents have to ask before any of it sticks.

Of everything I've built into RafeOS, the task store surprised me most by how central it became. It's probably the purest hybrid human-agentic tool in the whole system: genuinely written to and read by both me and the agents, with neither side owning it. I suspect that's partly because it was the second version of the idea. I started with a plain Markdown file doing the same job, hit its limits, and rebuilt it properly. It's still a glorified list of checkboxes, but I'm rather fond of it.

One store, many writers

Most to-do apps assume tasks come from one place: you, typing. That's the assumption I wanted to drop, so I designed the store wider than any single source from day one. It's fed from several directions at once:

 * Instructions and skills make it easy to automatically review, create, add status update notes, or mark a task as complete when working with an agentic harness (mainly through instructions, reinforced with end-session or skills)
 * Weekly review habit can spot an appointment, a message, or a document that implies a commitment, and suggest creating tasks (for me a quick voice follow-up on a Claude Cowork scheduled task, equivalent to an EA briefing, has been particularly powerful... and is starting to nag me about stuff I haven't done).
 * Briefing follow-ups enable status alerts and inferred information to be turned into a specific task (lowering the friction for creation of status-derived tasks).
 * Manual capture from any surface I happen to be at: the command line, a chat window, my phone (good for normal life and real-world tasks).

A task carries a source tag so I always know where it came from: source=messaging, source=briefing, source=health, source=manual. When I capture something myself it looks like this:

rafeos tasks add "chase consulting invoice" --domain finance --priority high

Nothing exotic. The point isn't that command; it's that the same store is just as reachable by an agent triaging my messages at 7am as it is by me at the keyboard. The list stops being a thing I maintain and becomes a thing that maintains itself, with me as one contributor among several.

A real lifecycle, not a checkbox

A checkbox is too thin to let an agent do anything useful. If the only states are "done" and "not done", an agent can't safely move a task along, because there's nowhere to move it to that means "I've parked this until Thursday" rather than "I dropped it".

So tasks have an actual lifecycle. Every task gets a status: inbox for newly captured and not yet triaged, active for in play, snoozed for not-now-but-not-gone, done, and dropped for the honest "this isn't happening" pile. Each task also has a priority, a rough size, and a domain (finance, home, health, work, and so on). Notes are append-only: you add to the history, you don't quietly overwrite it.

Listing and updating look like you'd expect:

rafeos tasks list --focus today
rafeos tasks update 14 --status done

That richness is what makes agentic handling possible. An agent triaging the inbox can promote a task to active, set a sensible priority, or snooze something that's clearly for next month. All legitimate moves within a model that has room for nuance. A checkbox would force everything into a binary that doesn't match how work actually behaves.

Where the agents earn their keep, and where they don't

The agents are strongest on the computer-shaped work. When I'm building something in RafeOS with Claude Code or Codex (a new module, a refactor, a bug) tasks get created and closed almost without me thinking about it; it's similar with knowledge or document work with Claude Cowork. The work and the record of the work happen in the same place, so the agent that did the thing also files that it's done, with a contextual note about what changed and why (it also ties into session logs, which are cross referenced and have additional detail). Going back later and finding it all recorded, with those notes attached, is genuinely useful. That's the case where I most happily let go.

Real-world tasks are different. When I needed to get an electrician in, I talked it through with an agent, had it write the scope into a short brief and update that brief as things firmed up, and eventually close it off. But I was steering throughout. The pattern I keep noticing is that the digital, check-it-off tasks are the ones agents own, and the physical-world ones are the ones I still drive. The system has settled into respecting that on its own, but I can sense the barriers moving as more things come into the system’s purview.

The importance of the audit log

Here's the part that turns "an agent is editing my to-do list" from unsettling into useful.

Every change to a task (every status move, every priority bump, every note) is written to an audit log, with attribution. So when I open a task I can see not just where it stands but how it got there, and who did each step: me from the command line, the briefing orchestrator, the messaging triage. If an agent moved something, the log tells me why it moved.

That trail is doing the heavy lifting. Without it, handing over the routine moves would be slightly spooky: things shuffling around my list while I'm not watching, no way to interrogate the change. With it, the automation is just delegation I can audit. If an agent gets it wrong, I can see exactly what it did and reverse it. The log is what lets me relax my grip.

The session-end checkpoint

When I've been working in a harness a customised session-end skill includes a step that summarises what it wants to do to the task store and asks me to approve it. New tasks it thinks should exist, things it reckons are done, items it wants to snooze or drop: it lays them out and waits. Most of the time I just say yes, because most of the time it's right.

The failure mode this guards against isn't the dramatic one. The agents almost never get a task badly wrong. What they do, left to their own enthusiasm, is create too many of them. Because I keep tasks fairly high-level (closer to reminders than to a micro-managed checklist), that over-eagerness is the thing I'm still tweaking.

What "mine" looks like at a glance

The flip side of letting agents do most of the moving is that I need to see, instantly, the slice that's genuinely mine to act on. That's what --focus today is for: a short, human-sized view of what needs me, not the full churn of everything captured, triaged and snoozed in the background.

The whole arrangement only works because the at-a-glance "what's mine" list stays honest and short. If it bloated, I'd be back to a to-do list that accuses me, just with extra steps. Keeping it lean is the real job and I'd say this is still a work in progress.

How the trust actually built

The tidy version of this story would be a single moment where I stopped checking and started trusting. That isn't what happened.

What shifted, slowly, is that I now leave the agents to create and close the appropriate tasks and do far less of the ticking-off myself, particularly on the engineering side, where it just works.

I have also changed the shape of things to fit how much I trusted it. The bigger, chunkier commitments live in the task store; the more granular items moved into plain backlog.md in the project folder.

Why I built the engine rather than buying one

Unlike a lot of other RafeOS modules there's not an app under Tasks. The engine is a handful of Python scripts and a single SQLite file. Not using something like Todoist or Things cuts against the grain.

A task store is commodity functionality; there's nothing in mine that a hundred apps don't already do better in their UI. However, I built it for two reasons. First, portability: it's a single file I own outright, scriptable from anything, with no service to be at the mercy of. Second, and more important, the integration is the value, not the engine. What matters isn't how tasks are stored; it's that everything else in the system (messaging, the briefing, health, home) can write to the same store, and that every write is attributed and runs past the same checkpoint. You can't easily get that coherence by bolting onto someone else's product. The commodity bit is the to-do list. The valuable bit is that it's wired into everything.

The limits

This isn't finished, as the above commentary should make obvious. I'm still not sure how much of life genuinely belongs in a task list at all, and I'm recording less of it than I once did.

But the core of it holds up in daily use. Most of my task admin now happens through agents rather than my own typing, the bit that needs a human stays small and visible, which is what feels different. After years of to-do lists that quietly made me feel behind, that's the first one that feels like it's working for me rather than the other way round.

On how this was made: the task store is part of RafeOS, which is built collaboratively with AI — and this post was also drafted with Claude and edited by me.

---

# The messaging layer
_https://rafeblandford.com/rafeos-messaging-layer/ · 2026-06-22_

My conversations were scattered across three apps I don't control. Bringing them into one private store I do control turned out to be the easy half. Teaching an agent to be useful with them was the hard half.

A note on privacy first, because it shapes everything here. My conversations are about as personal as my data gets, and the whole point of this layer is that they're mine: mine to keep, mine to query, and mine to decide what to do with. So the examples in the prose are kept representative, and the one screenshot below is a real but deliberately thin slice of my own "owed a response" inbox.

The itch was simple enough. Could I give my agentic layer context from my email and messaging? And could I get it to help with prioritisation (a human failing is that I'm not very good at replying to messages).

My personal email lives (mostly) in Gmail, on a Google Workspace setup. It's also where my personal calendar lives. My everyday messaging conversations live in WhatsApp, Signal and Telegram: three apps, three silos, and no way to ask a question across the lot of them.

Getting the messages flowing

For email, it was easy as there are excellent existing connectors that work in real time. That said I did end up creating a custom tool, but 90% is wrapping Google's own Workspace CLI tools, so that there is consistency across RafeOS. Gmail also does a good job of marking emails as important and its search tools let you run triaging-aligned queries (e.g. emails that have not had a response).

For messaging the plumbing is a Matrix homeserver (Conduit) with bridges into each platform, pulling everything into a local mirror. This part took a while to get stable, but what matters is the shape of what came out the other end: one store, every platform, queryable (well, not every platform, LinkedIn is pretty hostile to external integration...).

And here's what I didn't expect. Plumbing was the easy half; usefulness was the hard half. Once the messages were flowing, I had a searchable archive and a vague sense of triumph, and then I realised I had to rethink how an agent should use this. A wall of every message I'd ever received is not useful. The real design question, the one that took far longer than the bridges, was what an agent needs to be genuinely helpful here.

Three types of question

I ended up going back to the primitives of messaging and how I might satisfy the original itch in a consistent and coherent way.

So the layer is built around three modes, and an agent picks the one that fits the question being asked.

The first is the inbox triage mode: what needs my attention? This is the triage view — recent activity, weighted, with the noise pushed down. It's what feeds the morning briefing's "you've got a couple of things waiting" line. This works by looking at both the messaging store and Gmail inbox, applying some deterministic rules, and using Anthropic's Haiku to do some classifications and scoring. A second iteration added a salience layer, which is really just a simple way to boost the scoring of some contacts (family and friends) and mute others (e.g. noisy WhatsApp groups).

rafeos gmail action-needed --days 7
rafeos messaging action-needed --days 14

The single most useful thing this mode does is refloat the messages I've forgotten to reply to. I set it a window of roughly a fortnight: if something arrived in that span and I never answered, it floats back up. And it's genuinely good at it. What it catches is mundane and exactly the kind I drop: an email missed on a busy day, a bill that needed paying, a refund I'd meant to chase, a family member's suggestion we meet up while they were passing through London.

rafeos gmail awaiting-reply --days 14

The second is person-centric: what did Helen say? You point at one human and pull their recent thread, regardless of which app it arrived through. This is the mode that benefits most from the bridge existing at all, because in real life a conversation with one person hops between platforms and your memory of it doesn't. I'll ask my agent to go back through everything with one person (sometimes more than a year deep) and remind me what we last discussed before I reply. It's mostly retrieval and summary, but it changes the reply: I'm answering with the context in front of me rather than half-remembering. The small human wins are the ones I'd be embarrassed to admit I needed: a quick "remind me when their birthday is" or "what are their kids called", pulled out of a thread in seconds.

rafeos messaging people --tier favourite
rafeos messaging rooms --name 'Ewan'
rafeos messaging history --room !roomname --limit 50

The third is topic, which is plain search: find that message about the restaurant. No idea who, no idea when, just a phrase that ought to be in there somewhere. This is where full-text search earns its keep:

rafeos messaging search "deadline NOT spam"

That's FTS5 under the hood, so the boolean operators do what you'd expect (AND, OR, NOT, phrase matching). Cheap, fast, and exactly the verb an agent reaches for when it has a fragment and needs the message.

The payoff that surprised me, though, only shows up once messaging stops being a silo and joins the rest of the system. The good moments are the cross-channel ones. I'll be working through how to respond to something and realise the relevant context is scattered: part of it was a conversation with ChatGPT, part is sitting in an email thread, part is in a WhatsApp exchange. Pulling all of that together in one place, then thinking about the reply, is the thing I couldn't do before at all.

The unglamorous half that makes it honest

If I only described the three tidy modes, you'd be getting the demo, not the system. The lived version has rough edges, and the rough edges are the part worth reading, because they're where the actual work went.

 * Names are the worst of it. Messages don't always arrive labelled "Boris". They arrive as platform IDs, email addresses, and phone numbers. A raw number is no use to an agent trying to answer "what did Helen say?" Contact-name resolution (mapping the identifiers back to the humans) is unglamorous and never quite finished, but a bit of human steering and some deterministic rules do help a lot.
 * A group is not a DM. A direct message from one person and the 200th message in a busy group chat are not the same signal, and an agent that treats them alike will either spam you or miss the thing that mattered. The fix here was the salience layer that helps the inbox mode weigh them differently.
 * A search hit on its own is nearly useless. Finding the message that says "yes, 8pm works" tells you almost nothing without the question it answered. So a hit can pull the messages either side of it for context, the small thing that makes search results readable rather than cryptic. The fix here is loading in wider context and validating a search.

None of that is exciting. All of it is the difference between a thing you built once and a thing you actually use.

Read-only, on purpose

One firm line: this layer reads. It does not send. The bridges are wired up so the system can see my messages, full stop. There is currently no path by which an agent fires off a WhatsApp on my behalf.

The principle across all of RafeOS is read-everything, write-with-boundaries; messaging is the clearest case for keeping the boundary firm. But I am tempted... so maybe autonomous outbound will get its own treatment when I'm ready to think it through properly.

Email is a little different. In common with others, I am using agents to draft email responses, but for now at least, nothing goes out without my approval. For me the highest value has been getting a context-prompted start on a reply... and then redrafting or adding to it as needed. This tends to be better than the AI drafts built into the apps themselves (though I use those too).

Why ownership is the whole point

My conversations are some of the most personal data I generate, and by default they sit inside three companies' silos, searchable on their terms, queryable through their interfaces, gone if they decide so. Pulling them into a store I run doesn't make them more secure in some abstract sense, but it does unify them and make them mine to query. I can ask my own questions, in my own words, across services, with an agent that works for me and nobody else.

---

# One API, one MCP, one CLI
_https://rafeblandford.com/rafeos-one-api-mcp-cli/ · 2026-06-21_

The single biggest design decision in RafeOS I'd highlight: build the shared thing once. Today that's over a hundred tools behind one personal API and MCP, reachable from Claude, Claude Code, the command line, the Cockpit, Telegram and ChatGPT. Here's what that looks like in practice.

Every personal-automation project hits the same fork early on. You wire up your tasks. Then you want your calendar, so you wire that up too, with its own little script, its own auth, its own way of being called. Then health, then messages, then the weather. Six months in you don't have a system; you have a drawer of one-offs, each with its own token, its own URL, its own command, its own config file.

I didn't want to build RafeOS that way. There's deliberately one API, one MCP umbrella, and one CLI dispatcher. The pay-off is the thing I find most satisfying about the system now: well over a hundred tools in reach from wherever I happen to be working. Same tools, same data, many surfaces. Everything below follows from taking that one rule seriously.

The shape of it

RafeOS is a single modular service. The modules are the obvious life areas (tasks, messaging, reading, health, home, info, calendar, email, notify, screen-time) plus a briefing module that orchestrates over the rest. They all live in one application and deploy as one unit. The headline isn't the module count; it's that those modules together expose more than a hundred tools, and every one is callable from any of the six surfaces without me re-plumbing anything.

The conventions are deliberately boring, because boring is what makes them predictable for an agent. Endpoints are /v1/<module>/<verb>. The matching MCP tools are <module>_<verb>. The CLI is rafeos <module> <verb>. The verbs are a small, reused vocabulary (search, history, today, recent, list, summary, add, draft, send), so once you know how one module behaves you can mostly guess the next. rafeos tasks add "call HMRC" does what it says. So does rafeos messaging search. The agent doesn't have to learn a new grammar per module, and neither do I.

The same boring verb pattern across modules, with rafeos --help listing them.

Every mutation carries an audit attribution header, so the store records not just what changed but who changed it: human:cli, agent:briefing, and so on. That single header is what makes the automation trustworthy rather than spooky.

A new module in about a day

The clearest test of whether the shared-thing-once bet is paying off is how cheap the next module is. The most recent one I added is digital wellbeing, screen-time data rolled up into a single score I can glance at. Data collection was in place in under a day. The verbs, the audit header, the CLI dispatch and the MCP exposure all came for free, because they're conventions the whole system already follows. What was left was the bit actually specific to screen time.

Why one service and not many small ones

The reflex for anyone who's built distributed systems is to reach for microservices. Nine-or-so modules, nine-or-so services, each independently deployable; it sounds like the grown-up choice.

I deliberately didn't. For a single-user system that one person operates, microservices buy you isolation I don't need and hand me operational overhead I'd rather not carry: lots of things to deploy, lots to monitor, lots of ways for the seams to fail. A modular monolith gets me the boundary I actually want (clean module edges, shared conventions) without the tax. I'll split something out the day there's a concrete reason to, like a module that needs to scale independently or run somewhere else.

Conventions, not a framework

Here's the call that surprised people I've talked to about it. With this much repetition across modules, the obvious move is to factor it out: write a rafeos-platform-sdk that every module imports, so the patterns are enforced rather than followed by hand. I chose not to.

The conventions live in my head and in a project CLAUDE.md the agent re-reads each session, not in an abstraction. Each module follows the pattern by hand. That sounds like the naive choice, and for a team of thirty it probably would be (shared code stops thirty people drifting). But for a system built collaboratively with an agent, hand-written, slightly-repetitive code is easier to evolve than a clever shared layer.

CLI versus MCP: horses for courses

This is the one I'd most want a semi-technical reader to take away, because it cuts against the grain of how MCP sometimes gets talked about.

MCP is the fashionable answer to "how does an agent call your tools", and the easy instinct is to expose everything over it, load the connector everywhere, and call it consistent. The reason not to is cost. Loading the full RafeOS MCP surface into a Claude Code session spends a meaningful chunk of tokens per session, just to put the tool definitions in front of the model before it's done a single useful thing. In a long coding session on the system itself, that's a standing tax on every turn, for tools I might not even reach for.

So the principle I landed on is a dual setup:

 * Cowork is for more knowledge-based work, with back-and-forth thinking. MCP is the only way to get the tools in there. The RafeOS MCP is also used by Claude Chat, ChatGPT and Grok.
 * Claude Code does a lot of technical execution, so there the agent calls the same API through the rafeos CLI via Bash (which it can already shell out to) at essentially zero token overhead, with a tiny skill telling it the command vocabulary exists. The CLI is also used by Codex and OpenClaw.

So it's a case of MCP where it's appropriate, not as a universal interface. Because it's the same API underneath either way, I can make the choice per-surface without duplicating any logic, which is the whole point of building the shared thing once.

Composed views over a thin base

At a high level there are two kinds of tool that sit on each module:

 * Primitives mirror the upstream API roughly one-to-one: thin wrappers for ad-hoc exploration, for when I want the raw thing.
 * Composed views answer an actual use-case question by rolling several calls together. gmail_action_needed instead of "list threads, then filter, then check read state". health_summary instead of fetching readiness and sleep and activity separately and stitching them in my head.

Both are available on the CLI and over HTTP, but MCP exposes only the composed ones, deliberately, to keep the agent's tool-picking surface small and focused on questions worth asking rather than handing it fifty primitives to get lost in.

That pattern grew out of a pain point; the health module grew to around 25 tools, and the agent started picking badly, reaching for an expensive live call when a cheap cached read would do, or the wrong primitive entirely. The fix had two parts. First, source-tag docstrings: every tool's description opens with a tag ([STORE] for a sub-millisecond local read, [LIVE] for something that hits an upstream service, [ON-DEMAND], [PRIMITIVE]) so the agent can judge cost and latency without reading the implementation. Second, once a module passes roughly ten tools it gets a <module>_overview tool, a map the agent can consult before committing to a call.

What earns its way to self-hosted

Building everything yourself is its own failure mode, and I've tried to resist it. The default is: don't replace something that already works, especially when the cost of using them is reasonable. The Anthropic-hosted connectors and third-party MCPs I use for a couple of sources stay exactly where they are, because there's no concrete reason to reimplement them and "I'd rather own it" isn't enough on its own.

As I've written elsewhere in this series, saying no is an important discipline in itself. I will admit that building for yourself also tends to reward the opposite instinct: prototype the thing, see if it's useful, tidy it up later.

Calendar and Gmail did earn promotion to self-hosted because I wanted consistency across surfaces and greater consideration of token efficiency, given how often they were being used. Additional customisation was also a benefit, and coherence with RafeOS conventions probably pushed it over the edge.

What the one rule buys you

Strip out the specifics and there's one move underneath: build the shared, expensive thing once, keep the module edges clean, and make it agnostic about which surface — or which actor, me or an agent — is doing the calling.

It's composable architecture pointed at my own data and services, and it's the whole reason the thing feels like a system rather than a pile of scripts. Every surface is cheap because the engine was expensive exactly once; the next module costs a day because the last hundred tools already paid for the conventions. The alternative was the drawer of one-offs I started this post worried about... and that one rule is the only thing standing between the two.

On how this was made: RafeOS is built collaboratively with AI, and this post was drafted with Claude and edited by me. All part of a wider experiment.

---

# The Cockpit
_https://rafeblandford.com/rafeos-cockpit/ · 2026-06-20_

Most of RafeOS doesn't have a face. It's an API, a command-line tool, a set of small functions an agent can call. That's deliberate (the system should be reachable from wherever I happen to be thinking, and most of the time that's a chat window or a terminal, not a screen). But there's one place where I wanted a face: a single surface I can open on my phone or laptop and read in a few seconds. What's on today. How I've slept. Whether the trains are behaving. What's waiting for a reply. In my head I called it the Cockpit, and the name set the brief: instruments, at a glance, trustworthy.

A recent visit to SXSW London illustrates why this is useful for smarter decision making. I wanted to carry the minimum possible bag (a lot of walking, a long day), so the small decisions mattered: jacket or no jacket, which route in, whether to leave early. One look at the Cockpit answered all three. Weather said intermittent rain, so light jacket. The transport line had a delay on the ground, so I chose to walk (and left time to do so). None of that is clever on its own... but having it in one read, at the moment I was deciding, changed what I put in the bag and how I travelled.

Glance app, not dive

The interesting part wasn't building it; it was deciding what it should not contain, and learning that the better a summary surface presents something, the less I end up opening it.

Oura already has excellent sleep analytics. Home Assistant has dashboards I've spent real time on. So, for most modules, the Cockpit's job is narrow on purpose: surface the summary and the key signal, then get out of the way and link out for depth (Tasks and Read are kind of exceptions here, but that's because more complete versions of them live in Cockpit).

So, I think of it as a meta-container app. Each module is a thin window onto something that lives properly elsewhere. The skill is choosing what's worth pulling forward into the glance and what's better left one or two taps away.

And a second big part of this is using AI (or agents if you prefer) to help with choosing the content or status that is pulled forward. The messaging module unifies and triages incoming comms (and flags things that need a reply), the tasks module is co-owned with agents, and there's time-of-day and context intelligence baked in too.

The thing I actually look at

The stats tell me that the individual modules I use most are tasks, messaging and health, partly because those are the most mature and partly because they drive a lot of daily life activity. But the thing I look at most isn't a specific module, it's the cross-module today screen with its AI-created briefing and summary glance cards.

The daily briefing is a very short summary of what's happening, regenerated four to six times through the day. It synthesises across several channels and tries to make decisions for me rather than just listing things (I'm still tweaking the prompt that generates it). Under it sits the part I'm most pleased with, done deterministically with tools already in place rather than asking a model anything: a status line of things to do today and things to know, each one a deep link into the right RafeOS module if I want the detail. The essential stuff sits at the very top of the screen and I never have to scroll for it.

The pattern matters more than the feature. A good briefing is the reason you open the other things less. The weather glance card is a small example. I rarely go into the full weather view now, because the briefing already tells me whether I need a jacket. One line, and I don't look anything up. Better presentation upstream means less navigation downstream, and that turned out to be the single most useful thing the whole surface does.

It's all still experimental. But the principle is set – the meta-layer that filters for you is worth more than any individual module behind it.

Internalise where the value is in combination

So when does something earn a place inside the Cockpit rather than a link out? The rule I settled on: internalise where the value is in the combination, link out where a single native app is already good.

Health is the clearest case. No single app I own combines my Oura readiness with my Withings weight trend and my blood pressure into one read, because no vendor has a reason to. That combination only exists in RafeOS, so it belongs inside the Cockpit and, as a result, is deeper than other modules. The same logic gave me the composite "today" view: briefing + compact cards, none of which is that interesting alone but which together tell me the shape of the day.

Just another client of the same API

Here's where the wider RafeOS architecture pays off, and the part I'm quietly pleased with. The Cockpit isn't a special thing with privileged access to RafeOS. It's just another client of the same API every other surface uses, the same endpoints the command line and the agents call. Each module in the UI is a thin layer over one API endpoint, almost nothing else. The module, generally, doesn't compute anything clever; the cleverness lives in the API, where every surface gets it for free.

Cockpit is a Next.js app (App Router), installable on Mac, iPad and iPhone, served at cockpit.rafeblandford.com. The one engineering detail worth calling out: the TypeScript types the UI is built against are generated from the API's OpenAPI description. The UI literally can't drift from the backend, because the shapes it's allowed to use come from the backend. That's been helpful during the rapid iteration phase and has, I think, helped with the agentic engineering.

Modules that keep themselves fresh

The bit I find most satisfying is underneath the glance entirely. Rather than the Cockpit hammering everything on a fixed timer, each module keeps its own data fresh on a schedule that's aware of context. The Tube status refreshes regularly during rush hour, backs right off on a day I'm out of office, and the weather pulls faster when there's a warning in force. The freshness matches how much I'm likely to care, which saves a lot of pointless polling.

The part that made the composable architecture feel worth the discipline is that the modules consult each other. The transport refresh checks the calendar before deciding how hard to work. A module asking another module a question, to decide how to behave, is exactly the kind of cross-domain joining-up I built the whole thing to get. The Cockpit just gets to display the result.

Real-time only where it earns it

The temptation with a dashboard is to make everything live, streaming, always-current. I didn't. Most cards and modules simply refresh when the app loads or comes back into focus, which is exactly when I'm looking at them and never otherwise. Spending a persistent connection to keep a sleep score "live" would be effort for a number that changes once a day.

Two places earn the streaming: messaging, and chatting with the agent. Both are conversational, both want updates to land as they happen, and for those I use server-sent events rather than full WebSockets. The principle, which I'd apply anywhere: add real-time when something actually needs it, not before, and use the lightest mechanism that does the job.

The module I barely open (and why that's fine)

The clearest proof of the "presentation means less navigation" idea is a module I'm genuinely proud of and almost never open: the transport card. I spent real time on it: the Tube lines I actually care about, departures from nearby stations, trains and buses, a personalised London view that lets me time a bus or decide between a fifteen-minute Tube and walking to a different station to dodge a bad line. It's good. And I don't use it as much as I thought I would, because the one thing I'd open it for (a disruption) now floats up to the briefing before I'd ever think to look.

I don't go to transport unless there's a problem, I've been alerted to one, or I've already made the decision. The card didn't fail. The briefing made it redundant for the most common case, which is a strange kind of success.

Home is the module I open least, and that one's honest too. I already have a mature, heavily personalised Home Assistant setup with its own dashboards; I'm not going to out-build that inside a glance. Where the Home module earns its keep is exactly the exception case: telling me when something's out of the ordinary. That's the whole principle in miniature. Do the routine automatically, alert me only on the thing I actually need to act on. The dashboards I built to show state matter less than the system quietly deciding what's worth interrupting me for.

Where it is

Cockpit is useful... and unfinished. The briefing, messaging and tasks are the ones I open daily. Some modules are still placeholders waiting for the right signal to surface, and a couple I built well and now rarely touch. It does the core job (I can read the shape of things in a few seconds and decide whether to dig), and that was the whole point.

In some ways an app surface feels a bit traditional, especially compared to the rest of RafeOS, but there are some things I want to push. The surface I'm most curious about next isn't a phone or a laptop at all. I like the idea of e-ink displays: something to glance at in passing, the briefing or a health trend sitting there without me reaching for a device. A dashboard you don't have to open is the logical end of everything above.

From a glance to a conversation

Aside from e-ink, the other thing I'm prototyping, almost pushing in an opposite direction, is a more dynamic link into an AI harness to make a query or have a conversation. Right now the Cockpit is (mostly) read-only: it shows me the shape of things and then links out for depth and action. The bit I keep wanting is to ask from inside the health card and say “why's my readiness low this week?”, or at a message and say “draft a reply”... and then I want to see how much of this could be delegated or automatic.

So I'm testing an “ask anywhere” affordance: an AI query with the right context already loaded, and a seamless step from the glance into one-shot response, a quick conversation, or a full agentic job (I need to work out the best place for these to happen; I suspect, like the messaging use cases they are different paths). It's early, with experimental wiring, but the idea is to continue to iterate the agentic layer and move from smarter decisions to smarter actions.

On how this was made: Cockpit and RafeOS are built collaboratively with AI, and so was this post. Drafted with Claude, edited, and, in this case, written mostly by me.

---

# What is RafeOS?
_https://rafeblandford.com/what-is-rafeos/ · 2026-06-19_

I've written about why I built RafeOS: the thinking, the two questions I'm chasing, and what it's taught me. This post is the other half, and a more practical one. People keep asking the reasonable follow-up: yes, but what actually is it? So here it is, laid out in parts.

The short version: RafeOS is three things — a platform holding the tools and services that read and act on my data, a knowledge layer – the data and context the platform draws on, and a set of surfaces – the different ways I reach and interact with the platform and the knowledge. The caveat: I also tend to use it interchangeable to refer to my wider AI/agentic and self-hosted set up too.

So perhaps it's most accurate to say RafeOS is an ecosystem, combining what I built what I borrowed to create an agentic-first layer to help run my life.

The shape

The architecture (below) reads as the three things above: how I reach it, the platform itself, the data and context it draws on, and the borrowed foundations underneath. Solid is what I built; dashed is borrowed.

How it acts

The behaviour (below) is a flow: something triggers a response, it's handled with as much or as little autonomy as the job needs, and it has effects.

Three things can set it going: me (asking, glancing, replying), an agent (delegating to a sub-agent, handing off, or cross-checking one AI against another), or a loop or event (a schedule, a webhook).

Whatever fires it, the request is handled with only as much autonomy as it needs — from a plain passthrough that just shows data, through deterministic automation and fixed workflows, up to a full agent handed a goal that works out its own steps.

Then it has effects: read, respond, use a tool, create something, notify me, or act on something in the world — with a firm gate on anything outbound (messages to other people, real-world actions, anything touching money or secrets). The same platform runs human-only, as a hybrid of me and an agent, or fully autonomously. The human account of what that's actually like to live with is in the agentic-edge post.

How I reach it

There are multiple surfaces I use to reach RafeOS. Each suits a different moment and use case. It is the obvious expression of a deliberately interface agnostic intent.

Here's a quick run through:

App

Cockpit (a progressive web app, installed on Mac, iPad and iPhone) for the at-a-glance view: the day's shape, health, messages owed a reply, transport, home; and for human-first actions. It surfaces a summary and links out for depth rather than rebuilding the things it sits on.

CLI

rafeos command line for text based interaction from quick summary to quick capture (rafeos tasks add "…"). This is a quick-query interaction and is most useful when I'm already working in terminal.

Agentic chat

Through an MCP connector, a normal chat window — Claude, ChatGPT, Grok, and experimental local models via Ollama can reach the same tools. This is the quick-query door, especially useful on the go, with a pleasant UX and AI smarts.

Agentic harnesses

Claude Code, Claude Cowork and OpenClaw: the places I actually work. This is where the building and the heavier, longer-running jobs happen, the agent calling the tools directly as it goes (including work on RafeOS itself). This is the surface I use most.

Messaging

Signal, Telegram and WhatsApp: two-way, and a good way to reach me on the go or for when I'm away from a bigger screen. A scheduled briefing arrives as a message; I can ask something back.

The platform

At the centre is the thing I actually built: the platform (the engine, if you like). One modular service, rafeos-api, with a matching MCP umbrella (rafeos-mcp) and the rafeos CLI, plus a set of skills — packaged know-how an agent can invoke. Alongside my own tools sit connectors to third-party ones (the Anthropic-hosted tools, Home Assistant, other MCPs): borrowed, but reached the same way.

Between them the modules expose well over a hundred small tools, each doing one readable thing. The commands follow a deliberately boring pattern, so once you've seen one you can guess the next:

rafeos tasks add "call HMRC"
rafeos messaging search "restaurant booking"
rafeos health summary
rafeos transport tube-status

One detail worth calling out: every change is attributed — the store records whether it was me or an agent that made it. That's a small thing that does a lot of work; it's what makes heavy automation trustworthy rather than spooky. The architecture post (One API, one MCP, one CLI) covers why it's built this way; here the point is just that there's one platform, and everything else leans on it.

The modules are the obvious slices of life (with more being added).

 * Tasks — a to-do store several agents and I all write to, with most of the admin handled automatically (deep dive).
 * Gmail and Calendar — access to email and schedule, plus some wider services
 * Messaging — WhatsApp, Signal and Telegram bridged into one private, searchable archive I own (deep dive).
 * Reading — a daily digest built to surface what's worth my attention and suppress the rest (deep dive).
 * Health — Oura, Withings and Apple Health unified into one view, with an interpretation, not just numbers (deep dive).
 * Home — Connections to Home Assistant, Octopus, and other smart-home tools.
 * ...and Briefing – AI and rules powered briefing that is composed using the modules above (deep dive).

Data & context

A platform is only as good as what it knows, and RafeOS draws on two kinds of thing — the line between them being who owns it.

What it owns. The substrate is plain markdown — the system's written record: knowledge, project state and decisions, session logs, the context files the agents read. The agents write to it directly or through pipelines; when needed I edit it by hand in Typora or Obsidian; Git syncs it across machines (there's a whole post on the substrate). Then there are also small SQLite databases for tasks, reading, health and messaging for more structured data.

What it pulls live. Everything else is borrowed data, fetched on demand and grouped roughly: productivity (email, calendar, files, CRM); home and environment (Home Assistant, screen time, the electricity tariff, weather); health (Oura, Withings, Apple Health); and reading and the odd extras. There are some local caches for performance and costs reasons too.

The memory inside ChatGPT and Claude is relevant here too, but it is gated or siloed to those services.

Foundations

None of this would exist without a lot of borrowed foundations.

Underneath sits a stack of self-hosted, open-source services — the Matrix server and bridges that carry the messages, the Miniflux RSS reader, Home Assistant, the metrics tools — all running on my own hardware across a few machines on a private network.

Similarly, the AI models are Anthropic's, OpenAI's, xAI’s, and experimental local ones via Ollama. The agentic harnesses are other people's software and they are what made this possible.

RafeOS also uses a number of public APIs for things like transport information, energy status and rates, weather conditions and forecasts, and more. This is one of the things that gives richer meta information that makes smart decision-making possible

What ties it together

If I had to keep one thing, it would the principle of having shared context (the substrate) and shared tools (and services) that can be then used across any number of surfaces and interactions.

You can probably see one facet of this in the briefing. It owns no data of its own; it reads all the other modules and tells me what they add up to: a short morning read-out of what's on, what needs me, and what's merely worth knowing, with the genuinely urgent floated to the top. It's the clearest expression of the whole system's goal - not more dashboards to check, but the right things brought to me.

But what's really changing the way I work (and to some extent live) is having this context and shared tools available in the agentic harnesses, whether that's Claude or Codex, because it gets me much closer to that promise of an always-on AI assistance that feels part magical and part inevitable next step in the progress of tech.

...and of course, it's under constant evolution. RafeOS is very much an alpha product, helping me explore my own personal agentic ecosystem, so I'll share more as I go!

---

# Why I built a personal operating system
_https://rafeblandford.com/rafeos-why-i-built-personal-os/ · 2026-06-18_

If you've read the About page, you'll have seen the line about building "a personal operating system, to find out" what AI changes for products, teams and the way we work. This is the longer version of that sentence.

I call it RafeOS. The name is a bit grand for what it is, but it makes people smile. Underneath, it's one platform, best described as agentic-first, that reads and (carefully) acts on my own data: tasks, calendar and email, health, messages, reading, the flat (home), and various information statuses (transport, weather). I tend to think in layers, so the whole thing is RafeOS but it divides cleanly into parts of an ecosystem, the modules sitting behind one API, one set of small tools, one command-line dispatcher, and so on. I can reach the same system from my laptop, my phone, a chat window, or an agent running on a server.

The shape of it: how I reach it, the platform, the data it draws on, and the borrowed foundations underneath. Fuller tour in What RafeOS is.

Two reasons I keep building it

The first is that I wanted to understand the agentic edge from the inside, not from the demos. Much of what's written about agents right now is either breathless (we're deep within the hype cycle) or dismissive. I'm more interested in the lived version: when you point capable agents at your own data and workflows, with real stakes (my actual calendar, my actual health), what genuinely changes about how you work, live and think? What's useful, what's theatre, and what quietly becomes a habit you'd miss? Living with a second brain and a deliberate agentic layer has really brought home the potential... it's a little unnerving what is and will possible... and I think I'm only scraping the surface,

The second is more about the how, or the next version of it. I've spent years doing and leading transformation, innovation, product and engineering (teams) in various guises, and I know collaborative and coexistent AI is already reshaping how software and services get built. It's not just the coding, but the whole lifecycle, from discovery (why) and requirements + use cases (what) through to the design and build, testing, and deployment (how). I wanted somewhere I could run that end-to-end myself, experimenting and trying different things, with fewer constraints. RafeOS, and its connected pieces, is that somewhere. It lets me get a different hands-on perspective on what the future of product, design, and engineering might look like.

And honestly, it's only practical now. Agentic-led or assisted work is what makes it sensible to build something for an audience of one; RafeOS wouldn't exist a couple of years ago, if I had to design and write every line myself. The what and the why are still mine. The how is increasingly the agent's, and the division across all of these is turning out to be most of the point. Critically, it also highlights the current limits and the new failure modes (and some not so new ones).

So RafeOS is two things at once: a system I genuinely use, and a lab. Most of what follows is the system. The lab is where the next few posts go.

What's actually different about it

It would be easy to call RafeOS a second brain: context and memory, a knowledge wiki, session logs, a collection of skills, all compounding as you feed them. That part is real and useful. But this is almost a commodity layer now; anyone who's used Claude Cowork, spent a fortnight with an agentic harness, or set up something like OpenClaw or Hermes, has felt it. This is still an important layer and is a huge productivity boost in itself, but I think there are two things that matter more.

The first is a consistent set of custom tools that work across every surface. Some interrogate Gmail and Google Workspace, a bit like the off-the-shelf connectors but customised. Some hook into health: Oura, Withings, Apple Health. Some I wrote from scratch, like the ones for reading and tasks. The point is they're the same tools whether I'm in a chat window, on the command line, or letting an agent loose on a job, so the data and the context follow me around instead of being trapped in whichever app I happened to open.

The second is handing classification and the small decisions to the reasoning itself. A lot of what RafeOS does is let a model do the filtering: these are the messages worth a reply, these the tasks to pay attention to, this the status that matters today. The benefit is that it decides what's worth my attention, so my attention goes to the work that actually needs me.

None of this is exotic engineering. When I say I'm building RafeOS, what I'm mostly doing is connecting things together: gluing my data and context to a model's reasoning, then choosing how it surfaces, whether that's a chat, a briefing in my inbox, or a sensible call about what to float to the top of a dashboard. I don't self-host or rebuild everything either; the dashboard deep-links straight out to existing apps I use that already do a given job well; I'll use existing services, connectors, or MCPs where it makes sense to do so; and I'm standing on the shoulders of a lot of prior art and open source software. Partly this is a reflection of the jagged frontier, but it's also that I just want something that works.

Is this all just agents? It's the obvious question, and the answer is no, which is the point. Some of what gets called an "agent" now is a markdown file that springs to life when you ask it something in Claude or ChatGPT, or when a scheduled job pokes it. RafeOS has some of that. But it's one band on a wider spectrum: from a plain passthrough (just showing the data), through automation (deterministic rules, no model), through fixed workflows (a model running a set of known steps), to genuine agents (handed a goal, working out the steps themselves). Which band a job sits in matters less than the fact they all draw on the same platform underneath: the shared tools, the memory, the audit trail. The agents are the visible bit; the platform is the personalisation and the multiplier.

There are places where I'm less advanced. I lean lighter on elaborate multi-step workflows than some do. And there are people running far more sophisticated memory than I am (proper vector databases over thousands of their own documents).

One substrate, many surfaces

The design decision I'd defend hardest is that as much as possible runs on a single substrate, reachable from wherever I happen to be thinking:

 * The Cockpit, a web app for the at-a-glance view and a traditional front end for some modules.
 * The command line, via terminal, for the fast, no-ceremony stuff. rafeos tasks add "call HMRC" and it's captured.
 * Claude Code and other agentic harnesses, via direct API and skills, calling the same tools while doing technical work, including work on the system itself.
 * Claude Cowork, via an MCP connector, when I'm working with files or knowledge projects.
 * A normal chat window, same connector, for when I just want to ask
 * Telegram, Signal or WhatsApp, so I can reach the system, and it can reach me on the go.

The point isn't the list. It's that these are all front doors onto the same context, data, and capabilities, with one way to authenticate and one record of who did what. That's a systems-thinking habit more than a technical one: build the shared thing once, then let the surfaces be cheap. Adding a new way in shouldn't mean rebuilding the engine.

Living with all those doors, I've found they do three different jobs. The app is for the glance (is everything roughly fine?) and quick human actions. The chat/agentic harness is for the deeper work (help me think this through, help me create this). The briefing and the alerts are the push, the thing that comes to me unasked, because waiting to be asked is its own kind of friction. More often than I expected, the best version of RafeOS is the one that asks the least of me. It's at its best when it's close to invisible.

This is also part of a very deliberate composable approach here: breaking the system into independent, reusable, and modular components. Things, including the foundational models, can be swapped out, but it also applies to the surfaces.

Automate, then show or alert on the exception

One habit runs through the whole system: do as much as possible automatically, and only interrupt me when something is out of the ordinary. These are a kind of loops, though perhaps not the buzzworthy kind.

I learned it most clearly from the part of my setup that predates RafeOS, the smart home. Home Assistant has run for years (lights, presence, security) and I rarely open it. Where it earns its keep is the exception: during a heatwave it nudges me to draw the curtains to keep the heat out; electricity usage is time-shifted to the cheapest rates automatically; and it reminds me if I have left the window open. The normal stays silent; the unusual surfaces. That's the same shape as the messaging triage telling me which five emails actually need me, or the briefing floating a Tube delay because it knows I'm about to head out. The goal was never more dashboards to check. It's less checking.

The jagged edge

The gap between the demo and the lived version is where the useful learning is. RafeOS is alpha. It's brilliant in places, flaky in others, and the line between the two isn't always where you'd expect. Some of that is the technology still maturing. A lot of it is me: handing an agent something you've done by hand for years is a behaviour change, and behaviour change runs on trust. You have to learn when to hand over and when to check, and the system earns that by being coherent often enough that you stop double-checking.

It gets things confidently wrong, too. Early on the briefing welded a health reading to an unrelated calendar entry and delivered the nonsense with the same calm assurance as everything useful it says. The fix wasn't a cleverer model; it was a firm rule about what it's allowed to connect and taking into account confidence levels when presenting information. Most of the engineering, it turns out, is fences.

What it deliberately doesn't do

A word on restraint, because it's so easy to skip. RafeOS has an explicit list of things it will not do: no sending messages on my behalf, no sub-task hierarchies, no multi-user anything. Every "no" has a reason written next to it. That discipline matters more as a system grows, not less. The temptation with a project like this is to make it do everything; the skill is deciding what it shouldn't touch and holding the line. Knowing what to leave out, what to remove after experimentation, is the part of this that most resembles my day-to-day job decision making.

Owning it

There's a quieter reason, too, and it's grown on me. The more of your life runs through a system like this, the more it matters who holds the data. Building my own tools, on my own infrastructure, keeps my messages, my health, my reading mine: queryable by an agent that works for me, not sitting in someone else's product to be mined, priced or discontinued. I don't self-host everything. But for the personal, sensitive core, ownership is an attractor, and that pull towards self-hosting is as much about privacy and control as anything technical.

What comes next

Building a personal project, from the ground up, has given me a real point of view on the two questions I actually care about: what the agentic edge does to the way we work, and what AI-native product building looks like across the whole lifecycle.

The next few posts go deeper: the platform decisions, the messaging layer, the self-running tasks, the health view, the Cockpit, how it decides what's worth reading, the memory it all runs on, and the two bigger arguments about agents and engineering.

And of course there's a backlog too and more experiments to run!

On how this was made: RafeOS is built collaboratively with AI, and so was this post. That feels like the honest thing to say, given the subject. Every post here carries a label for exactly this reason.

---

# A front door for people and machines
_https://rafeblandford.com/a-front-door-for-people-and-machines/ · 2026-06-18_

ChatGPT has, as of June 2026, around 1 billion people using it every month, Google's Gemini is around 700 million, and Claude is climbing fast behind them. Whatever else you think about generative AI, its adoption is the fastest of any consumer technology in history, and a large and growing share of people now ask a model rather than a search box.

So when I rebuilt this site, I made a decision that would have sounded slightly mad a couple of years ago: I designed it for two audiences. People, obviously. But also the machines that, increasingly, read the web on people's behalf.

The web has always served many audience (including bots), but we are now looking at a more deliberate bifurcated system, and it will accelerate over the next few years. Once you accept that a meaningful share of "readers" are now models, summarising and answering and citing rather than browsing, the conclusion is fairly obvious: a site has two audiences now, and they read very differently.

What's odd is the shape of the second audience. The human one is potentially billions of people. The machine one, in theory, is no more than a dozen or so frontier models. A tiny, strange readership… with enormous reach. That asymmetry is most of what makes this interesting (and "in theory" is doing some quiet work in that sentence, which I'll come back to).

Letting the machines in

The first decision is whether to let the crawlers in at all. A lot of sites are now blocking the AI bots, and for understandable reasons: if your content is your business, you don't necessarily want it ingested for free.

I went the other way and welcomed them explicitly, training crawlers included. There's some ambivalence in that, of the "you're building on my words" variety, and I suppose "making money from my work". But I don't think blocking is either pragmatic or realistic, and more to the point, I actually want my views in the training corpus. The value of an opinion, to me, is in how widely it travels. If a model has read what I think, and occasionally repeats it, that is rather the point.

Telling them who I am

Then there is helping a machine work out who is actually writing this. That is the structured-data work: schema, a connected description of me and what I've done that a machine can resolve rather than guess at.

None of this is new advice. It has been the sensible thing to do for years (I spent a fair bit of the All About Symbian archive work building exactly this kind of author authority, for a site that had long stopped publishing). But it is a useful reminder that machines read differently to us. A person reads the page; a machine reads the page, and the markup, and the links, and tries to decide whether you are a real, consistent entity worth trusting.

A map for the machines

The genuinely new bit, the unproven bit, is something called llms.txt: a plain, structured map of the site written for language models rather than browsers. A short index, plus the full text, in one place they can grab.

I'll be straight about the uncertainty. Only about one site in ten has adopted it, and the AI search crawlers mostly ignore it: in one large analysis it was fetched in roughly 0.1% of AI-bot visits, and no major lab has committed to reading it. So as a search play, it is hedging a cheap bet more than backing a sure thing.

What makes me a little more interested is a different use altogether. The tools that do already read llms.txt are the agentic ones: Cursor, Claude Code, Copilot and the like pull it when you point them at a site. That suggests its real value is not search at all, but a fast way to hand a site's live, in-the-moment context to an assistant on demand. Point your tool at a site, pull its llms.txt, and you can more or less start a conversation with it (or have it discovered) in seconds. That feels more useful, and more likely to stick.

How it's made... and saying so

The part I care about most is not really optimisation at all. It's provenance.

There is already a great deal of AI-generated content, and there is about to be far more. By late 2025, some research suggests that more than half of newly published web articles were primarily AI-generated, with "slop" being word of the year. The trust problem is worse than the volume problem: NewsGuard is now tracking over three thousand AI-generated "news" sites that publish without ever disclosing it.

So I've labelled every piece on this site by how it was made: by me, with AI, or by AI. I think that labelling matters. Collaboration with a model does not automatically mean slop.

The difference between useful and slop is human judgement and integrity, but it is a subjective and grey area.

I'd go a bit further, because this is one of the things I'm most worried about. The commercial incentives around content have never really rewarded transparency, and the last decade of the internet is a fairly bleak lesson in what happens when they don't. I don't have a neat answer. But labelling my own work transparently is at least a position, and it costs me nothing except the temptation to look cleverer than I am.

Then I set up a way to find out if it works

Most of this could be wishful thinking, so I wired up some measurement: server logs for crawler activity, referrers for the humans arriving from AI answers, and a small weekly report so I don't have to remember to look.

It is already visible, and the most interesting evidence comes not from this site but from the much longer-established All About archive. While content stopped being actively published on the All About sites some years ago, it still serves around five hundred requests a day to crawlers. Most of those are the long-established search bots (Googlebot does the heavy lifting, and these days it feeds both search results and AI overviews), but a clear and growing slice is the dedicated AI crawlers: OpenAI's, ByteDance's, and others.

The machines are sending people back. Over the last three months the archive has had visitors arriving from ChatGPT (more than 150 of them), with smaller numbers from Gemini, Perplexity, Claude and Copilot. And, of course, it's fair to note that many more consumed the content, or at least a shadow of it, within the respective AI assistant (a 1%-2% click through rate suggests there are thousands of content consumers that never reach the site).

On reflection, none of this should surprise me. The archive has two decades of authority built into it, the very defintion of domain expertise and depth.

So is this all just SEO?

Mostly, yes. I keep waiting for the new magic and mostly find old discipline: clean markup, structured data, clear writing, and being a genuine authority on something. It is really a continuation of the zero-click web (around 60% of Google searches now end without a click, rising to roughly 83% when an AI Overview appears). The answer arrives without the visit.

But the acronyms are worth untangling, because they mark a real shift. Answer engine optimisation (AEO) has actually been around a while: it is what you did to land in a Google answer box, an FAQ result, or a voice-assistant reply, which is really search compressed to a single answer. Generative engine optimisation (GEO) is the newer thing, and it is most of what I've described here: getting your content cited, and your view trusted, by the frontier models. Less ranking in ten blue links, more citations, and something like share of model and AI visibility. Much of it still comes down to two things: how you structure content, and where your authority is built. And the weight of those are changing, respectively, the shape and feel of content itself (modular, self-contained, shorter), and the importance of off-site activity (the citations and mentions elsewhere that tell a model you are worth trusting).

Looking a little further out, I suspect GEO will itself give way to something I don't yet have a tidy name for: optimising not for the models, but for the harness around them. The per-user context, the tools, and memory that increasingly sit between a person and a raw model. This is where "in theory, a dozen frontier models" stops being true. An agent's behaviour may depends less on which model is underneath and more on how its particular user has set it up. Which would be a quietly funny outcome: we might yet still end up back where we started, trying to be useful to one person, and their assistant, at a time, albeit with a very different equation making up the stack.

For now, I've built my personal web front door for both audiences, labelled my work honestly, and set up a way to watch what happens. I'll report back when the data has something to say.

---

# AI Provenance on rafeblandford.com
_https://rafeblandford.com/ai-provenance/ · 2026-06-15_

Every post here on rafeblandford.com carries a small label saying how it was made: written by me, written with AI, or AI-authored. You can see it next to the tag labels at the top of every post and on the cards on the index pages. This, or something like it, is a pattern I expect to become much more widespread across content, not just code, in the next few years.

The pragmatic classification test is simple: would this post still exist, recognisably in this form, without the AI?

Written by Rafe (Human-first)

Yes - basically unchanged. The thinking, the opinions and the words are mine. AI did mechanical things at most: a spellcheck, a “is this clear?”, or faster searching for references. The key principle: no generated prose or arguments.

Written with AI (Collaboration)

Yes - but slower or worse. The ideas, opinions, and direction are mine; AI materially shaped the words or the structure. The thinking is mine, the execution shared. In practise, for most posts in this category, there are sections that are human-written, and others that are human-reviewed.

AI-authored (AI-first)

No - it wouldn't exist. The bulk of the prose came from AI, working from my brief. I'm the editor and commissioner, not the author in the traditional sense. Most frequently, these are to document a project or a topic I've been working that I think is worthwhile sharing because others might be interested in it. Typically, these are born from things I've supplied significant context for, be it a working project, notes, or other input, so the human touch is present, it's just not primary.

🧠Why label it?
Because being transparent about how AI is used is the honest thing to do... and, increasingly, the authentic one. I work this way every day; showing it openly demonstrates the operating model rather than just describing it. The label is what makes AI-authored writing publishable here, not a constant "is this OK" and "what will people think" set of decision.

Humans, Centaurs, and Cyborgs

This pushes on the different ways of working with AI. I've found it's useful to abstract into three broad categories: human, centaur, and cyborg. I've found it helps with thinking and explaining to others... but I would acknowledge that it's more like different modes along a continuous continuum - another example of adventures along the jagged frontier of AI.

---

# Lessons in AI Adoption
_https://rafeblandford.com/lessons-in-ai-adoption/ · 2026-06-15_

As part of the UK Government's AI Champions programme an independent report AI Adoption Plan: Creative Industries was published this week. It is worth reading for the 8 recommendations as a strong articulation of an approach for accelerating AI adoption responsibly and confidently.

There's also an eye catching stat that 51% of creative businesses are using AI, with the source data indicating this is dominated by two tools (text generation/LLMs at 27.7% + visual content creation at 23.7%). However, I'd gently question measuring adoption by tool uptake at all. These figures may tell you who is experimenting, but they tell you very little about who's getting real value, and who's just moved the effort somewhere less visible.

⚠️Access to tools is still a blocker and was a dominant theme for many in 2025 (including me). This is only going to get worse as the economics of AI tokens starts to bite.

It is common to see the value-gap in the AI "false dawn" optimism generated by one-shot pilots, happy-path-only demos, and tool dumping... (or, more generally, AI for the sake of being seen doing AI). More often than not, this is driven by senior stakeholders' demands (and subsequent expectations), rather than people grounded in the pragmatic reality of the work, with predictable results. This is probably the most common failure mode right now, exemplified by messages like "we've rolled out the tools, now get on with it".

💡Experimentation, pilots, and lean methods remain the best way to accelerate AI adoption, but the intent and targeted outcome is critical. The point is not to run a pilot or to "do AI", but to learn and validate value, before scaling.

My experience has taught me that adoption isn't a clean efficiency curve. It's jagged and messy.... the hard part is almost never the model, the tool, or identifying opportunity... it is behaviour change, mindsets, and trust. Setting up for success by re-imagining a business or a process, rather than automating or bolting AI on to an existing solution, is typically the harder path (again, mainly because it's a human and ambiguity challenge, rather than a technical one), but it also generates and sustains greater value.

🌎For me this has varied by area and discipline. For example, engineering and product teams seems to understand this better because decent agile intrinsically builds adaptation and flexibility into its core through short feedback loops, continuous iteration, and empowered teams. Operational, strategic, and creative teams tend to adhere more rigidly to existing processes and frameworks. It's worthwhile to adjust the approach and expectations accordingly... and remember there is still a lot of value in simple automation.

The report acknowledges this in its challenges section and case studies. It's also refreshing to see the productivity mirage called out ("...struggle to distinguish genuine efficiency from displaced effort").

The lesson from my AI transformation work in 2025 and 2026 is that the context/knowledge/data preparation, the impact of new failure modes, allowing time for multiple iterations, legal and security bottlenecks, and a longer term view on correcting/sustaining outcomes can quietly absorb the time and costs the AI workflow was forecast to save. This is typically more apparent in the short-term (more "discovery" and "optimisation" required), so initial headline savings are over-estimated (with a knock-on effect that the long-term impact is then under-estimated). It also pushes use cases towards more operational and coherent use cases, which can also be seen in the data underlying the headline stats (see attached chart).

⚖️The biggest time-absorbers I personally saw in 2025 were legal and liability when moving from experiment to live. This was especially acute when it was deliberately ignored early on, or where there's was little provenance or observability in the use of AI. Understandably, legals teams and clients/leaders are unwilling to sign off after-the-fact, where the risk isn't clear, or where a conservative attitude is present.

Nonetheless, I have no doubt at all, that much of this is early-adopter friction, but it's great to see the conversation happening. As a transformation optimist, I find it helpful to remember Ethan Mollick's articulation that "today's AI is the worst AI you'll ever use". I also like his thesis around moving from Co-Intelligence to Co-Existence.

A version of this post was originally published on LinkedIn.

---

# Screen Time + Digital Wellbeing Score
_https://rafeblandford.com/screen-time-and-a-digital-wellbeing-score/ · 2026-06-14_

I've been building RafeOS, a personal data and tooling layer that pulls my health, calendar, mail, home and reading into one place I can query. The latest piece scratches an itch I've had for years: I spend a lot of time on screens, most of it deliberately (and it feels like it is increasing), and I wanted to know whether my digital life was actually healthy — not just how many hours the phone's Screen Time tab guilt-trips me with.

So I built a digital-wellbeing score: a single 0–100 number per day, higher = healthier, sitting next to my Oura readiness, sleep and activity scores. This is the story of how it works, and what happened when I made the model argue with the actual research literature.

The shape of the problem

Three things make "scoring screen time" harder than it looks.

First, getting honest data. Most screen-time research is built on self-report, which is badly inaccurate — people's estimates explain less than half the variance in their actual measured use. I wanted passive, measured data. On the Mac that's easily done with ActivityWatch (which app is in focus, am I actually at the keyboard); on the iPhone it's the existing Apple Screen Time (imported into ActivityWatch using an Importer.

Second, my Mac isn't always on. So the architecture pushes rather than pulls: a little job on the Mac wakes up hourly, builds a compact daily rollup from the local data, and POSTs it to the always-on server, which means there's an always available data store (and it also allows to do some post-processing). Re-sending a rolling few days is free (the ingest is idempotent), so if the Mac sleeps through a slot, the gap heals itself on the next wake.

Third, the interesting one: what should the score actually reward? That's where I stopped agentic coding and went back to the evidence.

What the research actually says (and what it doesn't)

I had an agent do a proper, sourced literature review — meta-analyses and primary studies, not wellness blogs. The findings genuinely reshaped the model. A few that mattered:

 * Total screen-time hours barely predict wellbeing. The best methodological work here found digital-technology use explains at most 0.4% of the variance in wellbeing — about the same as whether you wear glasses. The dose-response is a gentle inverted-U ("Goldilocks"), not "more is worse". So a model that makes raw hours the main axis of health is building on the weakest part of the literature.
 * Timing is the strongest, most actionable lever. Late-night use robustly associates with worse sleep (media-use ↔ sleep problems pools around r ≈ 0.28), and the mechanism is displacement and arousal: you stay up, the content keeps you alert. Blue light is the weakest leg, its interventions mostly failing to reach significance. So: penalise the late doomscroll, and don't bother with blue-light theatre.
 * Long focused sessions are healthy; fragmentation is the harm. This one flipped a contributor on its head. I'd originally penalised long unbroken sessions (a "take a break" instinct). But for a knowledge worker the attention literature says the opposite — task-switching and constant interruption are what fragments attention and raise stress; a two-hour deep-work block is the good pattern. My "breaks" penalty was punishing exactly the behaviour I want more of. It became a fragmentation penalty instead.
 * It's compulsive checking, not hours, that flags trouble. The construct with real predictive power is "problematic smartphone use" — the unlock-every-ten-minutes pattern — not total foreground time. My model had no measure of this. It became the single most evidence-aligned thing I added: pickups.
 * Exercise offsets the sedentary cost. The best causal-leaning evidence in the whole area is that moderate physical activity substantially cancels the health risk of sitting. So a day with a logged workout should forgive a lot of screen volume — which reframed "volume" from a wellbeing axis (weak) to a sedentary one (well-evidenced), gated on whether I'd moved.

And one nice adversarial catch: the viral "checking your phone within 5 minutes of waking spikes cortisol 31%" stat? It doesn't trace to any real study. The agent flagged it as unverifiable. So morning-use gets, at most, a soft nudge — not a confident penalty.

The model that fell out of that

The score starts every day at 100 and subtracts points across nine contributors, in two layers.

Five "backbone" contributors grade the day on its own terms:

 * Composition — the share of the day in social + entertainment (the "reduce" tier). Proportional, so an extra hour of coding doesn't dilute it.
 * Fragmentation — category-switching per hour; deep focus scores well.
 * Timing — off-hours use, with after-midnight weighted 3× and late work charged a quarter of late doomscrolling.
 * Volume — a sedentary signal, biting past ~8h but largely forgiven by a logged workout.
 * Bookend — how late the last screen of the night was, doubled if it was mindless content (the revenge-bedtime tail).

Four "balance" contributors then compare today to my own trailing two-week norm — volume, off-hours, composition and pickups, each vs usual. This is the part borrowed straight from Oura: its Readiness and Activity scores weight your recent baseline, precisely so the number means "good for you" rather than against some population average that was never going to fit a desk worker who's online 10 hours a day by design. Being above your usual costs points; being below earns a few back.

There's a deliberate guard against the obvious failure mode of personal baselines — drift. If I slowly creep to twelve-hour days, a purely relative score would just normalise it. So the backbone stays absolute (the 8h-ish line still bites regardless of my norm), and balance is only a lighter modifier on top. Belt and braces.

The decision I kept coming back to: today is "pending"

An interesting feature note was deciding not to score today.

It's tempting to show a live number, the way activity trackers shows progress through the day. But Oura's sleep score works because it grades something already finished — last night's sleep. Digital is the opposite: a lot of its quality signals (the late-night use, the bookend, the evening pickups, the total volume) are back-loaded in the evening. A score computed at 2pm would be systematically flattering: the bad stuff simply hasn't happened yet. And quietly showing yesterday's number labelled "today" isn't helpful.

So you'll see the day's card shows an honest "still collecting" state — your real running totals and a live composition strip, but no score — and only finalises the number once the day is complete (I run the days 4am-to-4am, like Oura, so "a day" is the span between two sleeps rather than a calendar artefact). The score freezes, and from then on everything just reads it.

Couldn't have: real iPhone pickups

A tangent worth mentioning. Mac pickups were easy — macOS quietly logs every screen wake, and you can count them. iPhone pickups, the number Apple shows you right there in Settings, turned out to be a wall. The data is genuinely on my Mac (Screen Time syncs across devices, pickup counts and all) — but Apple seals it in a sandboxed "data vault" that even Full Disk Access can't open; only Apple's own process may read it. The iPhone's own copy is excluded from backups. Every route that works needs a forensic extraction, not a daily job.

So I did the honest thing: real pickups on the Mac, a clearly-labelled proxy (session count) on the phone, and a note in the code so nobody re-litigates it. A good reminder that "the data exists" and "you can have the data" are different sentences.

What I learned

The build was maybe a third of the work; the rest was product work, deciding what to measure, and letting the research-based evidence overrule my instincts. My original model would have docked me for deep work, leaned on screen-time hours the literature says barely matter, and missed the compulsive-checking signal that actually predicts harm. The research didn't just tune the weights, it changed which contributors existed.

There's a broader RafeOS principle in there: a personal metric is only worth having if it's honest. Honest about uncertainty (today is pending, not faked), about provenance (real vs proxy), and about what the science does and doesn't support. A number that flatters you isn't wellbeing — it's a dashboard.

Next: a personalised "by this time of day" comparison so the live view can tell me I'm already heavier than usual — and a longer look at whether the categories still make sense once I've got a couple of months of clean data.

---

# Notes from SXSW London 2026
_https://rafeblandford.com/notes-from-sxsw-london-2026/ · 2026-06-08_

Sharing some notes from last week's festival - as usual there was an eclectic mix - and perhaps a greater than usual sense of ambiguity around the inevitable AI hot-topics.

AI business change sessions

Redesign before technology as an answer to the "90-95% of AI projects fail" stat.

▶ The Reinvention Window, Marc Warner (CEO & Global CTO, Faculty & Accenture). His argument: most projects fail, 90-95% by one count, because we bolt AI onto the existing process rather than redesigning it (his analogy was factories taking years to get value out of electricity while keeping the steam-era layout).

Key point: The same pattern came up in nearly every business session I sat in, the value isn't really in the model, it's in whether you're willing to redesign how the work gets done, and to rethink who the customer is.

▶ The Workforce Reimagined, Euro Beinat (Global Head of AI & Data Science, Prosus). One of the larger agent deployments I've heard described: 60,000 agents built in 12 months, graded intern to senior, with a few hundred driving most of the return.

Key point: What resonated was "jagged intelligence", the idea that AI is brilliant and brittle at the same time, which I think we'll all recognise from our own interactions with it.

▶ Why AI-Native Companies Are Playing a Different Game, Brian O'Reilly (COO, Writer). Only 10-15% of large enterprises have really re-architected their workflows and 80-85% of use cases don't need a frontier model.

Key point: the underserved opportunity is AI supervision (governance, auditing, observability) as businesses in their own right, because the capability is running well ahead of the controls. That's going to be the critical element as we re-architect and re-imagine businesses.

▶ Intercom On the Age of AI, Des Traynor (Co-Founder, Intercom). The story of putting 80% of engineering behind a $100k product (Fin) the day ChatGPT launched, against a $250m business.

Key point: Intercom's story is well known by now, but a good reminder that adoption will move fastest outside western markets, because there it's zero-to-something rather than an incremental upgrade.

▶ The Agent Has Entered the Store, with Daniele Bernardi (Toolhouse), Bouchra Kaabouz (Air France-KLM), Andy Fishburn MBE (Virgin StartUp) and Alessandra Bosco. Travel is the obvious early proof, given the friction (80% of carts abandoned, 23 tabs, three-hour bookings).

Key point: you need to serve two audiences at once, the model (which rewards consistency) and the human (who still wants relevance, or elasticity). Lose either and you optimise yourself into a sea of sameness.

The memory economy

The AI you talk to will probably end up knowing you better than you know yourself, while quietly working for someone else. It was one of the most thought provoking themes from last week.

A run of sessions kept circling the same question: who does AI actually work for, and who controls what we hand it?

▶ Meet Charlie, Sir Tim Berners-Lee & John Bruce (Inrupt), with Tania Bryer OBE (CNBC). Their argument is that the memory economy is more dangerous than the attention economy: assistants that know us intimately but answer to shareholders. Their proposed fix is a data vault you own, with agents working on top of it.

Key point: The data-vault model is one of the more important ideas for an agentic world. Whether it gets traction commercially is a separate question.

▶  The 6-Pack of Care, Audrey Tang & Caroline Emmer De Albuquerque Green (University of Oxford). Alignment reframed as a question of care rather than just code, with Taiwan's deliberative polling that cut deepfakes by 94% and became law in two months.

Key point: the bit that resonated was designing and making decisions to avoid lock-in. Alignment as an ongoing process, not a setting you configure once.

▶  Designing for Trust, Hovhannes Avoyan Hovhannes Avoyan (Picsart) & Nad Chishtie (Lovable), moderated by Hannah Parvaz (Aperture). Trust has shifted from "can it impress us?" to "can we rely on it?". The detail I liked: role-based agents flopped until they were given names and faces.

Key point: non-determinism (and the variability that comes with it) is a feature rather than a bug, but it does change how you have to design for trust (e.g. from empowerment, rather than consistency).

▶ From Policy to Practice: Building National AI Capability, George Osborne (OpenAI), moderated by Arjun Kharpal (CNBC). If the personal version of this is "who holds my data", the national version is "who holds the country's". Osborne on how governments pragmatically turn AI ambition into capability: trusted infrastructure, sovereignty, sharing cyber-defensive models with trusted partners, and regulation flexible enough not to be out of date in nine months.

Key point: it's the same data-vault instinct, one level up. Sovereignty isn't all-or-nothing; the harder question is which layer of the stack you trust others to run, and which you keep.

Fear, Trust and Hope

The corridor conversations at SXSW and the undercurrent in many sessions was how fearful people are of AI (and this from an AI-first and AI-literate crowd)... and yet I came away hopeful. A few sessions reminded me what we're capable of when we point the tech at the right problems and design it the right way.

The strongest sessions on staying ahead of AI's harms shared a spine: this is really about whether we can trust it, with our children, with the public realm, in our careers, and with each other. But we also need to remember that trust takes years to build and moments to break and so today is a formative moment.

▶  AI Is Already Shaping Childhood, Julia Gillard, Kanishka Narayan MP (UK Minister for AI & Online Safety) & Giovanni Salum (Child Mind Institute). The argument: act faster than we did with social media, and treat child safety as a moral non-negotiable rather than a cost-benefit calculation. A warning note is that AI is fundamentally different from social because it goes beyond social interaction to core cognitive functions.

Key point: the cleanest test I heard all week was whether a given use enhances or degrades someone's agency. It works well beyond children too.

▶ Reclaiming AI for the Public Good, Bo Young Lee 이보영 (AI4ALL), David Ryan Polgar (All Tech Is Human) & Elizabeth M. R. (Oxford). The harms aren't theoretical, bias enters at four different layers (algorithm, data, neural network, interface), and collective action does work. Bias and values aren't an accident that creeps in at one point, they are choices made at every layer. LLMs outputs are the direct result of design (and prompt) choices, not accidental

Key points: "inevitability" is itself a choice of narrative and collective action works (e.g. ozone layer). Existing law (IP, environmental, labour) is probably a faster lever than waiting for new AI-specific rules.

...and despite a shadow of fear in the rooms last week, there was still a sense of SXSW wonder - a fair bit of optimism about what creativity and technology can do together.

▶  Who Gets to Touch the Stars, Sheila Xu (AstroAccess) & Sandhya Sabapathy (Kaleidoscope). A deaf crew's light-based comms system ended up helping everyone once the cabin was too loud to hear.

Key point: design for the person your product wasn't built for. What breaks for them tends to break for everyone else under stress too.

▶  LEGO Futures Imaginarium, Joana Lenkova & David Pallash (LEGO). Probably my most joyful session of the week, partly because it was a room full of grown adults actually playing with LEGO. Play activates 24+ skills across creative, social, cognitive, physical and emotional development, and LEGO's Build the Change programme reaches 3 million children a year.

Key point: children from disadvantaged backgrounds "dream smaller", imagination can help change that. Also reminder that imagination and play are exactly the things we shouldn't be AI-ing away.

---

# BIMA 100 Tech & AI Pioneer
_https://rafeblandford.com/bima-100-tech-ai-pioneer/ · 2026-05-22_

I was proud to have recently been named in the BIMA 100 2026, in the AI & Tech Pioneers category. Thanks to the team at BIMA (British Interactive Media Association) and the supporting judges.

The work I was recognised for here was done leading a brilliant cross-discipline team at Digitas UK delivering complex and pioneering products and digital transformation for brands like Formula 1, EE, Honda and Biffa, plus working on change and AI capability that has real outcomes. The people around me made me better, and I tried to do the same for them, so a huge thanks to all of them too. For me high standards, high humanity = great outcomes.

I was privileged to be in great company in the Class of 2026, with names like Matt Roberts, Rebecca Crook, and many more. It was also great getting to see the next generation recognised too - the future is in good hands with people like Niyati Gupta and Roberto Scialpi.

At the evening reception for winners and invited guests, Mary Keane-Dawson, in opening remarks, powerfully reminded us that Britain's digital industry is at its strongest when diversity and inclusion are embedded, not bolted on. This is close to my heart and the work here continues and I think fairness, in many forms, is an inherent part of both high standards and high humanity.

The BIMA 100 is at its best when it surfaces people doing work you hadn't heard of yet. Go look at the full list - impressive people and pioneering work.

This post originally appeared on LinkedIn.

---

# Running a Personal Server Without Thinking About It
_https://rafeblandford.com/running-a-personal-server-without-thinking/ · 2026-05-07_

The important question to ask when they set up a personal server is: what happens when you stop paying attention to it?

This post covers the monitoring and maintenance stack built to ensure the new server doesn't follow the same path. The goal was specific: the server should run without daily attention, but alert immediately when something needs it.

The stack

 * Uptime Kuma for availability monitoring (11 endpoints, 5-minute checks)
 * Daily health check scripts for system-level verification (disk, memory, containers, SSL, backup status)
 * Automated backup to at home Synology NAS and remote B2 with a logical directory structure and restore documentation
 * Monthly Lighthouse for performance regression detection
 * Server email via Resend for alerts
 * Server notifications via Signal and Telegram for alerts

Key decisions

 * Why Resend over Gmail for server email (Workspace App Passwords don't exist)
 * Why restic and rsync over Synology Hyper Backup (simpler, no agent, full control)
 * Why a health check script over expanding Netdata alerts (Netdata is for deep-dive; the script is for "is everything OK?")
 * Why Uptime Kuma over external monitoring services (self-hosted, Tailscale-only, no subscription)
 * Why monthly Lighthouse rather than weekly (scores are stable, but useful to monitor)

What it costs

All of this runs on the existing server with no additional services or subscriptions. Resend's free tier (100 emails/day) is more than enough for alerts. Uptime Kuma, the health check script, the Lighthouse runner, and the backup cron are all self-hosted. The total additional RAM for monitoring: roughly 300MB.

---

# Preserving Flickr Archive with a Data Lifeboat
_https://rafeblandford.com/preserving-my-flickr-archive/ · 2026-04-29_

For a couple of decades I used Flickr as a working photo library — uploading from press events, device launches, Mobile World Congress, Nokia World, S60 Summits — and as a casual personal archive alongside that. The collection has been useful as a primary source: an exact record of what a Nokia 808 PureView looked like in someone's hand, what the keynote slides at MWC 2009 said, what the show floor at Nokia World 2010 felt like.

Flickr is healthier than it has been for a long time, but no service is forever. The platform changed hands twice (Yahoo, then SmugMug), changed its free-tier rules more than once, and at one point was rumoured to be on its last legs. So when the Flickr Foundation — a small non-profit spun out by SmugMug specifically to think about long-term preservation of online photography — opened up its Data Lifeboat service, I signed up.

What a Data Lifeboat actually is

A Data Lifeboat is a self-contained static export of a Flickr account. You pay (mine cost around £50), you choose which photos and metadata to include, and a few days later you get a ZIP containing:

 * the original-resolution photo files
 * thumbnails at multiple sizes
 * metadata as plain JSON: albums, galleries, tags, descriptions, comments, dates, contributors
 * a vanilla HTML/CSS/JavaScript viewer that runs entirely in the browser
 * a cover page describing the collection

That's the important bit. There's no database, no server-side logic, no external dependencies, no proprietary viewer that can stop working when something changes. Open the cover page in a browser and you can browse the entire collection. Upload the folder to any web host and it's a public website. Hand somebody the folder on a USB stick in twenty years' time and — assuming they still have a web browser — they can open it.

It is, deliberately, the simplest possible thing that could work.

What I got back

For my account that turned out to be 3,947 photos and around 5.3GB of files, covering roughly 2005 to 2014 — the All About Symbian and All About Windows Phone years. Originals and thumbnails together come to about 5.2GB; the metadata and viewer together are a few megabytes.

To publish it on the open web I renamed the cover from README.html to index.html and updated the viewer's references to match (the only change the export's SHARING.txt instructions require). It then drops straight into the existing static site setup behind Caddy.

Why bother?

I already had the photos. They were on Flickr. Why pay for an offline copy?

Three reasons. First, control: my archive now lives on infrastructure I own, alongside the rest of the All About sites' archived content. If Flickr ever changes the rules in a way I dislike, it doesn't matter to the archive. Second, completeness: the Lifeboat captures everything Flickr knows about each photo — original titles, descriptions, comments, tags, album membership — in a form I can actually read without the Flickr UI in the loop. Third, format simplicity: a folder of static HTML and JSON is going to outlive any live web service. It's the same reason the rest of the All About archive is plain HTML rather than running on a CMS.

The Flickr Foundation's argument is that the act of making a Lifeboat is itself a form of curation — you have to think about what's in your collection and what you want preserved. I can confirm that's true. Going through 3,947 photos one more time, I noticed a lot of things I'd forgotten taking, and a few I'd forgotten existed.

The archive is now live at archive.rafeblandford.com/flickr/ and will stay there.

The Data Lifeboat service is documented at flickr.org/programs/content-mobilization/data-lifeboat/.

---

# old.rafeblandford.com
_https://rafeblandford.com/old-rafeblandford-com/ · 2026-04-22_

I've long had a placeholder landing page on rafeblandford.com... Friends Ben and Ewan used to mock (rightly) the rather outdated set of icons, but I have a fondness for this snapshot of the early days of mobile (Symbian, N-Gage), social (Twitter and Jaiku), photography (Flickr) and services (Nokia's Ovi).

So... it's preserved for posterity at old.rafeblandford.com.

---

# Building Author Authority for a preserved website
_https://rafeblandford.com/building-author-authority/ · 2026-04-12_

How do you establish E-E-A-T (Experience, Expertise, Authoritativeness, Trustworthiness) for a website that's no longer actively publishing? Google's quality guidelines are designed for living sites with active authors. But a preserved archive has something most websites don't: two decades of consistent, high-quality content from identifiable authors with verifiable credentials.

The challenge is making that visible to search engines.

The author identity chain

Google's author understanding works through a chain of signals:

 1. Article page → links to author page via author Person object with URL
 2. Author page → has Person JSON-LD with sameAs links to external profiles
 3. External profiles (LinkedIn, GitHub, etc.) → confirm the person exists and matches

Each link in the chain strengthens the signal. A broken link — an author URL that 404s, a missing sameAs, an inconsistent name — weakens it.

What we found

All About Symbian had no author pages. The articles linked to /authors/rafe-blandford.php but that path returned 404. Every article by every author had a broken identity chain. Nearly 5,000 articles by me, 12,000 by Steve Litchfield, 4,200 by Ewan Spence — all orphaned.

All About Windows Phone was slightly better — it had four spidered author pages, but they contained old email addresses, dead Google+ links, and no structured data.

Building the pages

We created proper author pages with:

 * Person JSON-LD with name, jobTitle, description, image, sameAs, worksFor, knowsAbout, and alumniOf
 * Cross-site linking — each author's AAS page links to their AAWP page via sameAs, and vice versa
 * Professional headshots — replaced the 150×100 greyscale thumbnails with proper photos
 * Published work tables — article counts per site with section breakdowns
 * Selected articles — editorially chosen pieces that demonstrate range and authority
 * Bio text — establishing credentials, career progression, and specific areas of expertise

The sameAs array is where the identity chain connects to the wider web. My author page links to LinkedIn, GitHub, Instagram, rafeblandford.com, the 361 Podcast, and the archive portal. Google can follow these links, verify the identity, and associate the 5,000 articles with a verified person.

The publisher entity

Author identity alone isn't enough. The publisher — All About Symbian as an organisation — also needs to be a verifiable entity. The homepage WebSite schema includes:

 * Organisation with name, url, foundingDate (2001), logo
 * sameAs linking to the GitHub repo and social profiles
 * founder as a Person object linking back to the author page
 * memberOf connecting all three All About sites
 * knowsAbout covering the site's topic areas

This creates a bidirectional relationship: the Organisation knows about the Person (founder), and the Person works for the Organisation. Google can trace both directions.

The URL consistency problem

There was a subtle issue: all 13,496 article pages linked to author URLs with www.allaboutsymbian.com, but the canonical domain (and the author pages) used allaboutsymbian.com without www. The www version redirects via 301, but every article's author link was going through an unnecessary redirect before reaching the author page.

A single sed pass across the article files fixed the URLs, eliminating the redirect hop and giving Google a direct link from article → author page.

Minor authors

Not every contributor needs a full profile. The top five authors (Rafe, Steve, Ewan, David, Krisse) each have dedicated pages. Twenty-two minor contributors — people who wrote between 1 and 29 articles — redirect to a contributors page that lists them all with article counts.

This means every author URL in every article resolves to something meaningful. No 404s. No broken chains.

Results

The author pages are now the strongest E-E-A-T signal on the archive:

 * 7 author pages on AAS with Person JSON-LD
 * 4 enhanced author pages on AAWP
 * Cross-site sameAs linking creating a unified identity across properties
 * Every article linking to a live, structured author page
 * The publisher Organisation connected to the founder via founder and worksFor

For a site that stopped publishing years ago, this is arguably stronger author identity than most active blogs. The content is fixed, but the identity signals keep strengthening.

---

# Adding Schema.org to 145k Static Pages
_https://rafeblandford.com/adding-schema-org-to-145000-pages/ · 2026-04-12_

When you're running a live CMS, adding structured data is usually a template change — edit the theme, add the JSON-LD block, deploy. Every page gets the schema automatically because they're all generated from the same templates.

When your site is 145,000 static HTML files spidered from a CMS that no longer exists, it's a different problem entirely.

The starting point

The All About Symbian archive — along with its sister sites All About Windows Phone and All About Mobile — was preserved as static HTML in early 2026. The spidering process captured every article, review, feature, podcast, and gallery page as individual HTML files. The content was intact, but the structured data was minimal: basic Article microdata from the original CMS, and BreadcrumbList JSON-LD that we'd added in a previous pass.

Then Google started sending emails.

What Google wanted

The Google Search Console alerts were specific:

 * Review snippets: "Invalid object type for field 'itemReviewed'" — 61 review pages had review-like content (scores, reviewer names) but no proper Review schema
 * Forum comments: "Missing field 'comment'" — the DiscussionForumPosting schema on forum pages lacked the comment array that Google now requires
 * Breadcrumbs: "data-vocabulary.org schema deprecated" — some pages still had the old breadcrumb format
 * Junk files: HTML files masquerading as images in upload directories

Each of these required a different approach, and none of them could be solved with a template change.

The post-processing approach

The solution was a set of Python scripts that read each HTML file, extract metadata from the existing markup, build the appropriate JSON-LD block, and inject it back into the file. Each script handles one schema type:

Review pages (4,504 across three sites): The original CMS had review scores and reviewer names in the HTML, but as Article microdata — not Review schema. The script extracts the product name from the <h1>, the score from a content attribute, the author from an itemprop element, and builds a proper Review JSON-LD with itemReviewed, reviewRating, and author as a structured Person object. It even distinguishes between Product reviews (hardware) and SoftwareApplication reviews based on keyword detection.

News and feature articles (42,001 pages): These became NewsArticle or Article depending on section — news and flow pages get NewsArticle (eligible for Top Stories), features get Article. Each includes headline, description, author (Person with name and URL), datePublished, image, publisher (Organization), and articleSection.

Podcast episodes (616 pages): These were upgraded from generic Article to PodcastEpisode, with AudioObject containing the actual MP3 URL, duration (extracted from existing HTML microdata), file size, and encoding format. The partOfSeries property links each episode to its podcast series, extracted from the og:audio:album meta tag.

Forum threads (81,117 pages): The existing DiscussionForumPosting schema was enhanced with a comment array containing the first page's reply posts as Comment objects, plus commentCount, articleSection, inLanguage, and isAccessibleForFree.

Gallery pages (147): Upgraded from Article to ImageGallery with ImageObject entries for each photo on the page.

Support/KB pages (193): Tagged as TechArticle with headline, author, and description extracted from the Q&A structure.

The edge cases

Static archives have edge cases that live sites don't:

 * Symlinks: The archive uses lowercase symlinks for case-insensitive URL handling. Every script needs to skip symlinks to avoid processing the same content twice — and to avoid the symlink inheriting changes from the real file unexpectedly.
 * Two sites, shared icons: Some icon files are used as both tbimg (100×100 thumbnail) and fimg (640×180 featured image) by different articles. You can't make the file both sizes. Solution: featured image size wins, CSS scales it down for thumbnails.
 * URL-encoded filenames: Files with %20 in the name coexist with files that have actual spaces in the name. Caddy URL-decodes requests, so it serves the space-in-name version. Both files need to be updated.
 * Placeholder detection: The archive has two different placeholder image files — a 782-byte 640×180 PNG and a 287-byte 100×100 PNG. Scripts need to check file size, not just filename.

The results

After a single session, the three archive sites had:

 * Review JSON-LD on every review page
 * Article/NewsArticle JSON-LD on every editorial page
 * PodcastEpisode on every media page
 * Enhanced DiscussionForumPosting on every forum thread
 * WebSite + Organization on every homepage
 * Person JSON-LD on every author page
 * Consistent BreadcrumbList everywhere

All from post-processing scripts that can be rerun if the source files change. The scripts are at github.com/rafeblandford — the approach generalises to any static archive.

What happened next

Within days of submitting the sitemaps for revalidation, Google's coverage reports started improving. The review snippet errors cleared first, then the breadcrumb warnings. The forum comment schema was accepted on recrawl. The structured data went from "basic Article microdata" to a comprehensive schema implementation covering 145,000 pages across six different content types.

The irony: this preserved archive from the early smartphone era now has more thorough schema markup than most actively-maintained websites.

---

# What Google Search Console actually tells you (and what to do about it)
_https://rafeblandford.com/what-google-search-console-tells-you/ · 2026-04-11_

A day after cutting over DNS for the three archive sites, the emails started. Google Search Console had opinions.

Review snippets structured data issues. Breadcrumbs using a deprecated schema. Pages returning 404 that used to return 200. The kind of feedback that makes you realise the migration was only half the job.

Setting up programmatic access

The first thing I did was set up API access to Search Console. Google's web interface is fine for checking one site, but with four properties to monitor, I wanted a script I could run from the terminal. A Python script using the Search Console API, authenticated via OAuth2, that pulls coverage data, sitemap status, and URL inspection results across all properties at once.

This turned out to be straightforward. Enable the API in Google Cloud Console, create Desktop app credentials, run the script once to authenticate in the browser, and the token gets cached. From then on, a single command shows me what Google knows about all four sites.

The structured data mess

The review pages were the worst offenders. Over 2,200 pages across the three sites had schema.org/Review markup that had never been quite right. Five distinct issues:

The itemReviewed field was a bare text span, not a typed object. The author field was missing a name property. The author wasn't typed as a Person. The rating used schema.org/Rating instead of the expected type. And there was an unclosed <span> tag that had been silently wrong since the markup was first generated.

For an active site, you'd fix the markup properly. For an archive of Symbian app reviews from 2011, the pragmatic answer was to strip the review schema entirely and reclassify as Article. The ratings still display visually. Google just no longer tries (and fails) to parse them as structured data.

Converting 23,000 breadcrumbs

Every page used data-vocabulary.org/Breadcrumb markup, deprecated by Google in 2020. The old markup was consistent: a <p> tag with nested <span> elements containing the breadcrumb chain. Home > Section > Page.

Rather than stripping it, we converted to schema.org/BreadcrumbList JSON-LD. A Python script parsed each page's breadcrumb HTML, extracted the link text and relative URLs, resolved them to absolute URLs based on the file path and domain, and injected a clean JSON-LD <script> block into the <head>. Then it stripped the deprecated attributes from the visible HTML, leaving the breadcrumb links intact for users.

One script, 23,124 pages, all three sites. The visible breadcrumbs look identical. The structured data is now what Google expects.

The case sensitivity problem

This was the subtlest issue. The old server ran Apache on cPanel, which serves files case-insensitively on most configurations. Google had indexed some URLs with different casing than the actual filenames. When those URLs hit the new Linux server (case-sensitive by default), they 404'd.

The URL Inspection API confirmed it: the lowercase version was indexed and had been successfully crawled as recently as four days before the cutover. The correct-case version was unknown to Google.

The fix was symlinks. For every HTML file with mixed-case characters in the filename, create a lowercase symlink next to it pointing to the real file. 12,232 symlinks across the three sites. Zero performance cost. Caddy follows symlinks by default. The 404s became 200s.

The http sweep

Checking the HTML source more carefully revealed that internal references were riddled with http:// URLs. The og:image meta tags on 23,000 pages. Cross-site links between AAS, AAWP, and AAM. References to the mediafiles subdomains. Even the twitter:image tags on AAWP.

A single Python script with a list of our domains handled the lot. 28,874 pages updated. It also caught a double-www bug that had been in 1,400 pages since the original CMS generated the URLs.

We also found that the mediafiles subdomains had no cache headers, no security headers, no HSTS. A quick Caddyfile update added Cache-Control: immutable (one year), HSTS, and content-type protection. One reload, all mediafiles now cached properly.

The meta description gap

PageSpeed Insights flagged that pages had no <meta name="description">. They had og:description (for social sharing) but not the standard meta description (for search results). A script that copied the og:description value into a meta description tag, only where the og:description was non-empty, added descriptions to 12,494 pages.

Monitoring what you've fixed

Fixing things is satisfying. Knowing they stay fixed is more important. We set up three layers:

A daily health check script runs at 06:00, verifying disk usage, memory, Docker containers, HTTP status of every site, SSL certificate expiry, Tailscale connectivity, and whether the overnight backup completed. It emails only if something is wrong.

A weekly Lighthouse audit runs on Sunday mornings, testing six URLs (two per site) and logging the scores. If any score drops below threshold, it alerts.

Uptime Kuma monitors all eleven public endpoints every five minutes, providing a status dashboard and historical uptime data.

The total resource cost of all three monitoring systems: negligible. The total cost of not having them: discovering a problem when a user emails you, or worse, when Google deindexes a broken page.

The boring truth about SEO

None of this was glamorous work. Converting breadcrumb schemas, fixing canonical URLs, adding meta descriptions, creating symlinks for case-sensitive filesystems. It's the kind of thing that gets skipped because it doesn't feel productive.

But it's the difference between "the site works" and "the site works the way search engines expect it to." For an archive that depends on search traffic to remain discoverable, that distinction matters. Twenty years of mobile history is only preserved if people can find it.

Post-script - 1 month on

...and it had a real impact - traffic is up about 50% - a lot of that attributable to search engine or AI assistant traffic. It's hard to be certain, but I'd attribute it to performance (a ranking signal), technical improvements (e.g. consistent https), and making it easier for machines to understand the content... rather than a sudden upsurge in Symbian nostalgia!

---

# Migrating 200,000 comments
_https://rafeblandford.com/migrating-200000-comments-to-remark42/ · 2026-04-09_

When you host your comments on a third-party platform, you're renting your community. When the platform changes its terms, adds tracking, degrades performance, or simply shuts down — your community goes with it.

For the All About archive, we had nearly 200,000 comments across two sites, all hosted on Disqus. The comments were part of the editorial record — readers correcting details, sharing experiences, debating Nokia's strategy decisions in real-time. Losing them would be like archiving a newspaper but throwing away the letters page.

Why Remark42

Remark42 is self-hosted, open-source, stores everything in a local BoltDB database, supports OAuth login (Google, GitHub, Microsoft), and has a tiny footprint. No external dependencies, no tracking, no ads. Perfect for an archive.

The critical technical decision was same-origin proxying. Remark42 creates an iframe to render comments. If the comments server is on a different domain, Safari's Intelligent Tracking Prevention blocks third-party cookies, breaking authentication. The solution: serve Remark42 at allaboutsymbian.com/comments via Caddy reverse proxy, making it same-origin with the main site.

The AAS migration

All About Symbian had 102,496 comments across 3,570 threads. The migration had three phases:

Phase 1: Embed swap. Replace the Disqus <div id="disqus_thread"> and lazy-loading script with the Remark42 equivalent on every article page. 13,500 spidered HTML files, each modified in place.

Phase 2: Import. Disqus provides an XML export. But the URLs in the export don't match the archive URLs — they reference the old CMS paths, use http:// instead of https://, and include articles that no longer exist. A rewriter script maps each thread to its current URL using the CMS database: article ID → furl → current section → canonical URL.

Phase 3: Spam filtering. Disqus's export includes spam it had filtered at display time but kept in the database. We removed 8,000 Disqus-flagged spam comments plus 674 additional spam users identified by heuristic patterns (CJK character spam, link farms, known spam keywords).

The AAWP migration

All About Windows Phone was the bigger challenge. 95,338 comments, a separate Remark42 instance (different domain needs its own OAuth callbacks), and a 163MB XML export file.

The import hit two problems:

Problem 1: Remark42 crashes on 404 pages. During import, Remark42 fetches each page to get its title. When the page returns 404, the response handler dereferences a nil pointer and panics. The entire import crashes partway through. The fix: strip all threads with unresolvable URLs from the XML before importing — reducing 249,000 threads to 9,217 threads that actually map to existing archive pages.

Problem 2: The file is too big. At 163MB (reduced to 64MB after stripping), the XML exceeds internal limits when uploaded via the API. The solution: bypass the CLI tool entirely and POST directly to the container's internal API with a longer timeout.

The import took about 10 minutes to process, working through 9,217 threads and writing 89,483 comments to the BoltDB database.

The listing page updates

Comments aren't just for article pages. The listing pages — where readers browse through articles — show comment counts next to each headline. On AAS, the original spider captured these from Disqus. On AAWP, they all said "Comments" with no count.

A batch query script hits Remark42's /counts API with groups of 50 URLs, retrieves the comment count for each, and rewrites the listing page HTML. Rate limiting at 1 request per second keeps the API happy. 2,330 articles now show real counts across 623 listing pages.

Historical comments and GDPR

The imported comments are maintained under the UK GDPR archiving exemption (Article 89), which provides specific provisions for archiving in the public interest. Users can request deletion of their comments via the site contact page.

What we preserved

Between the two sites:

 * 191,979 comments imported and self-hosted
 * 6,000+ discussion threads preserved
 * Zero dependency on external services
 * Full user authentication via OAuth (no anonymous commenting)
 * Daily automated backups of the BoltDB database

The comments are no longer rented. They're part of the archive, served from our own infrastructure, backed up to our own storage. The community discussion from 2011 to 2022 is preserved alongside the editorial content it responded to.

---

# Every Nokia N-Gage Game
_https://rafeblandford.com/every-nokia-ngage-game-ever-made/ · 2026-04-08_

Nokia's N-Gage is one of those platforms that everyone remembers but nobody really knows. The "sidetalking" memes, the taco phone jokes, the assumption that it had no good games. Two decades on, the actual library — what was released, what was cancelled, and who made it all — is surprisingly hard to piece together.

So I did.

The Nokia N-Gage Archive is a complete directory of every game known to have been developed for the N-Gage hardware (2003–2006). Not just the 65 that shipped, but the 47 that didn't — the cancelled projects, the unreleased prototypes, the games that were announced at E3 and quietly vanished.

The numbers

65 released games. Published on MMC cards, sold in shops. From the October 2003 launch (Tomb Raider, Tony Hawk, SonicN, Pandemonium) through to the final stragglers in 2006 (Civilization, Warhammer 40K).

47 unreleased titles. Some barely existed beyond a press release. Others were nearly finished — Leisure Suit Larry: Pocket Party was built twice (at a cost of $1.4 million) before being shelved because Nokia couldn't decide how raunchy it should be. 8 Kings, a turn-based tactics game by Argonaut Games (the studio behind Star Fox), had its prototypes leak online in 2023. Alien Front, a Sega Dreamcast port, has had a playable prototype circulating among collectors since 2004.

6 PAL-only releases that most lists miss entirely: Flo-Boarding (by Housemarque, yes, the Returnal studio), Barakel, Pool Friction, TechWars, N-Gage Motocross Freestyle, and Sega Rally Championship. All developed or published by StormBASIC Games in South Africa, except Sega Rally (Hitmaker/Sega) and Flo-Boarding (Housemarque/Nokia).

The games were better than you think

The N-Gage's reputation for bad games is undeserved. The hardware was awkward, the marketing was dire, and the initial lineup was weak. But by 2004–2005, the library had genuine quality:

Pathway to Glory — RedLynx's WWII squad tactics game. Semi-turn-based, with destructible environments and Bluetooth multiplayer. Edge gave it 8/10. GameSpot gave it 8.1. RedLynx went on to create the Trials series and was acquired by Ubisoft.

The Elder Scrolls Travels: Shadowkey — The only Elder Scrolls game exclusive to a mobile platform, and only the second in the series with multiplayer (four-player Bluetooth co-op). The team did a 36-hour crunch to compress it below the MMC file size limit.

Colin McRae Rally 2005 — Won the BAFTA for Best Handheld Game in 2005. Yes, an N-Gage game won a BAFTA.

Tony Hawk's Pro Skater — Won BAFTA Best Mobile Game in 2004. Two BAFTAs for N-Gage in consecutive years, and nobody remembers.

Rifts: Promise of Power — Won Best Mobile Game 2005 from EGM/CGW. Its source code was later released and is now on GitHub, with an active community building a DRM-free version.

The developers who went on to bigger things

One of the most striking things about the N-Gage library is how many of its developers became significant studios:

 * Housemarque (Flo-Boarding) → Resogun, Returnal, acquired by Sony
 * RedLynx (Pathway to Glory, High Seize) → Trials series, acquired by Ubisoft
 * Bugbear (Glimmerati) → FlatOut, Wreckfest
 * Digital Legends (ONE) → acquired by Activision for Call of Duty: Warzone Mobile
 * Vicarious Visions (Crash Nitro Kart) → Crash N. Sane Trilogy, Tony Hawk 1+2 remake, merged into Blizzard
 * Monkeystone Games (Red Faction) → John Romero and Tom Hall's mobile studio
 * Gameloft (Asphalt: Urban GT) → launched what became their biggest franchise on N-Gage

The N-Gage was a proving ground. Studios cut their teeth on technically constrained mobile hardware and took those skills into the smartphone era that followed.

The ones that got away

The unreleased games tell their own story. Nokia was clearly ambitious — the cancelled list includes Mortal Kombat, Brothers in Arms, DRIV3R, The Urbz: Sims in the City, and a chess game by Lavastorm Engineering. There was even an MMORPG: HinterWars, which ran a public beta with cross-platform play between N-Gage and PC before the platform was cancelled.

Spirits was an MMO collectible card game where you hunted elemental creatures — think Pokémon meets an occult thriller. Jadestone, the Swedish developer, built a demo and had marketing plans underway before Nokia pulled the plug in 2006.

GunForge was a run-and-gun shooter by TKO Software — the same studio building Leisure Suit Larry. When TKO was shut down by its parent company, both games died. Part of the team formed Method Solutions and went on to make the N-Gage version of Call of Duty.

How we built this

This was built as a collaborative project with Claude Cowork and Claude Code. Agentic harness are very good at research synthesis and basic coding, so my role was more setting requirements, detailing potential sources, providing editorial narrative, and doing quality control. That AI was good at creating a small micro-site and synthesising information will suprise no one, but I was pleasantly suprised by its aptitude and reasoning for a relatively esoteric topic and the way it was easy to combine knowledge and technical work together, with relatively little direction (certainly a step on from last year's frontier models).

The data comes from over ten sources. The foundation is the original All About N-Gage database — I ran a sister site to All About Symbian covering the N-Gage platform from 2003 onwards, and the game directory was a section of that site until it went offline in 2020. That gave us the original editorial descriptions, publisher data, and review scores.

On top of that: Wikipedia's game list, MobyGames for developer credits and cover art, a comprehensive community spreadsheet maintained by collectors, the N-Gage Archive blog, Unseen64 (which specialises in documenting cancelled games), mupf.dev (an N-Gage preservation project that has done remarkable work including compiling an N-Gage SDK), and the Internet Archive which had official Nokia packshot images.

90 of the 112 games have box art — 25 are official Nokia packshot images preserved on the Internet Archive. 35 have their original PDF user manuals. 45 have review scores from All About N-Gage. 45 have official Nokia descriptions recovered from archived n-gage.com pages via the Wayback Machine. 66 have embedded YouTube gameplay videos, many from the excellent @ngage-archive channel which captures N-Gage gameplay in 4K via emulation. Every released game has developer, publisher, genre, multiplayer details, and links to whatever editorial coverage exists.

There's even a homebrew section: Lowtek Games in Dundee released Parasite Pack in 2025 — a limited run of 100 CIB copies at £35, making it the first new N-Gage game in nearly 20 years.

For anyone wanting to play these games today, the EKA2L1 emulator supports almost all official N-Gage titles on Windows, macOS, Linux, and Android.

I'm not aware of another source that brings all of this together in one place.

Browse the archive

The full directory is at allaboutsymbian.com/n-gage-games/original/. Games are grouped by genre, with a separate section for the 47 unreleased titles and a homebrew section. Each game has its own page with everything we could find.

The broader Nokia N-Gage Archive also includes the N-Gage platform games (2008–2010), third-party Ovi Store titles, and nearly 2,000 editorial articles — news, reviews, and features written during the platform's lifetime.

If you spot errors, know something we've missed, or have materials that could improve the archive (screenshots, box art, development stories), I'd be glad to hear from you.

The Nokia N-Gage Archive is at allaboutsymbian.com/n-gage-games/.

---

# Bringing N-Gage Home
_https://rafeblandford.com/bringing-ngage-home/ · 2026-04-07_

Bringing N-Gage Home: Integrating Nokia's Gaming Archive

N-Gage occupies a curious corner of mobile gaming history. It's not quite forgotten — mention it and people remember the "taco phone" jokes — but the detail of what Nokia actually built, and the games that were made for it, is surprisingly hard to find online. Most of the editorial coverage that existed at the time has been offline since 2020.

That changed recently. The complete editorial archive from All About N-Gage and its successor Ovi Gaming has been integrated into All About Symbian, alongside an enriched games database covering every title known to have been developed for the platform — released and unreleased.

Two generations of N-Gage

The N-Gage story divides neatly into two phases, different enough to be almost entirely separate platforms.

The hardware era (2003–2006) was Nokia's first dedicated gaming device. The original N-Gage and its successor the N-Gage QD were standalone handhelds running Symbian OS, with games distributed on MMC cards — physical media, bought in shops. The library ran to 65 commercially released titles, with another 47 that were announced, developed, or rumoured but never shipped. Some were ambitious — Elder Scrolls: Shadowkey was a genuinely impressive open-world RPG, and the only Elder Scrolls game with multiplayer co-op until Elder Scrolls Online a decade later. Others were competent ports of console franchises: Tomb Raider, Splinter Cell, Tony Hawk. The hardware was mocked for its form factor (you held it sideways to make calls), but the games were better than their reputation suggested. Pathway to Glory was a legitimate tactical classic that won BAFTA nominations. The device never found a mass audience, and Nokia discontinued it in 2005.

The platform era (2008–2010) was the second attempt, and a fundamentally different proposition. Rather than a dedicated device, the new N-Gage was a software platform that ran on existing Nokia S60 smartphones — the N81, N95, N96, and later the 5800 XpressMusic. Games were downloaded, not bought on cards. Nokia positioned it as a casual gaming platform with social features (N-Gage Arena for leaderboards and friend lists) and curated a library of 57 first-party and featured titles, plus hundreds of third-party games through the Ovi Store. The games were good — Reset Generation was a genuinely innovative multiplayer title, Metal Gear Solid Mobile was technically remarkable on a phone, and the N-Gage versions of FIFA and Crash Bandicoot held up well. But the platform never achieved critical mass, and Nokia shuttered the service in late 2009.

The editorial record

All About N-Gage launched as a sister site to All About Symbian, covering the N-Gage platform with the same editorial depth — news, reviews with scores, features and analysis. When Nokia pivoted to the Ovi Store model in 2009, the site rebranded as Ovi Gaming and expanded to cover the broader S60 gaming catalogue. The editorial team was led by Tzer2 (krisse), who was the driving force behind AAN and wrote the bulk of the platform-era coverage, alongside Ewan Spence who contributed extensively to the classic hardware-era reviews and features.

A lot of this content was cross-posted to All About Symbian — the audiences overlapped significantly, and the CMS made it easy to publish to multiple sites. But 651 articles were exclusive to All About N-Gage and Ovi Gaming. These included the detailed game reviews (with scores), the news coverage of platform launches and game announcements, and the opinion pieces about where Nokia's gaming strategy was heading. Combined with the AAS-native N-Gage coverage, there are nearly 2,000 N-Gage editorial articles in total.

This content had been offline since the server was frozen around 2020.

The integration decision

The cross-posting history made the integration decision straightforward. Rather than preserve All About N-Gage as a separate archive — which would have meant duplicating the shared content or leaving gaps — the exclusive content has been folded into All About Symbian where it naturally belongs. The 651 exclusive articles now sit alongside the cross-posted content in the AAS news, reviews, and features sections, tagged to the N-Gage platform. Each carries a note explaining its origin.

The editorial is organised into two eras: Classic Editorial (731 articles covering the hardware era, 2003–2007) and Platform Editorial (651 articles from the AAN/Ovi Gaming era). Both are browseable from the Nokia N-Gage Archive landing page.

The allaboutngage.com domain now redirects with full path mapping — old links to game pages, reviews, and news articles land directly on the corresponding content on All About Symbian.

The games database

Alongside the editorial content, the Nokia N-Gage Archive at allaboutsymbian.com/n-gage-games/ brings together the complete games record:

 * 65 released classic N-Gage games — the complete MMC card library, each with box art, developer and publisher credits, genre, multiplayer details, review scores, screenshots, and links to contemporary editorial coverage.
 * 47 unreleased titles — announced, developed, or rumoured games that never shipped. Many have detailed development histories: the $1.4 million Leisure Suit Larry that was built twice, the Mortal Kombat port by THQ, the Argonaut Games tactical strategy game whose prototypes leaked in 2023.
 * 57 N-Gage platform games — the curated first-party and featured titles from the software platform era.
 * 339 third-party Ovi Store games — the broader S60 gaming catalogue.

The classic games database was enriched from over ten sources: the original All About N-Gage database, Wikipedia, MobyGames, Unseen64, the N-Gage Archive community site, mupf.dev (an N-Gage preservation project), Internet Archive, GameFAQs, and a comprehensive community spreadsheet maintained by collectors. Box art comes from official Nokia press packshots preserved on the Internet Archive. 35 games include their original PDF user manuals.

Every released game page links back to the All About N-Gage editorial where it exists — the review, the news coverage, the features. The archive is cross-referenced: games connect to articles, articles connect to games.

Why this matters

There's a small but dedicated community of people interested in N-Gage history — collectors, mobile gaming historians, Nokia enthusiasts, retro gaming fans. The editorial coverage from All About N-Gage and Ovi Gaming is, as far as I can tell, the most comprehensive English-language record of the platform. Game reviews, launch coverage, developer interviews, analysis of Nokia's strategy — it was all written in real time by people who were using the platform daily.

The enriched games database brings something new. No single source previously had the complete picture — released games, cancelled titles, development histories, review scores, box art, and editorial links all in one place. The data is structured with Schema.org markup, making it discoverable and machine-readable.

Some of the development stories are fascinating. Housemarque — the Finnish studio that would later make Returnal for PlayStation 5 — made one of their earliest games for the N-Gage (Flo-Boarding, bundled with every European device). RedLynx, who created the Trials series, made the N-Gage's best game (Pathway to Glory). Digital Legends, who built ONE for the N-Gage, were eventually acquired by Activision to work on Call of Duty: Warzone Mobile. The N-Gage was a proving ground for studios that went on to shape modern gaming.

Most of this material doesn't exist anywhere else in a structured form. Now it does.

The Nokia N-Gage Archive is at allaboutsymbian.com/n-gage-games/. The editorial content is browseable via the N-Gage news, reviews, and features sections.

---

# What 449k forum posts tell us About Symbian
_https://rafeblandford.com/what-449000-forum-posts-tell-us/ · 2026-04-06_

Having recently restored the AAS forum, a fun extra projects was to generate some stats to get an after-the-fact sense of what was happening (and another excuse to use Claude Code for a micro-task).

The shape of a community

Go to the stats page and look at the posts-per-month chart. It shows something that no market share graph or analyst report captures: the lived experience of a technology community.

The line rises steeply from mid-2001, peaks violently in 2003, sustains a long plateau through 2007, then falls away — slowly at first, then rapidly — to almost nothing by 2013. If you know the history of Symbian, every inflection point makes sense. If you don't, the chart tells the story anyway.

This is what 449,000 forum posts look like when you plot them. Not pageviews or downloads or revenue — conversations. People helping each other, arguing about firmware, sharing things they'd made. The shape of a community.

Other stats show how forums interacted with each other, evolved over time, and who were the top users.

Three eras

The Early Web Forum (2001–2002): 341 threads in the first year. The Nokia 9210 and 7650 forums. A small, intensely technical community. Posts are long, detailed, often from people who'd been using Psion devices since the 1990s. The phpBB-era legacy markers ([addsig], inline smilie paths) are visible in the earliest posts. The Nokia 9210 forum — a communicator with a full keyboard and colour screen — accumulated 15,480 posts and 2,446 threads, making it one of the most active forums in the archive despite being for a device most people have never heard of.

The Smartphone Boom (2003–2007): The Nokia 6600 arrives and the forum explodes. 103,000 posts in 2003 alone. New device forums are created monthly. The Nokia 7650 forum accumulates 4,430 threads and 34,206 posts — more than many entire forums. The community is global: posts reference currencies from Nokia pricing in India, carrier-specific firmware for European networks, availability dates in the US. The peak of forum culture coincides with the peak of Symbian — this was how you learned to use your phone.

The Sony Ericsson P800/P900/P910 forum is a surprise in the data: 31,266 posts, making it the fourth most active forum. The UIQ platform never had the market share of S60, but its community was passionate and concentrated in a single forum.

The Long Decline (2008–2013): The iPhone launched in June 2007. The forum's monthly post count doesn't drop immediately — the N95 sustains activity through 2008. But the trajectory changes. Nokia's response (the N97, the slow Symbian^3 rollout, the eventual pivot to Windows Phone in February 2011) plays out in real-time in the thread titles. The February 2011 "burning platform" announcement is visible as a cliff edge in the posting data. By 2013, the forum was producing 732 posts for the entire year — less than the community managed on a single busy day in 2002.

What people actually talked about

The most active forums tell you what mattered:

Forum
Posts
Threads

Nokia N95 and N95 8GB
41,785
6,181

Nokia 7650
34,206
4,430

Series 60 (general)
33,355
2,752

Sony Ericsson P800/P900/P910
31,266
5,184

Nokia 3650/3660/3620
19,413
3,306

Nokia 6600 and 6620
19,160
3,288

The most-viewed threads reveal the forum's real utility. These weren't discussions — they were living reference documents:

 * N73 firmware versions (780,000 views) — a community-maintained tracker of every firmware release for every product code
 * N95 firmware versions (675,000 views) — the same, for the N95
 * N95 product codes for debranding (646,000 views) — how to flash your carrier-locked N95 with generic firmware
 * "Full phone formatting a 6600!" (427,000 views, 204 replies) — a troubleshooting guide that became the definitive reference

This was the pattern: someone would create a thread to document something, and the community would keep it alive for years, adding firmware versions as Nokia released them, noting which product codes worked with which carriers, flagging problems with specific updates. It was collaborative documentation, maintained by volunteers, before wikis were mainstream.

The general discussion forums reveal the community's personality. "Community Waffle" was the off-topic forum — 17,211 posts, but in only 1,246 threads, meaning long-running conversations. Its gaming subforum had 13,174 posts across just 42 threads, dominated by word games and forum games ("Let's Play!" had 2,399 replies, "This or That?" had 1,184). These were the threads that turned a tech support forum into a community.

The devices that defined eras

Device
Forum Threads
Peak Year
What It Represented

Nokia 7650
4,430
2002
The first real camera phone

Nokia 6600
3,288
2003
Symbian goes mainstream

Nokia N95
6,181
2007
The everything phone

Nokia N97
1,716
2009
The beginning of the end

Nokia N8 (Symbian^3)
957
2010
The last stand

The N95's forum is the largest by a wide margin — 41,785 posts, nearly 20% more than the 7650's forum despite covering a shorter period. The N95 was the phone that tried to do everything (5MP camera, GPS, Wi-Fi, video calling, music player) before the iPhone simplified the category. The forum reflects that ambition: threads about GPS navigation, firmware bugs, video encoding, Bluetooth accessories, and the endless debate about whether the N95 or iPhone was the better device.

The N97's forum is poignant. Nokia positioned it as the N95's successor, but the 1,716 threads are full of frustration — resistive touchscreen complaints, performance problems, software bugs. The thread titles shift from "how do I" to "does anyone else have this problem." You can read the moment Nokia lost the community's confidence.

The community's notable contributors

The top 15 posters account for a remarkable share of the forum's content:

Username
Posts
Active

slitchfield
7,002
2002–2013

GhostDog
6,356
2002–2005

Rafe
6,084
2001–2013

nj7
3,747
2006–2010

Jadeviper
3,119
2003–2006

Ewan
2,988
2001–2011

J2theIZZO
2,719
2002–2008

kontraband
2,666
2006–2012

bartmanekul
2,653
2007–2010

Gadget17
2,618
2002–2010

Steve Litchfield (slitchfield) posted consistently for over a decade — 7,002 posts from 2002 to 2013. He was also a prolific contributor to the main AAS site, writing hundreds of in-depth reviews and software roundups. GhostDog was intensely active for a shorter period, averaging over 5 posts per day during 2002–2005. Ewan Spence (Ewan) was another AAS editor whose forum presence spanned the entire Symbian era.

What stands out is how many of these contributors stayed for years. This wasn't a site where people asked one question and left. The top 40 contributors all posted for at least two years, most for five or more. They were the backbone of the community — the people who answered the same questions patiently, maintained the firmware threads, and kept the conversation going.

What's lost and what's preserved

No archive is complete. Here's what we have and what we don't:

Preserved:

 * Every public thread and post (449,030 posts across 76,783 threads)
 * The complete forum hierarchy (88 forums in a 3-level structure)
 * 3,929 file attachments, including 341 Symbian .sis application packages that likely don't exist anywhere else on the internet
 * Community statistics: who posted, when, how much
 * The full text of every discussion, fully searchable

Lost:

 * User avatars and profile images (stored on the server filesystem, not in the database)
 * Some icon images from the earliest posts (lost in a previous server migration, replaced with grey placeholders)
 * User profiles and signatures
 * Private messages (excluded for privacy)
 * The interactive elements — polls, reputation, thanks — that made it feel like a living community

The .sis files are perhaps the most historically significant artefact. These are Symbian application packages — the installable apps that people built and shared with each other. Most Symbian app download sites are long gone. The forum attachments may be the last copies of some of these applications.

Reading the archive

The forum archive is at allaboutsymbian.com/forum/. You can browse by the original forum structure, search across everything with Pagefind, or start at the stats page to see the community's timeline.

The data tells a specific story — of a technology that defined the smartphone, a community that formed around it, and the inevitable transition that followed. But the individual threads tell thousands of smaller stories: someone in 2003 figuring out how to get Bluetooth working between their Nokia and their laptop, someone in 2007 excitedly posting first impressions of the N95, someone in 2011 asking whether it's time to switch to Android. These are the kinds of conversations that disappear when forums go offline. Now they won't.

---

# Bringing back the forum — 449,000 posts
_https://rafeblandford.com/bringing-back-the-forum/ · 2026-04-05_

The All About Symbian forum ran from 2001 to 2013. At its peak, it was the primary English-language community for Symbian smartphone users — Nokia 7650 owners helping each other with Bluetooth pairing, N95 enthusiasts debating firmware versions, S60 developers sharing OPL tips. Nearly 77,000 threads, 449,000 posts, from 39,000 community members across 88 forums covering every Symbian device that mattered.

When the sites went into archive mode, the forum went dark. A vBulletin 3.8 installation needs PHP, MySQL, and active maintenance. Running a 2012-era forum application on a modern server is a security liability. So the forum got a placeholder page: "The All About Symbian discussion forum is no longer available."

Until now.

The database resurfaces

A 2020 backup turned up with a complete vBulletin MySQL dump — 1.6 GB, 180 tables, every thread and post preserved. The previous migration had only partially recovered this data. The full dump changes the picture entirely.

The first step was understanding what was actually in there. The numbers told the story even before reading a single post:

Year
Posts
Threads

2001
1,848
341

2002
37,434
4,942

2003
103,033
12,698

2004
55,864
12,808

2007
59,924
11,999

2010
20,214
3,745

2013
732
451

2003 was the peak — over 100,000 posts in a single year. That's the Nokia 6600 and 7650 era, when Symbian defined what a smartphone was. The 2007 spike corresponds to the Nokia N95, probably the platform's last great phone. By 2010, the decline is unmistakable. By 2013, the community had all but moved on.

This isn't just data. It's the heartbeat of a community that helped define the smartphone as we know it.

The encoding problem (and why forum data is hard)

vBulletin 3.8 stores everything in MySQL with a latin1 charset. But the actual content is UTF-8 — Chinese characters, Euro signs, accented names from European users. MySQL thinks the bytes are latin1; they're actually UTF-8 stored in latin1 columns. This is the classic "double encoding" problem that has plagued every forum migration in history.

The fix is deceptively simple: tell your MySQL client to read the data as latin1 (so it doesn't try to "convert" already-correct UTF-8), then decode the bytes as UTF-8 in your application code. In Python: text.encode('latin1').decode('utf-8', errors='replace'). One line, but getting there involves understanding why pymysql maps MySQL's 'latin1' to Python's 'cp1252' (which can't handle all 256 byte values) and overriding the connection encoding to 'iso-8859-1'.

This kind of thing is why forum archives are rare. It's not that the data is lost — it's that the layers of encoding, BBCode formatting, and application-specific conventions make it genuinely difficult to extract cleanly.

BBCode: the forgotten markup language

Forum posts from this era are written in BBCode — [b]bold[/b], [url=http://...]link[/url], [QUOTE=username;postid]quoted text[/QUOTE]. It's like HTML's less popular cousin, and every forum implemented it slightly differently.

The conversion handles the standard tags, but the interesting challenges are in the edge cases: [QUOTE=Rafe;12345] needs to render with a link back to the quoted post. [ATTACH]789[/ATTACH] references a binary blob stored in the database that needs to be extracted to a file on disk. Legacy posts from the forum's phpBB days contain [img]/phpBB/images/smiles/icon_wink.gif[/img] — smilies referenced by filesystem path. Posts from 2001 have [addsig] markers that vBulletin 2.x used to append signatures.

None of this is conceptually difficult. But the accumulation of edge cases across 449,000 posts from 17 years of forum software evolution means the BBCode converter needs to handle things no documentation covers.

Static, not dynamic

The decision to generate static HTML rather than running a read-only forum application was straightforward. The existing archive sites (AAS, AAWP, AAM) are all static — Caddy serves files from disk, Cloudflare caches them, Lighthouse scores hit 100/100/100/100. Adding a PHP or Python application server just to display read-only forum posts would be unnecessary complexity.

The generator is a single Python script. It connects to MariaDB, queries forums, threads, and posts, converts BBCode to HTML, renders Jinja2 templates, and writes static files. 81,117 pages generated in under two minutes. The output is 1.3 GB — HTML files, a CSS stylesheet, and the extracted attachments (3,929 files including Symbian .sis application packages that likely don't exist anywhere else).

Search is handled by Pagefind, a static search library that runs entirely in the browser using WebAssembly. It indexed all 78,000 pages in 3.5 minutes, producing a 430 MB index that loads in small chunks — typically 100-300 KB per search query. No server-side search infrastructure needed.

What the archive tells us

The most popular threads are exactly what you'd expect from a specialist community: firmware version trackers, product code databases for debranding carrier-locked phones, "ask any questions" megathreads for new device owners. The Nokia N95 forum alone has 6,190 threads and 41,785 posts. The most-viewed thread — N73 firmware versions — has been seen 780,000 times.

The busiest single day was 2 December 2002, with 613 posts. The top 40 contributors posted between 900 and 7,000 messages each, over periods spanning years. These weren't drive-by commenters — they were community members who showed up, day after day, to help strangers with their phones.

The stats page tells the whole story in a single chart: a line rising steeply from 2001, peaking in 2003, sustaining through 2007, and falling away to almost nothing by 2013. It's the lifecycle of the Symbian platform, measured in community engagement rather than market share.

Open source

The generator is available as an open-source project: vbulletin-3-static-archive. It's config-driven — the All About Symbian configuration ships as the working example, but the tool is designed to work with any vBulletin 3.x database. The documentation includes a detailed write-up of the encoding fix (which will save anyone working with vBulletin dumps in Python several hours of debugging), the BBCode converter's approach and edge cases, and deployment notes for Caddy, nginx, and Cloudflare.

If you have a vBulletin 3.x forum that deserves preserving, this might save you a few weeks.

The museum framing

This isn't a forum that's been "brought back to life." Nobody is going to post new replies to a 2007 thread about N95 firmware. It's a museum — a preserved record of how a community of enthusiasts navigated the most transformative period in personal technology.

The archive lives at allaboutsymbian.com/forum/, alongside the editorial archive of the main site. It's browsable by the original forum structure, searchable via Pagefind, and indexed by Google. Schema.org structured data helps search engines understand what the content is. Every thread page scores 100/100/100/100 on Lighthouse.

If you were part of the AAS community — if you ever asked about Bluetooth file transfer, or argued about whether the N95 or iPhone was the better device, or shared a theme you'd made — your words are still there.

---

# Claude Code as a migration partner
_https://rafeblandford.com/claude-code-as-a-migration-partner/ · 2026-04-04_

Over two days in late March, I migrated three websites containing 20 years of content from a dying CentOS 7 server to a modern static archive. The primary operator wasn't me -- it was Claude Code, Anthropic's AI coding assistant, running on my Mac and SSH-ing into servers while I supervised.

This isn't a product endorsement. It's a reflection on what the collaboration actually looked like in practice -- what worked, what didn't, and what it means for how technical work gets done.

The setup

Claude Code runs in a terminal on my Mac. It can execute shell commands, read and write files, and maintain context across a long session. For this project, it was SSH-ing into two servers: the old CentOS box being decommissioned and the new OVH Debian server receiving the archive. I watched, directed, and intervened when needed.

The project involved auditing a server's disk usage, cleaning up hundreds of gigabytes of cruft, spidering 24,000 dynamic web pages, rsyncing 54GB of media, running post-processing scripts across 29,000 HTML files, configuring a web server, setting up databases, optimising Lighthouse scores, and handling DNS cutover. A proper infrastructure migration with real data at risk.

Where it excels

The standout capability is repetitive operations at scale. When you need to strip Google Analytics tags from 29,000 HTML files, or add lazy loading attributes to 387,000 image tags, or rewrite URLs across an entire site -- this is tedious, error-prone work for a human and trivially parallelisable for an AI. Claude Code wrote the sed and Python scripts, tested them on a single page, then applied them across the full dataset. The feedback loop was minutes, not hours.

Debugging was another strength. During post-processing, some image tags were corrupted with byte sequences that shouldn't have been there -- \x01 and \x02 characters embedded in the HTML. Claude Code identified the source (an overly broad regex in the accessibility fix script), diagnosed why it was happening (backreference capture groups interacting with binary-like content), and wrote the corrective script. That kind of systematic diagnosis across thousands of files is exactly where pattern-matching at scale pays off.

The Lighthouse optimisation session was particularly effective. Claude Code could parse the JSON audit output, identify which specific recommendations were actionable, propose fixes, apply them, and verify the results -- all in a tight loop. The entire Performance/Accessibility/Best Practices/SEO optimisation was done in a single session.

Where it still needs a human

Architectural decisions were entirely mine. What content to keep, what to archive, what to let go. Whether to attempt recovering the corrupted vBulletin forum data or mark it as a future project. Whether placeholder images for missing icons should be grey boxes or something more descriptive. These are judgement calls that require understanding the history and the audience, not just the technical constraints.

Visual verification was another gap. Claude Code can check that a URL returns a 200 status code, but it can't tell you that the flexslider carousel looks broken, or that the logo is rendering with corruption artefacts, or that the archive banner's positioning feels wrong on mobile. Every significant change needed a visual check in the browser.

Domain knowledge mattered more than I expected. Understanding the CMS architecture -- how the URL routing worked, why mediafiles were on subdomains, which images were article content versus site chrome -- all of this informed decisions about what to spider, what to rsync, and how to configure the web server. Claude Code could investigate and report, but the interpretation required context that came from having built and maintained these sites for fifteen years.

The collaboration pattern

The working rhythm settled into something natural. I would set a direction: "Spider the three sites, rsyncing media separately." Claude Code would investigate the current state, propose a plan with specific commands and configurations, and wait for approval. Once approved, it would execute, monitor progress, handle errors, and report results. I'd review, spot-check visually, and set the next direction.

It's not pair programming exactly -- more like having a very capable, very fast junior engineer who never gets tired, never loses context, and is extremely good at following a systematic process. The "junior" part matters: it will confidently execute a plan that has a subtle flaw if you don't catch it first.

Mistakes and recovery

The biggest incident was a post-processing script with a greedy regex that was supposed to strip Google Ads divs but ended up eating significant chunks of page content across all 29,000 pages. The pages were mangled badly enough that we had to re-spider the entire dataset and start the post-processing from scratch.

The lesson wasn't that the AI made a mistake -- humans write greedy regexes too. The lesson was about safety nets. We'd taken hardlink snapshots before the post-processing started, which meant recovery was possible without re-downloading everything from the old server. After the incident, we adopted a stricter pattern: test every regex on a single page, visually verify the output, then apply at scale.

The flexslider breaking when jQuery was deferred was a more subtle issue. The fix was technically correct -- deferred scripts load faster -- but it didn't account for a runtime dependency that wasn't visible in the code without understanding the initialisation sequence. That's the kind of thing where human experience with legacy JavaScript catches what static analysis misses.

Speed

What would have taken me two to three weeks of evening work was completed in roughly two full days. The audit alone would have been a day of SSH-ing around and taking notes. The spidering was largely waiting, but the post-processing -- writing scripts, testing, applying, debugging, iterating -- would have been the real time sink. Claude Code compressed the iteration cycle from "write script, test, find bug, fix, retest" spanning hours into tight loops spanning minutes.

Trust but verify

The operating principle throughout was: trust the execution, verify the output. Every post-processing script was tested on one page before being applied to 29,000. Every Caddy configuration change was tested with curl before being declared complete. Every Lighthouse optimisation was verified with a fresh audit.

This isn't unique to working with AI -- it's just good operational discipline. But it matters more when the operator can execute changes faster than you can review them. The speed that makes AI assistants valuable also makes verification non-negotiable.

What it means

I don't think this replaces the need for technical understanding. If anything, it amplifies it. Having deep knowledge of the systems involved meant I could direct the work effectively, catch problems early, and make good architectural decisions. Without that background, I'd have been unable to evaluate whether the proposed approaches were sensible.

What it does replace is the drudgery -- the hours of repetitive file manipulation, the careful but tedious script writing, the systematic testing across thousands of pages. The parts of infrastructure work that are intellectually simple but operationally demanding. Handing those to an AI while retaining the interesting decisions is, genuinely, a better way to work.

---

# Optimising an old codebase for modern web standards
_https://rafeblandford.com/optimising-a-decade-old-codebase/ · 2026-04-02_

After migrating three legacy mobile tech sites to static archives, I had a working but underperforming set of pages. The HTML was from roughly 2020, built on a codebase that had its roots in the mid-2000s. It worked, but a Lighthouse audit told the real story: Performance 71, Accessibility 66, Best Practices 73, SEO 83.

Not terrible for a decade-old codebase. But not good enough to leave alone, especially when the pages would now be frozen forever. Whatever state they were in was the state they'd remain in. Worth spending an afternoon to get them right.

How

This was a great test case for agentic engineering. Well defined problems, lots of drudge work that could be easily automated, and a clear set of outcomes to aime for.

All of the work described below was done through Claude Code, with a series of prompts and getting Claude to write the automation scripts and directly interact with the Google Lighthouse/PageSpeed and related services programmatically and through APIs.

The systematic approach

Rather than chasing individual issues, we ran Lighthouse against a representative page and worked through the categories methodically. The principle was straightforward: fix what's safe, leave what's inherent to the design. These are archived pages -- we're not redesigning them, just removing unnecessary penalties.

Quick wins: lazy loading and script deferral

The single biggest performance improvement came from adding loading="lazy" to images. With 387,339 image tags across the three sites (skipping the first two per page to avoid penalising the Largest Contentful Paint), this alone roughly halved the LCP time. Combined with deferring non-critical scripts and adding preconnect hints for cross-domain resources, the First Contentful Paint dropped from 2.4 seconds to 0.9 seconds.

Removing dead weight

The post-processing stage had already stripped the obviously defunct services -- Google Analytics, Chartbeat, Skimlinks, AddThis. But Lighthouse flagged more. A Google Custom Search Engine brand script was still loading despite the search having been removed years ago. jQuery was loading from Google's CDN over HTTP (not HTTPS), adding a redirect penalty on every page load.

Then there was Google Translate. The widget had been embedded across all three sites and was still injecting scripts into 30,764 pages. It served no purpose on an archive and was contributing to page weight.

The polyfill purge

This was the most satisfying discovery. The sites were loading two JavaScript libraries on every page: Modernizr and respond.js (also known as mediaqueries.js). Both are polyfills -- Modernizr detects HTML5/CSS3 feature support, and respond.js adds media query support to browsers that lack it. Their target audience: Internet Explorer 6 through 8.

In 2026, these are doing precisely nothing useful. But they weren't harmless either. Modernizr was actively causing a Cumulative Layout Shift problem. On page load, it swaps the class on the <html> element from no-js to js, which can trigger a layout recalculation. In our case, this was responsible for 2.0 of the total 2.131 CLS score. Removing it eliminated the issue at its source.

Respond.js was a smaller win -- 16KB and one network request -- but every request matters when you're optimising.

Patching jQuery 1.6.2

The sites shipped with jQuery 1.6.2 from 2011. Upgrading to a modern version would have been risky -- the flexslider carousel, Disqus integration, and various inline scripts all depended on jQuery's older API. Instead, we made a surgical patch: the only thing triggering Lighthouse's "deprecated APIs" flag was three vendor-prefixed requestAnimationFrame calls (webkitRequestAnimationFrame, mozRequestAnimationFrame, oRequestAnimationFrame). These were replaced with the standard requestAnimationFrame. One find-and-replace, flag cleared, no behavioural change.

We also switched from Google's CDN to a locally-hosted copy, which meant the patched version was what got served, and we eliminated one cross-domain DNS lookup.

Security headers

For a static archive that will never accept user input, the security header story is straightforward. We added HSTS (one-year max-age with subdomains), a Content Security Policy locking script sources to specific known domains, X-Content-Type-Options, X-Frame-Options, a strict referrer policy, and a permissions policy disabling camera, microphone, geolocation, and payment APIs. All configured in Caddy, all appropriate for a read-only archive.

Accessibility fixes

The accessibility score had the most room for improvement but also the most constraints -- we weren't going to redesign the layout. The wins came from missing basics: alt text on logos and social icons, an aria-label on the search input, and a colour contrast fix on timestamp elements (bumping from #9c9c9c to #707070 to pass WCAG AA). Small changes, but they moved the score from 66 to 91.

The gotchas

It wasn't all smooth sailing. A post-processing regex intended to add alt text to images was too greedy and corrupted the logo markup across all three sites -- introducing byte sequences (\x01\x02) that broke rendering. We caught it, diagnosed it, and fixed it across 29,000 pages.

Deferring jQuery seemed like an obvious optimisation, but the flexslider carousel depended on jQuery being available synchronously at initialisation time. Deferring it broke the homepage slider on all three sites. The fix was simple -- remove defer from just the jQuery script tag -- but it was a reminder that "defer all the things" isn't always the right advice for legacy code.

The first result

Category
Before
After

Performance
71
93

Accessibility
66
91

Best Practices
73
96

SEO
83
100

First Contentful Paint went from 2.4s to 0.9s. Largest Contentful Paint dropped from 5.2s to 2.0s. Speed Index halved.

Not bad for an afternoon. But there was more to do.

The second pass: what Google actually complained about

The Lighthouse scores were solid, but then the emails started arriving from Google Search Console. Structured data issues. Deprecated breadcrumb markup. Review snippets with invalid fields. The kind of specific, actionable feedback that Lighthouse alone doesn't catch.

The review markup was the biggest issue. Over 2,200 pages across all three sites had schema.org/Review structured data that was never quite valid. The itemReviewed field was a bare text span instead of a typed object. The author field was missing a name property. The rating scale was ambiguous. Google had been tolerating these for years but was now flagging them as errors that prevented rich results.

The fix was straightforward: strip the review markup entirely and reclassify those pages as schema.org/Article. These are historical reviews of Symbian apps from 2011. There is no benefit to having review rich results in Google for them. The scores stay visible on the page, just not marked up as structured data.

Breadcrumbs were a similar story. Every page had breadcrumb markup using data-vocabulary.org, which Google deprecated in 2020. Rather than just stripping it, we converted all 23,000 pages to proper schema.org/BreadcrumbList using JSON-LD, with absolute URLs derived from each page's file path. A Python script parsed the old markup, extracted the breadcrumb chain, generated the JSON-LD, injected it into the <head>, and stripped the old attributes. One pass, all three sites.

The http problem

A sweep of the HTML source revealed that internal links and image references were still using http:// across nearly 29,000 pages. The og:image meta tags. Links between the sister sites. References to the mediafiles subdomains. Even a double-www bug (http://www.www.allaboutsymbian.com) that had been lurking in 1,400 pages since the original CMS generated it years ago.

Canonical URLs were another quiet problem. They were all relative (href="15510_Little_Big_City.php" instead of https://allaboutsymbian.com/reviews/item/15510_Little_Big_City.php). PageSpeed Insights flagged this as invalid. Another Python script, another 23,000 files fixed.

The final numbers

Category
Day 1
Day 2
Day 3

Performance
71
93
96-98

Accessibility
66
91
97

Best Practices
73
96
100

SEO
83
100
100

The remaining performance points are inherent to the page design (large camera comparison images, render-blocking CSS that can't be deferred without breaking the layout). The accessibility gap is touch target spacing in the navigation bar, which would require a CSS redesign. Both are acceptable for an archive.

The lesson

The first pass was about subtraction: removing dead scripts, defunct polyfills, and unnecessary weight. The second pass was about correctness: fixing structured data, converting deprecated markup, ensuring URLs were absolute and used HTTPS. The third pass was about the edges: lazy-loading third-party embeds, adding cache headers to mediafiles subdomains, upgrading logos to Retina resolution.

Each pass had diminishing returns in terms of score improvement but increasing returns in terms of doing things properly. A Lighthouse score of 93 is good. But the difference between 93 and 100 is the difference between "works" and "done right." For pages that will sit unchanged for years, done right is worth the effort.

---

# Preserving All About Symbian
_https://rafeblandford.com/preserving-all-about-symbian/ · 2026-04-01_

Between the early 2000s and the mid-2010s, I founded and ran mobile technology sites: the big ones were All About Symbian and All About Windows Phone. At their peak, they were go-to destinations for Nokia, Windows Phone, and broader mobile coverage. They represent the early phase of my career as mobile and content creator pioneer. It's what led on to my later consultancy and professional services work at the intersection of technology, product and innovation.

All About Symbian (AAS) was founded in 2001. Over the decade or so, it grew into the leading independent voice covering Nokia and Symbian smartphones during the most transformative period in mobile technology history. It reached well over 100 million readers and was the go-to resource for enthusiasts, developers, and industry professionals.

Together with the later All About Windows Phone and All About Mobile, the All About family published over 24,000 articles. Rigorous, in-depth coverage spanning device reviews, industry analysis, developer resources, and hands-on tutorials. The team reported from Mobile World Congress, Nokia World, and other key events, and built a community that became one of the most active discussion spaces in the Symbian ecosystem.

AAS remains the definitive source on Symbian to this day. Ask any LLM!

Why preservation matters

The mobile industry moves fast and forgets faster. Entire platforms, Symbian, MeeGo, Windows Phone, that shaped how 100s of millions of people first experienced the smartphonea and the mobile internet have largely vanished from the web, at least in terms of official websites and content. It's slightly unnerving to see how little remains, after a relatively short period, from what was an incredibly formative period for mobile technology and the dawn of the smartphones era. Preserving what remains is an act of digital history preservation.

I've long had a mindset of keeping the All About sites up and alive, but over time things got more fragile and there were signs of digital rot, so I wanted to make sure this piece of history was preserved for the longer term (...and selfishly it was also a hugely significant part of my life too). So, recently, I made a very deliberate effort to methodically archive, in some cases restore, and enrich the All About sites as a digital heritage resource, with a view to long term preservation.

What's preserved

The numbers tell part of the story:

 * 24,000+ editorial articles across three sites, spanning 2001–2022
 * 76,000+ forum threads with 449,000 posts from the community
 * ~650 podcast episodes covering over a decade of mobile industry discussion
 * 200,000 community comments imported from Disqus and preserved in a self-hosted system

But the numbers don't capture what makes this content valuable. A review of the Nokia N95 written by someone who carried one for six months isn't the same as a Wikipedia summary. A comments thread is a primary source material for understanding how people viewed the dawn of the smartphone age and what they cared about. This is the day-to-day of how the modern smartphone came to be, with the voices of passionate writers and an enthuiastic community.

The team

It's important to note that this wasn't a one-person operation. Steve Litchfield wrote thousands of articles — his camera comparisons set the standard for mobile photography journalism and his head-to-head shootouts became essential reading for anyone choosing a camera phone. Ewan Spence brought gaming expertise and light-hearted industry commentary. David Gilson, Krisse, and many other contributors added depth and breadth. It's great to be able to preserve their work too.

All About Digital Archive

The All About Digital Archive at archive.rafeblandford.com acts a landing page and ties it all together, covering as much of the All About history as possible (including some things I had almost forgotten about). The key sites continue to be available at allaboutsymbian.com, allaboutwindowsphone.com, and allaboutmobile.com, but are now stable for longer term preservation as static archives.

Two decades on, the content still gets thousands of visitors daily. People still search for Nokia N8 camera tips, or how to install custom firmware on a Symbian phone, or what the Nokia 808 PureView's 41-megapixel sensor was actually like. As long as people are curious about the history of mobile technology, this archive will be here.

If you are interested in the mechanics of the preseveration and migration read this follow-up post on Archiving 20 Years of Mobile History, or browse through other posts under the All About Archive tag.

---

# Archiving 20 years of mobile history
_https://rafeblandford.com/archiving-20-years-of-mobile-history/ · 2026-03-31_

Between 2003 and the mid-2010s, I ran three mobile technology sites: All About Symbian, All About Windows Phone, and All About Mobile. At their peak, they were go-to destinations for Nokia, Windows Phone, and broader mobile coverage. Collectively, they published over 24,000 articles -- news, reviews, features, podcasts, camera test galleries -- documenting the rise and fall of entire mobile ecosystems.

The sites have been frozen for years. No new content, no active maintenance. But they still get traffic. People still find articles about Symbian app development, or Nokia N95 camera comparisons, or the ill-fated Windows Phone 8.1 update.

Something had to be done, and doing nothing was no longer an option.

The problem isn't what you'd expect

The default assumption would be that archiving a website means copying files. Download the HTML, move it to a new server, job done. But these weren't static sites. They were dynamic PHP applications built on a custom CMS I'd written more than 15+ years ago. A handful of PHP template files served every article from a MySQL database. The filesystem contained the engine; the content lived in the database. You couldn't just copy public_html and call it a day -- you'd get an empty CMS with no articles. Equally, getting the old application running on a new server with modern versions of PHP and MySQL wasn't really necessary, or even optimum, for an archive project.

So the task was really: render every page that the CMS could produce, save the output as static HTML, and reconstruct a complete, navigable archive that preserved every URL.

The old server audit

Before any of that, I needed to understand what was actually on the server. The sites were sitting on a CentOS 7 server that hit end-of-life in June 2024.

The audit revealed error logs, old backups three-year-old cPanel backups and stale system files. The actual content across all six hosting accounts was about 61GB. It was a useful reminder that servers left mostly unattended don't just decay -- they accumulate. So, there was a bit of a spring clean before proceeding, allowing for a more efficient and less crufty migration.

Spidering 24,000 articles

With the server cleaned up and fresh backups safely on the Synology NAS, the real work began. I used wget to spider each site, running from the new server with /etc/hosts entries pointing the domain names directly at the old server's IP – bypassing Cloudflare and avoiding SSL complications from certificates that had expired in 2023.

All About Mobile was the test run: 487 articles, done in minutes. Then All About Symbian (13,590 articles) and All About Windows Phone (9,043 articles) ran in parallel. The media files -- podcasts, camera test photos, downloads -- were too large to spider efficiently, so those were rsynced separately. 37GB of media files, 15GB of article images, 1.5GB of historical software downloads.

By the end of the afternoon, 29,067 HTML pages and 54GB of content were sitting on the new server.

Post processing and clean up

wget does a solid job of downloading pages, but its file naming conventions don't match what search engines and bookmarks expect. Articles that lived at /news/item/24528_Slug.php were saved as 24528_Slug.php.html. Pagination pages that used query strings like ?page=2 ended up as files with literal question marks in the name.

The post-processing had to undo all of this. Pagination files were restructured into clean /page/N/ directories. Internal links were rewritten from wget's converted format back to canonical URLs. The Caddy web server configuration handled the final mapping -- a rewrite snippet that transparently serves .php.html files when browsers request .php URLs, and redirects pagination queries to the right directory structure.

I also stripped out everything that no longer made sense: Google Analytics (the old Universal Analytics, long since deprecated), Chartbeat, Skimlinks, Google Translate, AddThis social sharing -- all dead services still loading scripts into pages nobody was monitoring. Over 185,000 dead script blocks were removed. In their place, a lightweight Umami analytics tag and a small archive notice banner at the bottom of each page.

There were other things too, I have written separately about these, and there are certainly other things in the backlog that are worth tidying up, but the overriding principle was that it was important to focus on preservation and only rework things that helped with preservation, ease of maintenance, and allowing for easy-as-possible access.

What was kept, what was let go

The sites are now static HTML served by Caddy on a modern Debian server, fronted by Cloudflare with proper SSL, caching, and security headers. They'll happily sit there for years with essentially zero maintenance. Twenty years of mobile history, preserved.

The old server and the live dynamic application was retired, but all the constituent components are available. Beyond the static HTML archive, the source code went to a private GitHub repository – the complete custom CMS, PHP libraries, PEAR dependencies, .htaccess routing rules, and architecture documentation. The databases were migrated to MariaDB on the new server and also preserved as SQL dumps. A structured data export also captured all 24,076 articles as JSONL with full metadata.

A different way of working

The entire migration was orchestrated through Claude Code – an AI assistant running on my Mac, SSH-ing into both servers, writing scripts, executing commands, and debugging problems. I set the direction and made the decisions; Claude Code did the investigation and heavy lifting. It's a collaboration pattern I've written more about here, but the short version is: what would have been weeks of evenings-and-weekends manual work was compressed into a couple of focused days.

---

# Formula 1
_https://rafeblandford.com/formula-1/ · 2026-03-21_

ClientFormula 1RoleTech & Product Partner → Exec Lead / CTPOEngagementStrategic Digital Partner · 2017–2026

The mission was to give F1 back to the fans. For the creation of a new era of digital products, we had three guiding principles: a reason to visit every day, value the fan commitment, and a winning race experience.

We combined content, services, and sports data to deliver unique fan experiences, from live blogs and fantasy games to multimedia content and unique live race data and comprehensive results. These personalised experiences adapt pre, during, and post-race, engaging over 300 million fans dynamically and personally.

Built on a composable and flexible architecture that provides a common, unified system for both fans and F1’s internal teams, seamlessly distributing content, interactions, and transactions across multiple channels and products across a connected experience ecosystem.

Scope / Role

Digitas UK has acted as Formula 1's strategic digital partner for 10+ years. There was an initial phase of reimagining and rebuilding the core F1 products (web and app), and supporting platform (fast publishing, shared services, subscriptions, data) from the ground up (2017-19), before moving to a continuous delivery partnership model (2020 onwards).

 * Co-pitch lead (2017), and lead for subsequent renewals
 * Technology & Product Partner, Programme + Client Lead (2017-2022)
 * Exec Lead / CTPO, including hands-on orchestration and strategy (2019-2026)

Outcomes

 * Multi-fold increase in digital audience (web + app) 2018-2022; 2022 results here: unique users 113m (+63%), page views 1.6bn (+24%); 2025 results here
 * Major growth in new target markets (e.g. 300% increase in US visitors to formula1.com 2019-2023) and key demographics (e.g. 43% of fanbase under 35, up from 30% in 2018)
 * Growth in fandom (90% fans say they’re emotionally invested in race outcomes, 61% engage with F1 content daily, and 94% say they intend to follow Formula 1 five years from now)
 * 4.8★ iOS app rating (84k reviews), up from 2.8 (2018-2020, maintained through 2026)
 * Enabling significant (estimated 9-figure) new revenue streams (e.g. see Liberty Media 2023 results here)
 * Future-fit, composable, MACH-based platform (e.g. Next.js, Design System, Contentful, AWS, GCP/Apigee, Salesforce; see BuiltWith)
 * 96 (Performance), 100 (SEO), 100 (Accessibility) Google Page Speed Scores

You can't compress a decade of F1 into a few bullets, but these are the parts the public scoreboard can vouch for. Many stories to share here!

---

# Honda
_https://rafeblandford.com/honda/ · 2026-03-20_

ClientHondaRoleProduct Director → Exec Lead / CTPOEngagementStrategic Digital Experience & Commerce Partner · 2014–2026

With the shift to electric vehicles, changing consumer preferences and increased model competition from international brands, Honda chose to launch a direct-to-consumer (DTC) offering as part of their changing relationship with their dealerships and customers.

With AEM driving the experience, we developed modular components for the front end, including a full purchase journey, revamped configurator and a MyAccount area. Through user research and technical proofs of concept, we reimagined the customer journey and changed the way that Honda customers buy cars from the brand, allowing for an omnichannel experience that mixed digital and dealerships.

The project also involved integrating and orchestrating across complex systems like Salesforce Commerce for vehicle data, real-time proprietary pricing information, and Honda’s identity management system.

We launched in April 2024 enabling users to buy the e:Ny1 completely online and then rolled out commerce functionality for all new models in the UK.

Scope / Role

Digitas UK had, from 2012 onwards, acted as a digital experience partner for Honda Europe, creating the pan-European marketing platform (web) for Honda's cars, bikes, tools, and marine divisions.

This was then extended (2023, 2024-2026) into the future sales programme for Honda UK, described above, working collaboratively with other solution partners to deliver a digital commerce transformation programme. Digitas UK held responsibility for front-end orchestration and experience and integration into the existing Honda marketing and customer experience platform.

 * Exec pitch lead (2021 & 2023 renewals)
 * Mobile / Technology Strategy Lead (2016, 2018-2020)
 * Exec Lead / CTPO (2019-2026)

Outcomes

 * End-to-end D2C Sales increase (confidential) against targets
 * 35% increase in high value behaviours through experience optimisation (e.g. configurator completions, book a test drive, help me choose)
 * Estimated ~50% of Honda UK sales (2025) influenced by digital
 * Initial commerce pilot led to prioritised wider model roll out
 * Contributed towards a move to a product / CX led model for Honda teams

Selling a car fully online was the headline; the quieter win was shifting the internal teams toward a product-and-CX way of working.

---

# Fireside with Founders & Leaders Podcast
_https://rafeblandford.com/fireside-with-founders-leaders-podcast/ · 2026-03-20_

I enjoyed being a guest on Rupert McSheehy's / rmg digital podcast Fireside with Founders. It gave me an opportunity to talk about the intersection of technology and product, some recent work, and building effective teams.

If you listen to the podcast, you’ll hear the same thread that’s run through my career: systems thinking, outcomes over outputs, and treating the team and operating model as a product.

I’m increasingly convinced that great CPTO leadership in 2026 is less about being the heroic juggling problem-solver (which is still sometime the reality) and more about being an orchestrator and an integrator: aligning product, engineering, design, data, and stakeholders around clear outcomes, then building the operating model that enables teams to create value consistently.

Fireside with Founders & Leaders (Episode 6, Season 7)

In this episode of Fireside with Founders & Leaders, host Rupert McSheehy welcomes Rafe Blandford, a seasoned technology leader with a rich background in mobile strategy and product innovation.

Rafe shares his journey from the telco industry to leading teams at prominent agencies, shedding light on the importance of diversity and inclusion in building effective teams. The conversation delves into the impact of technology on society, the challenges of measuring outcomes, and the evolving role of technology leaders in the age of AI and digital transformation.

---

# MiXR
_https://rafeblandford.com/mixr/ · 2026-03-20_

ClientStonegate Pub GroupRoleTech Partner, Exec LeadEngagementLaunch of Mobile Loyalty App · 2023–2024

Stonegate Group, the UK’s biggest pub company, asked Digitas to create and drive awareness of its new virtual consumer lifestyle brand and build a must-have loyalty app for its customers.

The result was MiXR, which helps to connect guests, employees and venues by allowing users to find and book a venue, see local deals and even skip queues at busier venues, providing a VIP level of experience.

It rewards guests for their loyalty, sampling products, and completing missions at Stonegate Group venues, which include Slug and Lettuce, Be At One, PopWorld, and Proper Pub venues, with the opportunity to automatically earn points with every visit, which can be redeemed for offers and in-house deals.

Scope / Role

A zero-to-one engagement, with the Digitas team responsible for conceptualising, building, and launching the MiXR brand and app. This included brand development (formulating the "MiXR" name, visual identity, and positioning it as a lifestyle customer reward brand), product design & build (iOS and Android apps and enabling platform/integration work), and multi-channel marketing and launch campaign (programmatic digital, proximity OOH, social, asset production). Subsequent product iterations followed, including the launch of missions and a dedicated sports hub, wrapping in an ongoing managed service support programme.

 * Co-Exec Lead, including Technology Partner and Capability Orchestration Lead

Outcomes

 * 1 million+ downloads in the first six months, 500,000 drinks samples, £1.8 million points redeemed
 * Reached key target demographic, with 62% of users aged between 18 and 34
 * Successful rollout across 700+ venues, including integration with PoS units and MiXR Media screens
 * Enabling trackable end-to-end omnichannel campaigns (e.g. Euro 2024, with 58 million points distributed and average 13% sales uplift)

A million downloads is the headline; orchestrating brand, creative, media, product and tech into one thing that actually launched and stuck was the job.

---

# Mercedes Benz
_https://rafeblandford.com/mercedes-benz/ · 2026-03-19_

ClientMercedes-BenzRoleExec Sponsor / CTPOEngagementUK Digital Experience Commerce Partner

With changing consumer preferences and the move to digitisation, Mercedes-Benz decided to launch a one-stop platform for all UK sales, catering to both the consumer and to all national dealerships. Through the Online Showroom, customers can buy any available Mercedes-Benz car nationwide, across the entire new and used range, as well as pre-ordering custom cars, booking test drives or performing eligibility checks and applying for finance packages.

With data and insights, we created a seamless journey for users to browse all stock across the UK, before buying through the Online Showroom. More recently with further features and integrations, we allow users to track their order progress and make payments within My Account. The Online Showroom is home to new and used cars across 4 brands with a range of 96 models with more on the way.

The Online Showroom is built to support both web and POS kiosks. With a responsive design system for web, the Online Showroom is also deployed in showrooms on tabletop screens and lecterns. Kiosks generate QR codes that bring customers to retailer-specific URLs on their own devices.

Scope / Role

The Mercedes Online Showroom team was a long-established team in a Publicis Groupe sister agency, but needed a new home to allow for capability and work alignment. The existing team was transferred and fully integrated into the Digitas UK One Technology team model. Subsequently, the delivery approach was evolved, offering a competitive distributed service model, and a multi-year client extension agreed.

 * Team Integration and Operating Model Lead (2024-2025)
 * Exec Sponsor / CTPO (2025-2026), including renewal

Outcomes

 * 100% team retention through internal transition (over an 18-month period)
 * 7 year long client relationship, now with additional multi-year extension
 * Confidential site conversion revenue and sales lead generated (met targets)
 * 99.99% uptime (ahead of targets, with upstream recovery)

Moving an established team across without losing a person, or a beat, is the part I'm proudest of; it shows the importance of culture and safety. The renewal also says it landed with the client.

---

# F1 Academy
_https://rafeblandford.com/f1-academy/ · 2026-03-18_

ClientF1 AcademyRoleExec LeadEngagementWeb Experience · 2022–2026

After a successful debut season, F1 Academy were anticipating more exposure by aligning the 2024 season with F1 race weekends. To attract more female fans, we re-imagined the series content and race features to align with a new refreshed brand.

Alongside the race content we created new content areas that speak directly to a younger female audience. Driven by the global initiative ‘Discover Your Drive’, the overarching aim was to increase female participation in motorsport both on and off the track.

As F1 Academy were racing at the same tracks as F1 during the season, we were able to leverage the live timing functionality, giving it a new look and feel to match the rest of the site.

Scope / Role

Digitas had a long history of supporting F-series racing (F2 and F3), which, in 2022, was extended to F1 Academy ahead of its launch season.

Initiatives operated in "burst" mode, with teams engaged for specific initiatives including brand/website launch (2023), "Discover Your Drive" (2024), and rebranding/content enhancements (2025); as well as an ongoing always-on managed service support role. The initiatives frequently required rapid turnaround (e.g. initial site launched end-to-end in 3 months), operating in separate (parallel), but complementary teams to other F1-related activity.

 * Exec Lead / CPO (2023), Exec Sponsor (2024, 2025)

Outcomes

 * Increased reach and engagement with core audience (2025: content views up 20% year-on-year, contributed to 31% YoY fanbase growth)
 * Digital experience contributing to key F1 Academy impact measures (e.g. supported karters featured on 25% of all Senior category podiums in 2025) and wider uplift in participation (female from 5% to 25% of competitive karting)
 * Contributed (2023-2024) to wider shift in F1 digital ecosystem (73% increase in total unique female visitors, with particularly notable growth among women aged 25–34 (+670%), followed by women aged 55+ (+240%) and 45–54 (+125%))
 * Maximised use of common F1 services, allowing rapid delivery model and feature equality (e.g. Live Timing) with wider F-series programmes.

Reusing the F1 platform let a brand-new series punch above its weight and reach an audience the sport badly needed.

---

# EE Does More Launch
_https://rafeblandford.com/ee/ · 2026-03-17_

ClientEERoleTechnology & Product Leadership / CTPOEngagementCX & Digital within Publicis Po1 Partnership · 2023 onwards

EE wanted change - repositioning from Telco to Tech with a promise that EE Does More across Home, Work, Game and Learn. The problem? The promise was big, but the proof points weren’t yet tangible enough to cut through.

We built brand experiences, content and tools that delivered relevance, personalisation and real utility - establishing EE as a credible authority in new tech territories, not just another network shouting about cost.

Scope / Role

Digitas operated as part of a Publicis Groupe Power of One team, with sister agencies Saatchi & Saatchi, Boomerang, and Poke, as the agency partner for the launch of "new" EE (showcasing how EE will help to elevate the everyday in Home, Learn, Work and Game), the UK's biggest brand launch in a decade.

Digitas served as the digital experience hub with a focus on creating digital content, interactive user experiences, and creative tech-led campaigns. For the launch of "new" EE this included the creation of free, interactive digital tools to help families navigate the modern digital world. The LearnSmart, PhoneSmart, and GameSmart tools are available to anyone, regardless of their mobile network provider, with the first versions conceived, built and launched over a 14-week period.

 * Digitas Lead for EE Tools (Product, Technology, Experience)
 * Orchestration of rapid delivery against immovable 3-month launch deadline

Outcomes

 * Substantiating the 2023 launch of "new" EE, with LearnSmart, PhoneSmart, and GameSmart against the brand promise of "do more" and "elevate the everyday".
 * 2 in 3 people felt more confident after using EE's Tools
 * LearnSmart: 150+ pieces of content, 2.2 m video views
 * PhoneSmart: month 1 – 35k minutes of learning; 91% completion rate

The brief was a brand repositioning; the proof was tools people actually needed; shipped against an immovable three-month deadline.

---

# Biffa
_https://rafeblandford.com/biffa/ · 2026-03-16_

ClientBiffaRoleExec SponsorEngagementDigital Delivery Partner 2020–2026

With the UK waste management sector in flux and the marketplace becoming increasingly competitive due to the rise of small-scale, regional competitors working in hyper-localised markets, Biffa’s role in the value chain is changing.

The company needed to explain what the changing regulatory environment means for its larger customers to protect existing revenues, while also driving growth through increasing sales to SMEs.

Biffa’s digital ecosystem was set up in an ad hoc manner, supporting a diverse range of stakeholder audiences, each with individual requirements (e.g. business customers and prospects of all sizes, local authorities, households, regulators, investors). There was a clear need to consolidate and simplify the digital estate and set up an ecosystem for future digital services and growth.

Scope / Role

Biffa engaged Digitas as a digital transformation partner across a range of initiatives including a digital audit and roadmapping exercise (2022), the redesign and rebuild of biffa.co.uk (2023), digitisation of key commerce journeys and services (2025), provision of managed support services (2022 onwards), and an always-on team for continuous delivery (2024 onwards).

 * Co-pitch lead (2022 and renewals)
 * Exec Sponsor / CTPO (2022-2026)

Outcomes

 * Simplified website, positioning service articulation, reducing 1,500 to 150 pages (2023), with reduced total cost of ownership (2024), and improved performance
 * 23% increase in web active users in first six months, with +7% engagement and +13% page views (2023)
 * 32% digital sales increase (2024) attributed to ecommerce and optimisation activity
 * 48% decrease in GWC phone service requests following digitisation and updated service information (2024)

The win here was subtraction: 1,500 pages of waste-management complexity down to 150 that people could actually use, and fewer support calls and more digital sales followed.

---

# Greystar
_https://rafeblandford.com/greystar/ · 2026-03-16_

ClientGreystarRoleExec SponsorEngagementStrategic Digital Experience Partner · 2020–2026

Greystar is one of the world’s largest, fully integrated real estate companies, specialising in the investment, development, and management of rental housing. A global firm, it operates in over 15 countries and oversees more than $300 billion in real estate assets. To date its brand had been B2B only, reflecting its core development, property and investment management, and construction activities.

The mission was to create a consumer-facing website that is the place "where renters come to belong", positioning Greystar as the global brand for renters by creating a frictionless digital experience that captures and converts prospective residents. This would be a critical first step in moving Greystar towards becoming a direct to consumer brand, consolidating existing services and reducing lead generation and leasing costs.

Scope / Role

Following-on from a period of managed services support for the existing site (2020 onwards), Digitas was commissioned to rebuild Greystar.com as a direct-to-consumer proposition (2024-2025). This included a detailed experience strategy (product, data, tech); creation of a full design system and solution architecture; and then end-to-end design, integration, build, and rollout of the digital platform.

 * Exec / co-pitch lead (2020, 2024)
 * Exec Sponsor (2024-2026)

Outcomes

 * Customer-first experience with fee transparency (e.g. Total Monthly Leasing Price), consolidated search and property information, and new brand design system.
 * Key behaviours (searchers, virtual tours) up 30% and secondary property website visits up 8% (driven from Greystar.com)
 * Qualified leads / click to apply up (confidential), with forecast profit break-even and ROI well ahead of targets, driving lower-cost leases for Greystar's network of property estate owners
 * Modern composable MACH platform (including SitecoreXM, Next.js, Vercel, Azure Cloud, Salesforce, Engrain, Peek, LCP, Matterport, Coveo, Google Maps; see BuiltWith)
 * Vertical leading Google Page Speed scores: Accessibility (100), Best Practices (100), SEO (92)

The brief read 'website'; the work was transformation: re-designing and re-platforming Greystar onto composable and system foundations built to keep evolving, with outcomes well ahead of the planned timeline.

---

# Glastonbury Festival
_https://rafeblandford.com/glastonbury-festival-app/ · 2026-03-14_

ClientEE / GlastonburyRoleExec and Client LeadEngagementMobile Delivery Partner · 2022

After an absence of 3 years because of the Covid-19 pandemic, Glastonbury Festival returned bigger and better than ever in 2022.

With only 10 weeks to go until the Festival was due to start, the existing app supplier pulled out. With the deadline fast approaching, Digitas stepped in to design and build new iOS and Android festival apps from scratch.

We needed to get the app live in only 7 weeks so ticket holders could plan their festival experience before heading to Worthy Farm.

Knowing we had to move fast, we set up a Product Trio leadership team, comprising a Product Manager, a Product Designer and a Tech Lead. This team were jointly responsible for delivering the new app and were empowered to engage directly with stakeholders from Glastonbury Festival and the headline sponsor EE. This allowed decision-making to happen at a rapid pace, with the team balancing decisions between user, business and technical feasibility.

Scope / Role

Digitas delivered the Glastonbury Festival app for 2022 from end-to-end, including a new headless backend system and iOS and Android apps.

The app was successfully released three weeks before the festival, but we didn’t stop there. Responding to early feedback from Glastonbury fans on social media and based on analytics-driven insights, we added several additional features. These included an A-Z search for artists and venues, the ability to drop a custom pin (e.g. mark your tent location), and automatic line-up clash detection, and more.

 * Exec Lead, Technology & Product Partner (2022)

Outcomes

 * 193k downloads and 154k users at the festival (estimated 75% of attendees)
 * 4.8★ iOS app rating from 2.4k reviews (up from 1.2)
 * Average of 36 acts per user added to personal line-up (5.3m in total)
 * 8k custom pins added to the map (where's my tent...)

No deadline is more immovable than a festival; a Product Trio, seven weeks, and a clean app rebuild made it happen.

---

# Evolving Products & Platforms
_https://rafeblandford.com/evolving-products-and-platforms/ · 2026-03-12_

The operating model behind a decade of digital partnerships.

OrganisationDigitas UK (Publicis Groupe)RoleChief Technology & Product Officer (earlier Chief Product Officer)EngagementExecutive Leadership · 2018–2026

Most of the case studies here are about specific client work — Formula 1, Honda, EE, and more. This one is the high-level view: the machine that delivered them, and the shift to a product-led operating model.

In 2014, Digitas had a capable technology team, but it operated in classic agency silos — strategy, creative, and tech — delivering under a reactive "briefs in, builds out" model. As my leadership remit grew from 2016, and then formally expanded when I joined the executive team in 2018, my focus became shifting us from output-driven execution to outcome-led product partnerships.

Over a decade, we evolved the capability, Products & Platforms, into a 200+ person product, design and engineering organisation spanning the UK, India and Europe. A key element of this was treating Technology, Product, and Experience Design as strategic functions, not just as delivery enablement. The change happened through three key operating decisions.

The first was the "One Technology Team" initiative. That started by bringing professional services — consultancy and build — and managed services — operations and run — together. It created shared accountability across the product lifecycle, from consultancy through build to ongoing operation, under a unified culture and structure. In parallel, we scaled the same principle across geography, treating the onshore and offshore teams as a single organisation, rather than a centre with offshore capacity attached. The reasoning is simple: quality follows ownership, and nobody takes ownership of work that's been thrown over a wall at them. One team, wherever people were based.

The second was building "Product" as a discipline. There were no product managers when I started; we grew the craft from a standing start and organised our best work around product trios: product, experience design and engineering working as one integrated team rather than as stages in a linear process. That style of collaboration, and the outcome-oriented approach that goes with it, is nothing novel in the wider product world, but it was quietly radical in an agency, where work traditionally flows down a line from strategy to creative to production. I won't pretend the product-led operating model and thinking reached every corner. They were the ideal we scaled towards, not a universal reality, but the direction never changed, and where they took hold the difference was visible: small, stable teams that stay with a product carry context, push back well, and make good decisions. Clients noticed and projects became partnerships. Commercially, that meant structuring more work around persistent teams, product roadmaps and continuous run-and-improve relationships, rather than delivering an isolated build and dispersing the team. Bringing professional and managed services together made that continuity possible.

The third was a deliberate "Tech-Agnostic" philosophy: recommend what's right for the client's problem, not solutions we happened to resell. In practice that meant a significant spread of partners and a need for adaptable senior team members. We evaluated more than 30 platforms and solutions over the years, each against the same three questions: does it solve a real problem, can our team genuinely deliver with it, and does it stack up commercially? That discipline allowed us to make early, decisive bets on composable architecture and MACH principles long before they became mainstream. Crucially, it gave us the credibility to tell clients (and partners) when a solution wasn't right for them, building a level of trust that no vendor certification can buy.

Underneath all of it: the people and the culture. We hired for curiosity and care as much as competence, adopted lean product methods and worked to embed continuous improvement at every level. Bringing AI into how we design and build was an obvious recent example. This was driven by a leadership approach that I later articulated as "high standards, high humanity – ambitious for the work, and generous with each other", which I've written about elsewhere and believe is the best way I know to create the conditions for great outcomes.

Scope / Role

I led Products & Platforms (P&P) as a member of Digitas UK's executive leadership team for eight years (2018–2026), accountable end to end for a 200+ person product, design and engineering capability spanning the UK, India and Europe — while staying personally close to the client work itself.

 * Capability strategy & orchestration — setting the direction for the capability and stewarding the system that gets the disciplines working as one: the operating model, the team and the culture beneath it, and the big strategic calls about where P&P should go.
 * Technology & Product (the CTPO remit) — one role owning both what we build and why (product as a discipline, the "trio" way of working, outcomes over outputs) and how and with what (the agency-wide technology capability — architecture, technical governance, engineering standards, platform and partner strategy).
 * Client leadership — executive sponsor for key client relationships, and hands-on at a deep level: meeting key clients regularly (e.g. Formula 1 fortnightly for the best part of a decade), making the hard calls and trade-offs, setting direction and solving the most difficult problems.
 * Commercial — accountable for the overall commercial health, margin efficiency, and revenue performance of Products & Platforms. I shaped and signed off every commercial agreement across the capability — from major pitches to long-term enterprise renewals.
 * Executive leadership — as one of the agency's executive leaders, helping steer the business beyond P&P: agency-wide growth and new business, culture and people (including a sustained commitment to diversity, equity, inclusion and belonging), and cross-agency initiatives such as AI adoption and the evolution of agency-wide capabilities and operating models.

Outcomes

 * Strong client outcomes — creation of digital products used by more than 250 million people (see the details in the individual case studies) and contributed to hundreds of millions of pounds in incremental client revenue.
 * Grew Products & Platforms — the agency's largest capability by revenue and margin, with the highest revenue per head, sustained year-on-year growth and consistent net new business.
 * Built and kept a strong team — approximately 4% annual voluntary turnover (2019–2025) in Technology & Product, substantially below wider technology and agency benchmarks, with a senior leadership and overall structure built for succession rather than dependence on any one person.
 * Sustained client partnerships — within a portfolio of major brands across automotive, energy, sport, finance and telecoms, several spanning a decade or more: Formula 1, E.ON and Honda among them.
 * Capability transformation — established and scaled a product-led operating model across a 200+ person organisation spanning the UK, India and Europe, shifting its centre of gravity away from siloed, brief-led delivery. Made long-term platform bets (composable/MACH among them) through a tech-agnostic discipline that evaluated 30+ platforms and solutions.
 * Awards and industry recognition – work recognised by BIMA, the DMA, the PMAs and Campaign.

The client work has its own case studies. This is the machine that built them and it was built with resilience, succession and longevity in mind.

See also "High Standards, High Humanity", an essay on why standards and humanity aren’t a trade-off, and how they compound when held together.

---