Things I want to remember

The interesting part of agents isn't simply that software can now do more on its own. It is deciding what we're prepared to delegate, how that work is constrained, how we know whether it succeeded and where human judgement still belongs.

I'm drawn to systems that make authority, evidence and failure visible; that separate doing from judging; and that treat verification as part of the design rather than something added when the agent gets things wrong.

Repos I'm keeping close: Microsoft Agent Framework, Superpowers, Agent Skills, smalltask, ArcKit, Paperclip and the Fabric Data Agent testing template.

I like this partly because it is dated. It records a particular mental model of LLMs at the start of 2025: startlingly capable in some directions and strangely weak in others. The useful thing now is not whether every prediction survived, but having a timestamped view of what the boundary felt like at the time.

It is easy to spend years improving the machinery of a top-down model without asking whether the model itself is the problem. I saved this because it widens the design space. Sometimes the useful improvement is not a better version of the same service arrangement.

Derbyshire isn't abstract to me. My grandparents were from Hathersage and I've traced my Hickinson line there back to the seventeenth century. Going down this rabbit hole was a reminder that the county which feels so fixed on a modern map wasn't fixed at all. Mercia came and went, boundaries moved and identities changed. The family feels rooted there; the place itself has never stopped changing.

The model gets most of the attention, but the useful architecture is often around it: a boundary that lets inputs, providers, policy and behaviour change without rebuilding everything that depends on them. This was an early example of treating generative AI as one component behind an interface rather than the system itself.

Bad service design is not always an accident waiting for a better designer. Sometimes the friction protects a budget, transfers work, discourages demand or serves an organisational incentive. That changes the problem. You cannot redesign the interface properly without understanding who benefits from the current pain.

Local variation matters, but not everything needs to be locally unique. I keep coming back to the boundary between common foundations and the places where local difference genuinely improves the service. Getting that boundary wrong either recreates the same plumbing everywhere or standardises the bits that ought to remain close to place.

The title is deliberately provocative, but the useful point is practical. Governance that lives mainly in policy packs, boards and approval stages can become theatre. The real test is whether people know who can decide, what good looks like and what happens when something goes wrong.

Top-down sponsorship matters. Grass-roots capability matters. There is still a large space between them where ambition has to become everyday behaviour. Middle layers translate priorities, allocate time, interpret rules and decide what people are actually allowed to do. Any literacy effort that misses that layer is missing part of the system.

Shared definitions matter, but that does not mean every part of an organisation must use one universal definition for everything. Different meanings can coexist when the context and boundaries are explicit. The danger starts when we pretend the differences are not there.

The version of optimism here is more interesting than positivity: problems are soluble when we can create better explanations and correct our errors. Knowledge is never finished, but that is a reason to keep improving it rather than a reason to give up on knowing anything.

Corporate language can become a membership test. We say we want different voices, then make people translate themselves into the same dead dialect before we take them seriously. The bit worth watching is when shared language stops helping people understand one another and starts helping them avoid saying anything precise.

Detroit has always been my bag. I was deeply involved in dance music when I was younger, DJing and promoting, and I've never really lost the obsession with that late-eighties/early-nineties period: Chicago house, Detroit techno, the records travelling, and what happened when those sounds landed somewhere else. The UK turned that imported energy into its own Acid House explosion; Berlin took techno in another direction again. Delano Smith's mix feels connected to that lineage without sounding like a history lesson. I saved it because I still love the energy of the thing.

Notice, collect, share. It is almost embarrassingly simple, which may be why it works. Paying attention creates raw material; collecting gives ideas time to collide; sharing changes what you notice next. This is very close to what I want Commonplace itself to do.

A data strategy can become a strangely self-contained world: priorities, principles and roadmaps that make sense internally but are weakly connected to what the organisation is actually trying to do. Sometimes the data strategy is unclear because the wider strategy is unclear. More detail in the data document will not fix that.

Dashboards assume a person will keep coming back to look. Increasingly the system can watch, detect and bring something forward instead. That does not remove the human role; it changes where judgement enters. I want to keep an eye on that shift as analytics becomes less about visiting a screen.

“Legacy” is too easily used as a synonym for old technology. The harder legacy is often the process, contract, dependency or habit built around it. Replacing the application while preserving everything that made it difficult can leave you with a newer system and much the same problem.

I'm interested in the boundary here more than the conclusion. Scientific observations can raise metaphysical questions without science itself settling the metaphysics. Mystery is not evidence for whichever explanation fills it first. But mystery is still allowed to be mystery.

Proof of God sits in the same pile for the same reason.

Governance should make risk and decisions easier to see, not simply add another queue for work to pass through. I saved this because the most useful governance helps delivery teams understand the boundaries, surface the hard decisions early and move with confidence. Approval machinery can look like control while making the system less able to respond.

Money laundering is a useful place to see the difference between having controls and achieving the outcome those controls were meant to produce. A system can become very good at demonstrating compliance while the behaviour it exists to stop simply routes around it. That tension travels well beyond financial crime.

Reorganisation can consume enormous energy just moving boxes and responsibilities around. The more useful question is whether the change creates an organisation better suited to how people, services and technology actually work now. A new boundary is a poor reward if the operating model inside it is mostly inherited.

I have mixed feelings about the language of personal brand because it can turn useful work into performance. The counterpoint is harder to dismiss: good work does not automatically make itself visible or legible to the people it could help. There is a difference between performing expertise and making evidence of your work easier to find.

I've become increasingly interested in what an organisation actually remembers. Not what is stored, but what remains usable: definitions, decisions, context, exceptions and the reasons something became the way it is. AI makes retrieval easier, but that may not be the hardest problem. The harder question is what we choose to preserve, how we know where it came from and whether somebody ever judged it to be true.

Repos I'm keeping close: Lore, Vault-LD, QMD, GBrain, Contributor Knowledge Base Templates and WikiOS.

Starting small is usually good advice, but there is a difference between reducing scope and designing a dead end. I like the idea of finding a small first move that works now without making the future complexity impossible to reach later.

A sandbox is interesting when it makes a system easier to see, not just when it gives people somewhere safe to play with technology. Bounded experiments can expose assumptions, dependencies and rules without pretending that every uncertainty has to be resolved before anything moves.

Cloud made infrastructure easier to acquire and, in some ways, harder to see. I'm interested in being able to reproduce important parts of a system locally too: testing without needing permission from somebody else's platform, keeping development isolated, and making the boundary between an application and its provider explicit.

Local-first isn't necessarily anti-cloud. Sometimes it is simply a way of keeping your options open.

Repos I'm keeping close: Foundry Local, MiniBlue, Entra Local, Floci and n8n.

Organisations contain lots of language but surprisingly little shared meaning. Different professions use different words, and sometimes the same words for different things. Metadata becomes more interesting when it is treated as captured context: what something means, why it exists, who understands it and how it connects. A catalogue can be part of an organisation learning how to explain itself.

Open source is usually discussed in terms of code, reuse and avoiding lock-in. This adds another dimension: opening a layer can be a way for several weaker parties to stop one stronger party owning something they all depend on. Android is a useful warning too. Open code does not automatically keep power distributed; governance, standards and the surrounding dependencies still matter.

Good advice can become bad advice without changing a word. The world around it changes instead. I want to remember the habit of checking whether a mental model still describes the thing in front of me, rather than rewarding it for having worked before.

Producing more things is an easy way to look productive. Dashboards, reports, strategies and platforms can all be delivered without changing much. I keep this distinction because the useful question is what became possible, easier or better afterwards, not how much output the team generated.

I saved this because ambition gets talked about as if the serious version requires clearing everything else out of the way. For most adults that isn't the deal. Family, responsibility, age and ambition have to occupy the same life. The interesting question is how you keep building without pretending the other obligations are interruptions.

Calling data an asset should imply more than putting it in a catalogue. Assets need owners, users, maintenance, investment decisions and some idea of the value they create. A portfolio view is useful because it forces choices about what deserves attention rather than treating every dataset as equally strategic.

What interests me here is less the argument for psychedelics than the problem of interpretation. An experience can be vivid, coherent and life-changing without settling what caused it or what it means. Subjective experience deserves taking seriously; certainty about its explanation deserves more caution.

Capability frameworks, job descriptions and organisational structures can quietly set the ceiling on the work a public institution is able to do. Asking people to work differently while the surrounding roles and incentives still describe the old model is a familiar kind of contradiction.

Buying AI is not just a procurement exercise. The contract can decide where data goes, what can be inspected, what remains portable, who carries risk and how much freedom exists later. By the time those choices show up as architecture or governance problems, some of them may already be contractual facts.

The useful shift here is from leadership as control to leadership as creating the conditions for other people to act. Sharing power sounds softer than taking charge, but in public service it can be the harder discipline: making purpose clear, giving people room and accepting that the best answer may not come from the top.

I like the idea of joy here as something more serious than optimism. There are times when despair feels morally weightier, as if noticing anything good means not taking the bad seriously enough. Refusing to hand over everything valuable to despair can be a form of resistance too.

“Single source of truth” sounds reassuring until different people need the same underlying facts for different purposes. I prefer the idea of a trusted foundation with explicit context around how a metric is defined and used. Consistency matters, but flattening every legitimate perspective into one number can create a different kind of confusion.

Individual councils buying into the same software market with little shared intelligence creates an obvious imbalance. Suppliers can see the market; buyers often see only their own procurement. Sharing what we know about products, prices, contracts and capability is part of changing that relationship.

Strategies are often full of statements about what an organisation “will” do several years into a future nobody can see. I like the inversion here: record what we know, what we don't know yet and what we're learning as we act. Direction still matters. Changing your mind because reality taught you something needn't make the strategy weaker.

Leadership intent and leadership experience are not the same thing. A manager can believe they are creating clarity, trust or autonomy while the people below them experience something quite different. I saved this because the view from below is part of the evidence, not an inconvenient reaction to be managed away.

AI-ready is an attractive label, but local government reorganisation has a more immediate data problem. Before organisations can automate across a new boundary, they have to reconcile what their data means, which definitions conflict, what rules travel and what cannot simply be merged. The boring semantic work comes first.

We talk about owning data surprisingly casually. Ownership means rather less if somebody else decides whether you can retrieve it, move it, understand it or continue using it when the relationship changes. The question quickly becomes one of dependency: what are we still capable of doing if the organisation on the other side says no?

I love things like this. An ordinary-looking place with another version of itself underneath it: old watercourses, culverts and bits of infrastructure most people walk over without knowing they are there. No grand lesson. I just want to remember that it exists.

“Open source” is one of those labels that can make a conversation feel settled before the important questions have been asked. Open to inspect, reuse, contribute, govern or compete with are not the same thing. The definition matters because different forms of openness distribute power differently.

My brother taught himself how to build and publish this from scratch with AI. I like it as a reminder that one of the important things AI is doing is stripping away access barriers: committed people can now attempt things that previously needed much more specialist knowledge.

The 97% figure grabs the attention, but the bit I want to remember is that legacy isn't something you deal with after innovation. The condition of the existing estate determines how much room you have to innovate in the first place.

Useful distinction because "agent" is becoming one of those words where two people can agree while meaning different things. Autonomy, product feature or platform primitive is a simple question to ask before an architecture conversation goes any further.

This made me think about how much of a person is missing from their public record. Relationships are often built through tiny exchanges nobody publishes or thinks worth recording. There may be important limits to how well AI can understand somebody when some of the best evidence about them never became data.

I like that the definition changes the era without abandoning what actually matters. AI may be new, but organisations still have to do the hard work around culture, processes and operating models. You don't get to skip the internet-era lessons because a new technology has arrived.

This feels close to a problem I keep circling: can knowledge stay in a form humans can actually read, write and version while also being structured enough for machines to reason over it? I particularly like the idea that the directory itself remains the knowledge base rather than hiding everything behind another application.

I think the concept of erosion of trust is useful when thinking about how to use LLMs to contribute to team codebases.

Thoughts on choosing what to write about, how to say it, and the value of writing.

Not directly relevant to LLMs, but it's interesting to think at what point an LLM could produce an article like this. I feel like they're a long way off.

Boiten's argument about compositionality made me think of LLMs as software with no tests, no documentation, and lots of bugs. And yet very useful.

There are lots of examples of strange capabilities like this you'd never see in a benchmark.