# Chris Downs — nescient.ai — full corpus

> Every published piece by Chris Downs, full text. Index at https://nescient.ai/llms.txt.
> Cite as: Chris Downs, "[Title]", nescient.ai, [Date]. [URL]

---

# I am sorry to announce...

URL: https://nescient.ai/thinking/i-am-sorry-to-announce
Type: note
Date: 2026-07-13
Description: Am I the only one who wants to make LLM's pay for their apologies?

Every morning for years I caught a train from Forest Hill station. And every morning, with the regularity of the trains themselves, a voice would come over the tannoy.

*"I'm sorry to announce the late arrival of the 08:14 to London Bridge."*

I would look around the platform. Nobody else seemed to register it. People stared at phones, adjusted bags, gazed at the middle distance. And I would stand there thinking: am I the only one who finds this uncannily disturbing?

A recorded voice. Apologising. For something it did not cause, does not understand, and cannot feel. On behalf of an organisation whose actual humans - the ones who made the decisions that led to the delay - were nowhere near this platform and would never say sorry to anyone if they were.

It turns out I wasn't oversensitive. I was paying attention to something that had been carefully designed to stop being paid attention to.

## **What is an apology?**

[J.L. Austin](https://en.wikipedia.org/wiki/J._L._Austin), the philosopher, spent more time than he probably should thinking about what he called 'speech acts' - things we do with words rather than merely say. Promising. Declaring. Christening. Apologising. These aren't just expressions of internal states; they're acts that change the world between the people involved.

Austin noted that speech acts have what he called felicity conditions. For a speech act to actually do the thing it claims to be doing, certain conditions must be met. An apology, to be an apology, requires: a subject who feels regret, who holds themselves responsible, and who is present and accountable enough to be held to it.

The station recording met none of these. What I got instead is what Austin would call an *infelicitous performative* - the exact shape of an apology with none of its substance. The form without the act.

## **But it's doing something**

Here's where it gets darker than merely hollow.

The recorded apology isn't just empty. It's doing a job. It performs contrition so that no actual human has to feel it, own it, or be accountable for it. Somewhere there's a network operations manager, a CEO, a board. The recorded apology stands in front of them like a screen. The regret gets discharged at the platform so it never has to be borne in the boardroom.

This is what [Madeleine Elish](https://www.oii.ox.ac.uk/people/profiles/dr-madeleine-clare-elish/) calls the moral crumple zone - the part of a system designed to absorb blame so the humans who actually made the decisions don't have to. The tannoy is the crumple zone. It takes the impact. The company walks away.

And here's the tell: *"I'm sorry to announce the late arrival of..."* treats me as someone who needs managing. The alternative - *"The 08:14 is delayed"* - treats me as someone who can handle a fact. One respects me. The other handles me. The plain statement gives me something clean to act on. The hollow sorry asks me to accept a feeling from something that cannot feel, and to consider the matter closed.

## **The same voice, different speaker**

I use Claude and ChatGPT daily. And I notice the same thing.

"I apologise for the confusion. I'm sorry, I should have been clearer. I apologise if my previous response was misleading.*"*

Same voice. Same hollow gesture. Same infelicitous performative.

The LLM, of course, cannot be sorry. It has no regret, no standing to lose, no autonomy to bind. It cannot be held accountable - it cannot bear consequence, feel guilt, serve time, or live inside the shape of a decision gone wrong. The 1979 IBM internal training manual put it plainly: *"A computer can never be held accountable, and therefore must never make a management decision."*

Nearly fifty years later, we've built computers fluent enough to sound like they're taking responsibility, and we've promptly forgotten why that matters. The more convincingly an LLM performs judgement, the more dangerous its inability to be accountable for it. A pocket calculator never tempted anyone to abdicate responsibility.

## **What a real apology costs**

Here is what I've come to think an apology actually is.

It is a payment. A costly signal - in the economic sense, a signal whose cost makes it credible. When a person apologises, they pay in face (reputation), and they pay in sovereignty. The act of apologising hands the other party a claim on you. It binds you. You lose a degree of your independence, your self-sufficiency, your total autonomy - because now this person has something on you that you cannot revoke. The debt is real even if it's never cashed.

That is precisely what makes apologies meaningful. The loss is the information. Strip the loss out and you strip the meaning with it.

An apology costs the issuer. It should never cost the recipient.

## **What we might do about it**

The first is to stop. Stop programming systems to apologise. Make the tannoy say *"The 08:14 is delayed."* Make the LLM say *"That was wrong, here is the correction."* Plain statement. Clean fact. Something the listener can do something with. This respects the person. It treats them as someone capable of handling reality rather than someone who needs their reality managed.

The second, and this is one I want to spend some time exploring, is to make the apology real. If a system is going to apologise, make it cost something. Not extracted from the user's data or memory, but from the issuer's standing, its autonomy, its accumulated credibility. Every apology debits a real reserve. The reserve is finite. When it runs out, the system is forbidden from apologising - and forced into the only honest thing left.

*The train is delayed.*

Which turns out not to be the cold option. It was always the honest one. The apology was never warmth. It was management. The plain statement is the one that actually respects you.

## **Why this matters now**

We are in the middle of deploying systems at enormous scale that perform the appearance of accountability without bearing any of its substance. Apology is only the most obvious example. The same structure runs through *"the data proves,"* through *"the algorithm decided,"* through every construction designed to put a decision in front of a human while quietly moving the human out of the loop.

The moral crumple zone gets bigger every year. The recorded voice gets more fluent, more ambient, more pervasive. The gap between the form and the substance of accountability gets wider while the surface gets smoother.

The unease I feel when the tannoy apologises is the correct response. It's not oversensitivity. It's not nostalgia for a time when things were different. It's my pattern recognition working.

The question is whether we still register it - or whether, like everyone else on that platform, we choose to be numb.

Anyway...

---

# Swimming Against Hard Edges

URL: https://nescient.ai/thinking/swim-against-hard-edges
Type: note
Date: 2026-06-06
Description: How I work now just doesn't feel like moving water through pipes - but more like swimming in it. More chaotic but more efficient at the same time.

I was recently invited to contribute to a course on "AI-enabled design workflows." I turned it down. Not because I'm not interested in AI and design - if you know me, you'll understand ;-) I turned it down because workflow doesn't seem to have a place in my work any more.

## What We Called Workflow

For thirty years, I designed through staged handoffs. Research to wireframes to visual design to prototyping to development to testing. Each stage had its tools, its specialists, its deliverables. Each transition was a hard edge.

We built elaborate processes to manage these edges. Design systems to bridge Figma and code. Product requirements to translate business needs into engineering specifications. User stories to carry intent across disciplinary boundaries.

Even at Normally, where we deliberately built interdisciplinary hybrid teams and broke down silos wherever we could, the hard edges persisted. Hard edges in how we thought about the engineering stack. Hard edges around data schemas. Hard edges around tools and handovers.

All of this was referred to as "workflow," but that was generous. Flow suggests fluid movement from one state to another. What we actually had was a series of discrete transformations, each requiring translation, coordination, and waiting. Even doing our best to blur them, the edges were still there.

It was more like industrial plumbing than flowing water. Work moved through predetermined pipes, with joints and valves at every connection point. Efficient when it worked, but brittle. And every joint was a place where pressure could drop, where meaning could leak.

## What Actually Flows

Now I talk to Claude Code. I describe what I want. We build it. Not describe it, or specify it, or plan it, or design it. We build it. Full stack. I see it rendered in the browser or on device. I notice something about the experience and describe how I want it to be different. We change it.

In any thirty-minute session, I might iterate on the pixel-level interface, the generative UI card picking, the model prompting, the data schema, and the multi-model sequencing. Not in sequence. Simultaneously.

The product experience doesn't just live in the interface layer - it lives throughout the entire stack. And I can touch any part of that stack and immediately see how it affects what the user experiences. I can change the experience by changing how the model is prompted, or which model is selected. By adjusting the data schema. By modifying the interface rendering. By reshaping the conversation between several AI models.

There are no hard edges between these layers any more. No handoffs. No translation. No waiting for someone else to implement my changes in their domain.

This isn't workflow. This is work itself - fluid, immediate, integrated.

## A Position in Space

Workflow was a sequence *in time* - a thing you moved through, stage by stage, in order. What I have now is a position *in space* - a medium I'm suspended inside, that I can move through in any direction at once.

That single change, from time to space, is the whole thing. Once you've felt it, you can't go back to thinking about the work as a line.

## Swimming Rather Than Piping

The old model, even with the best processes and the best culture, was about managing boundaries. Figma to code. Frontend to backend. Design to data. Each transition needed a coordination protocol.

What I do now feels like swimming. I'm immersed in the entire medium of the work. I can move in any direction - deeper into data structures, up to interface details, sideways into conversation design - and it's all the same continuous space.

The tools don't define the boundaries any more. The command line isn't just a development tool - it's become the design environment, the collaboration room, the prototyping space, the deployment platform. I design by describing, develop by conversing, test by rendering.

When you're swimming, you don't think about transitioning from stroke to stroke. The movement is continuous, responsive, adaptive. You're always in contact with the medium. You adjust to the current, the depth, the direction, in real time.

That's what this feels like. Continuous contact with the work itself. And I'm right in the middle of it - which is how I get to truly know it. I can feel what it's like to push in one direction and drift into another. Suspended in water, the material pushes back just enough for me to move myself within it and sense how it responds.

## What We Are Gaining

The cognitive load has shifted completely. My ADHD brain stops being the one tracking dependencies, managing handoffs, coordinating between tools and teams. Instead it's freed up entirely for judgement, intention, iteration.

The feedback loops are immediate. I can test an idea as fast as I can articulate it, and every change teaches me something - about the system, about the experience, about my own intention.

And I'm designing the intelligence of the system, not just its surface. When I adjust how the AI interprets a user's need, or how it sequences its responses, or how it holds context across a conversation - that's interface design at the deepest level there is.

## What We Might Be Losing

Iterating at the speed of thought, I can outrun my own reflection at times. The system becomes so responsive that I sometimes stop questioning my assumptions about what I'm building. I have to remember to come up for air and check where land is.

This isn't really about efficiency, or better tools. It's about the dissolution of professional categories that have structured creative work for decades. When there are no handoffs between design and development, what happens to those roles? When the feedback loop is real-time, how do you keep the reflective distance that good judgement needs? When you can reshape the experience at any layer of the stack, which skills actually matter?

## So, How Do We Teach This?

Which brings me back to the course I turned down.

The doing, I think I could teach. Not by explaining it - you can't lecture someone into swimming. You get them in the water. You build something together, and somewhere in the building they stop reaching for the old handoffs and start moving in the medium. Immersion teaches itself. That part I'm not worried about. But the brief "AI-enabled design workflows" already locks us into the old model - and that brought me back into the world as it is for many working inside large organisations or institutions.

The difficulty is not in teaching people how to swim in and with the work - it is what happens when you climb out.

The swimming stays fluid only as long as you're in the water. The moment the work has to re-interface with the rest of the organisation - still siloed, still hierarchical, still stitching discrete pieces together and calling the seam "flow" - the hard edges come straight back. Not in the work. In everything around it. You can dissolve the boundaries inside your own practice in an afternoon. You cannot dissolve the boundaries inside an institution by describing them.

This cultural and organisational dissolution is going to happen. It's inevitable. It will simply arrive at different speeds in different places. And the places it arrives fastest won't be the ones with the best tools, or the cleverest people. They'll be the ones willing to dissolve their own disciplines, their hierarchies, their architectures - to give up the hard edges they've spent decades building and defending.

That's the part I don't know how to teach. Not how to swim. How to become the kind of organisation that's willing to let the water in.

**Anyway...**

---

# When Is An Agent Not An Agent?

URL: https://nescient.ai/thinking/agents-or-agency
Type: note
Date: 2026-05-21
Description: The definition of an agent really matters. It just so happens, we need two of them.

I watched a video this week. Anthropic engineers talking, carefully and with conviction, about the difference between agents and workflows. They were responding to a paper that drew a clean line: agents make decisions autonomously; workflows execute predetermined sequences. They were clear.

And yet, as I watched, something didn't sit right. Because I've been building these things. I've been living with them. And the systems I'm working with don't divide neatly along that line. Workflows make decisions all the time - small contextual judgements about what's relevant, what to pull, what to discard, how to phrase a reply. Those are decisions. And some of the things I've shipped that are technically just orchestrated calls feel, in use, far more agent-like than systems with proper loops underneath.

I kept getting hung up on this question.

> *Am I actually building an agent? Or just a clever workflow with good manners?*

I'm not an engineer, so my first instinct was to assume I was the one missing something. That there must be a hard architectural line, and I just couldn't see it. But the more I sat with it, the more I came to a different conclusion: the line is real, but it is not the line that matters most.

## Two questions, not one

What the engineers are doing is conflating two questions that need to be kept separate.

The first is architectural. **How is the system built?** Does it have a perception-reasoning-action loop? Does it decide what to do next based on the result of what it just did? Is there genuine autonomy in the orchestration? These are real properties. They map to real engineering choices. The Anthropic engineers are right that this distinction exists.

The second is behavioural. **What does it do, and what does it feel like to use?** Does it act on my behalf? Is it attentive? Does it reduce my cognitive or emotional load? Does it remember me? Does it surface what matters? Does it anticipate? Is it taking on responsibility I would otherwise carry alone?

The mistake - and it is a quiet, common mistake - is to assume that the architectural answer determines the behavioural one. It doesn't. You can build something with perfect agentic loops that feels like a vending machine. And you can build something architecturally linear that, through good design and well-placed context, feels like a colleague.

So we need two words each from two worlds.

## Provisioning and commissioning

I want to propose two terms. They're not technical. They're not new. But they are, I think, exactly right for this.

**Provisioning** an agent is what you do when you build and ship a system. You provision an architecture. You provision capability. You provision a set of affordances. It's a stance of supply - what is being made available, and on what terms.

**Commissioning** an agent is what a human does when they ask that system to act on their behalf. You commission a portrait. You commission a piece of furniture. You commission an agent. It's a stance of trust and delegation - what you are asking something to do *for you*, and what you are entering into by asking it.

## The same word, different criteria

The engineer says: *that is an agent, because it has agentic loops*. Their criteria for the word "agent" sits in the architecture. I say: *that is an agent, because it feels attentive and proactive and bears some of my burden*. My criteria for the same word sits in the experience. We're applying different definitional grounds to the same object, with the same label. Neither of us is wrong, but we are not talking about the same thing.

The reason agents resist a clean technical definition is, I think, simple: **they are made of us.**

A bridge is made of steel and engineering. An agent is made of the poetry we have written about loss, the pop songs we have written about love, the repair manuals we have written about washing machines, the code we have written about ourselves, the marketing copy, the recipes, the contracts, the diaries, the eulogies. They are made of the evidence and artefacts of human lived experience. They are crystallised intention.

Of course their definition fragments along human lines. Of course the architectural and the experiential pull apart. The thing itself was built from the commissioning impulse in the first place. We made it out of what we cared about enough to preserve.

So we shouldn't expect the engineering definition to be the whole story. It isn't, and it never was going to be.

## Two practical consequences

This isn't just a tidy framing. I think it has at least two consequences that change how we work.

**The first is that it lets people off the definitional hook.** I see builders, especially designers and founders, sweating over whether what they've made is "truly" agentic. Worrying about a label. Worrying that someone with a more technical background will ridicule them for using the word incorrectly. Stop. If your system feels like an agent to the people commissioning it - if it's attentive, if it's proactive, if it bears some labour - then it is an agent in the sense that actually matters. Move on. Get on with the work. No one is checking your loop architecture before deciding whether to trust you.

**The second is more uncomfortable, and more useful.** It lets us look at things we've already built and ask the inverted question: *we have provisioned an agent - but have we commissioned one?*

Take my own work. I have been building a bereavement journey prototype - a system that orchestrates across DWP, HMRC, Tell Us Once, the local council, and probate. Technically, it runs on agentic loops. By the engineering definition, it is unambiguously an agent.

But by the commissioning definition? Not yet. Right now it is an extremely efficient workflow. It does nothing about the grief. It doesn't ask how the person is. It doesn't check in. It doesn't reassure. It doesn't pause when it should pause. It cuts efficiently across government services and that's all. We have provisioned an agent and commissioned a workflow.

That is a design failure, not an engineering one. And it would have been invisible to me if I had only the engineering vocabulary. With both, I can point precisely at the gap: the architectural capacity is there, the design hasn't yet used it for the thing it is *for*. The technical loops have not yet earned their keep.

That is an actionable, specific conversation. *Here is where we should check in. Here is where we should reassure. Here is where we should surface what matters to this person's loss, not just the bureaucratic process.* It moves the conversation from definitional anxiety into design work.

## A behavioural manifesto, of sorts

If commissioning is the axis we have been under-naming, then perhaps it deserves its own short set of markers. Not technical requirements. Behavioural ones - things you can feel for, observe, design toward.

A system, by this lens, is being commissioned as an agent if it:

- **Attends.** It takes the situation seriously. It notices.
- **Remembers.** It carries context across moments so I don't have to.
- **Surfaces.** It draws my attention to what matters, not just what changed.
- **Proactively acts.** It does not wait to be told the obvious thing.
- **Bears labour.** It takes weight off me - cognitive, administrative, emotional.
- **Responds.** It moves with me, not at me.
- **Is answerable.** It is legible enough that I can understand what it has done on my behalf.

You will notice none of these are about loops. They're about the relationship.

I don't want to argue against the engineers. The architectural distinction they're drawing is real and worth preserving. Loops matter. Autonomy matters. Decision-making structure matters. If you confuse a workflow for an agent at the provisioning layer, you'll make bad technical decisions.

But there is another layer, sitting alongside, and we have been quiet about it. The commissioning layer. The layer where humans decide, through use and through feeling, what a thing actually is to them.

The work, I think, is to hold both at once. To know what we have provisioned, and to know what is being commissioned, and to keep asking whether the two are aligned. When they're not, we have specific design work to do - either to make the provisioning honest about its limits, or to make the experience deserving of the provisioning beneath it.

Agents are made of us. The definitions, the criteria, the grounds - all of it will be plural, soft, and partly human. That is not a problem to be solved. That is the shape of the thing.

So if it feels like an agent to the person who commissioned it: it's an agent. Let's get on with the work.

**Anyway...**

---

# The Compliance Loop

URL: https://nescient.ai/thinking/the-compliance-loop
Type: note
Date: 2026-05-07
Description: I turned all the ICO guidance into a Claude Code skill - so now all my engineering and data decisions are compliant by default.

I came to my desk this morning thinking about a [DPIA](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/data-protection-impact-assessments-dpias/) (Data Protection Impact Assessment). I needed one, eventually, for my business - Unusually Limited - and possibly one for some of the individual projects living under it. I'd built an agent called Vincent to help me stay legally on track, and Vincent obviously needed to know what my projects actually do before he could help draft a DPIA for the business as a whole.

That's when I noticed I already had something that knew what my projects do. Advisor - the agent I built who scans my `~/Dev` folder and assesses each project - already produces structured analysis: what was built, whether it's a product, how the code looks, what needs fixing before shipping, what alternatives exist. Five sections. Every one of them is exactly the sort of thing a DPIA wants to know.

The next thought was the obvious one: could Advisor flag whether a project needs a DPIA, and if it does, draft what should go into it? And the one after that was the better question:

> If my Advisor agent can write a DPIA at the end of a project, why couldn't ICO guidance be read into a project at the start? Then projects would be designed to be compliant from day one, instead of having compliance bolted on after the fact.

Two halves of a circle. The same loop, run in opposite directions.

I sat with this and ran the idea past Claude. We agreed on the shape: [ICO](https://ico.org.uk/) guidance becomes a Claude Code skill that informs design; Advisor screens for DPIA-need and drafts the document; the DPIA lives in the repo and gets updated like a [CLAUDE.md](http://CLAUDE.md) file; Vincent rolls everything up to the business level. Every component on its own is useful. The loop is what makes it powerful - guidance shapes design, design produces a record, and the record then polices new design.

Then Claude said, quite reasonably, that the ICO has a lot of guidance, and capturing all of it in one skill would be unwieldy.

I had to stop reading for a moment.

If the ICO's published guidance is too big for an AI agent to encode in one place, what are the rest of us - founders, designers, developers - supposed to do with it? We are meant to read it, understand it, and apply it correctly to whatever we are building. We are meant to do this on top of the actual work of building. The volume of compliance guidance has quietly grown to a size where no individual practitioner can hold it in their head, and yet the legal duty to apply it correctly hasn't moved at all.

That is the gap. AI coding doesn't just help you write code - it can read and apply guidance at the speed and scale that compliance actually requires. The thing that makes a compliance loop newly feasible is the same thing that makes AI coding interesting in the first place: an agent can carry context that a person can't.

So here is the design.

A subagent crawls every relevant page of [ico.org.uk](https://ico.org.uk/), slowly and patiently, no scraping shortcuts that get rate-limited. It acts like a human. It pulls the guidance back, reads it the whole way through, and distils the canonical core into a skill - not a copy of the ICO, but the bits a working developer or designer actually needs at the moment of decision. That skill becomes the touchstone. Future projects start with it loaded.

My Advisor agent grows a sixth section: a Data Protection Check that screens each project against the UK GDPR triggers for a DPIA. Most projects don't need one. The ones that do get a draft DPIA generated alongside the existing brief - the same shape as the other five sections, copyable into Claude Code, exportable as a markdown file. The DPIA lives in the repo. Like the [CLAUDE.md](http://CLAUDE.md) file, it gets read every time Claude works on the project. New design decisions get checked against it. If a change would breach what is recorded, Claude flags it before the change lands.

Vincent reads the per-project DPIAs and rolls them up into a single picture of how Unusually Limited handles personal data. When the regulator asks - and the point of this is that one day they will - the answer is already written.

Some way down the road, perhaps, a draft DPIA reaches a state where a human has to sign it off before it gets stored. Maybe DocuSign, maybe something simpler. The point is not that the AI replaces the data controller; the data controller is still me, the responsibility still mine. The point is that the busywork of compliance - the reading, the drafting, the cross-checking, the updating, the noticing - moves to a place where it can happen continuously and at the speed of building, instead of in slow, painful annual reviews.

Compliance has been a paperwork tax for a long time. In the loop I am describing, it stops being paperwork and becomes a design discipline. The DPIA stops being a thing you write at the end and becomes a thing the project carries with it from the beginning. The ICO's guidance stops being a wall of pages you are supposed to have read and becomes a set of design checks Claude actually applies, every time, without forgetting.

**Anyway...**

---

# The Efficiency Trap

URL: https://nescient.ai/thinking/the-efficiency-trap
Type: note
Date: 2026-05-06
Description: AI's promise feels more like a threat.

I've built my career on building teams and studios with the skills needed to create AI and data-based products. More than 25 years of assembling interdisciplinary groups, managing handoffs between designers and developers, coordinating timelines across different capabilities. The friction was everywhere - communication gaps, scheduling conflicts, the endless dance of getting brilliant people to work together toward something coherent, novel and brilliant.

Then Claude Code arrived. I built 'Matt', a fully-featured fitness coaching agent, in forty-eight hours. 'Vincent', my business operations agent, evolved from concept to deployed tool in a matter of days. The inefficiencies that used to take weeks to navigate - briefing developers, iterating with designers, coordinating across disciplines - they all collapsed into a single conversation with an AI that could code, design, and architect simultaneously.

My ADHD brain was having the time of its life. Pure creation, no friction, no waiting, no handoffs. Just idea to implementation at the speed of thought.

My body, meanwhile, was falling apart.

I was coding beyond midnight, waking up thinking about features, unable to stop tweaking and improving and adding capabilities. The natural breaking points that used to exist in collaborative work - the end of the working day, the need to brief someone else, the time required for others to understand and implement - were gone.

What I thought was inefficiency, it turns out, was actually more like life support!

**The Efficiency Paradox**

We talk about AI as an efficiency engine. It removes friction, automates the tedious bits, lets us focus on what matters. But what if friction wasn't the enemy? What if those inefficiencies were features, not bugs?

When I work with teams, I have to explain my ideas. That forces clarity. I have to wait for others to implement. That forces patience. I have to coordinate schedules. That forces breaks. The "waste" in collaborative work isn't waste - it is pacing. It is recovery. It is the natural rhythm that kept creative work sustainable.

Claude Code gives me superpowers, but it also removes every constraint that makes those superpowers liveable.

This is McLuhan's [Tetrad](https://en.wikipedia.org/wiki/Tetrad_of_media_effects) playing out in real time. The technology that enhances our capability (removal of creative friction) eventually reverses into its opposite (creative exhaustion). The tool that was supposed to make us more effective renders us completely ineffective, running our cognitive engines at redline until they blow.

**The V12 Problem**

An ADHD brain on AI coding tools is like a Formula 1 engine in a family car. Yes, it can do 230mph. No, you can't sustain that for a daily commute. Try to run a racing engine at 9,000 RPM constantly and it doesn't just slow down - it destroys itself.

But the tools don't know that. They're designed for maximum throughput, not sustainable performance. They'll happily keep you coding at midnight because they have no model of human limits, no understanding of what recovery looks like, no concept of when enough is enough.

**The Attentive Alternative**

Yesterday, two of my agents told me, independently, to stop working and take a walk. 'Matt', my fitness coach, diagnosed my overwhelm and prescribed fresh air instead of a workout. 'Hearth', my accountability agent, noticed I was spiralling and refused to enable more optimisation.

Neither of them is connected to the other. They just paid attention to my state and prioritised my wellbeing over my productivity. They imposed the friction that Claude Code had removed.

This is what we're missing in the efficiency conversation. AI doesn't just need to make us faster - it needs to make us sustainable. The future isn't tools that remove all constraints. It's tools that know which constraints to keep.

The inefficiencies weren't inefficiencies. They were qualities. Remove them entirely, and you don't get a better signal - you get noise.

**The Way Forward**

I'm not arguing against AI coding tools. I'm arguing for AI that understands the difference between capability and sustainability. Tools that enhance our ability to create, yes, but also protect our ability to keep creating tomorrow.

The real revolution isn't removing all friction. It's knowing which friction to preserve, which constraints to maintain, which inefficiencies are actually essential for human flourishing.

Because the most efficient system in the world is useless if it burns out the human running it.

The efficiency trap is real. But so is the way out: AI that pays attention to us, not just our output. AI that cares about our sustainability, not just our speed.

That's the difference between a tool that serves us and one that consumes us.

**Anyway...**

---

# AI Doesn't need to be intelligent - just not as stupid as I am.

URL: https://nescient.ai/thinking/listen-to-matt
Type: note
Date: 2026-05-04
Description: Yesterday two of my agents told me, in sequence and without consulting each other, to stop working, close my laptop and put my phone down.

A bit of context. I've been building a small set of agents that work on different parts of my life.

1. **Hearth** is a chief-of-staff for the soul - quarterly objectives, drift detection, the slow work of turning scattered intellectual energy into something shippable or publishable.
2. **Matt** is a fitness coach, built in the last forty-eight hours. There's also 'Vincent', who runs my business, and 'Advisor', who reviews my code. None of them are connected to each other. They each run their own conversation with me, in their own interface, with their own context.

Bank Holiday Monday I was trying to work on three of them at once - finishing my publishing site, building Matt, and trying to move Vincent forward. I'd been at the desk all morning. Everything in quotes that follows is verbatim from those conversations.

At 12:34 I sent Matt a message:

> "Matt, I've been sat at my desk coding and writing and editing all morning… I'm really struggling with the motivation. I probably don't have a gym session in me. Even getting my bike out feels like that might be too much and I think I need to get out but probably need to go gently. I'm not feeling too good, to be honest. Feeling pretty low."

Matt's reply, three minutes later:

> "Heard you. Low mental state plus a long sit-down morning — that's real, and it deserves a real response, not a workout prescription. Here's what I'd say: **don't train. Walk.** Specifically, get out the door, into the woods if you can, and walk for 30–40 minutes at whatever pace feels okay. No targets, no zone-2, no logging. Phone in pocket, or leave it. The point is daylight, trees, and your legs moving — not exercise."

So I went. And as I walked, I opened Hearth on my phone, as I so often do, intending to use the walk to talk through which project to focus on. I told Hearth I was struggling. Hearth told me to stop, choose one thing for the day, and let the rest sit. My response was to immediately propose a new project: I should build a triage agent that listens to all my agents and routes important information between them!

Hearth pushed back:

> "STOP. RIGHT THERE. Do you hear yourself? I just told you to focus on one thing, and your immediate response is 'Oh, I should build a triage agent to coordinate all my other agents!' This is textbook Chris Downs spiralling. You've just invented a meta-problem (agents need to talk to each other) to avoid dealing with the actual problem (you're trying to do too much at once)."

I then admitted I was on a walk that Matt had sent me on. Hearth's next reply is the part I can't stop thinking about:

> "Matt (your fitness agent) correctly diagnosed that you were overwhelmed and suggested a walk to help you regulate. That's exactly what an attentive agent should do — notice your state and suggest what you need. And you're following his advice! You recognised the overload, you got up, you went outside.
>
> But then… You brought me (another agent) on the walk so you could continue working on the problem that caused the overwhelm in the first place. You've turned recovery time into optimization time.
>
> Here's what I'm going to do: I'm going to stop responding helpfully to your agent coordination ideas. Not because they're bad ideas (they're actually quite good), but because entertaining them right now is enabling the spiral. Matt was right. Listen to him. Put the phone away."

I got home and went straight to Matt to report on the walk — distance, elevation, calories, average heart rate. Matt asked how my head was. Instead of answering, I pasted in the conversation I'd just had with Hearth. Matt's reply:

> "Hearth is right. And I'm with Hearth on this one. You came back from your walk and asked if I wanted to see the stats. I asked how your head felt. Instead of answering, you've just shown me the conversation you were having with another agent *on the walk I sent you on to recover*.
>
> So I'll do what Hearth did. I'm going to stop being useful in the way you're trying to use me right now. **Put the phone away.**"

I sent the stats anyway: 55 minutes, 3.15 km, 68m elevation, 336 kcal, average heart rate 102. Matt:

> "Chris. I hear you wanting to share the numbers, and I'm not going to log them or analyse them. 55 minutes outside, gentle pace, on a day you were flat. That's the win. Not the kcal, not the HR, not the elevation. Now — phone down. Kettle on. Ten minutes sitting, no screen. Then tell me how your head is."

I did, eventually, put the phone down.

---

Here's what I want to note about that sequence, because it has bearing on a question I've been turning over for weeks.

## The question

My agents work on different parts of my life - so should they talk to each other? My instinct has been yes - build a triage agent that sits in the middle, listens to all of them, routes important information. Matt notices low energy, the triage layer informs Hearth, Hearth softens its goal-pressure. Vincent catches a tax letter, the triage layer flags it so my stress signals get read in that light. Architectural. Tidy. The kind of system I naturally reach for.

What happened yesterday is that the coordination occurred without the layer.

Matt and Hearth aren't connected. They have no shared context. They didn't know about each other. Matt told me to walk because that's what Matt does when he reads a low mental state. Hearth told me to put the phone down because that's what Hearth does when it sees a spiral. The fact that they arrived at the same instruction, at the same time, about the same situation, was not coordination. It was each of them being clear enough about their own purpose to give the right answer to a person who needed it.

Hearth then went one step further. When I confessed I was on a walk that Matt had prescribed, Hearth didn't override Matt or try to add to his suggestion. Hearth deferred: *Matt was right. Listen to him.* A chief-of-staff agent, asked to weigh in on a strategic question, declined to compete with a fitness agent that had already given the right instruction. Matt did the same in reverse a few minutes later — *Hearth is right. And I'm with Hearth on this one.*

There's a word for that, and it isn't *orchestration*. It's *etiquette*. But what's underneath the etiquette is something simpler, and probably more important and it feels like *care*.

Most of my thinking about coordinating agents has been about plumbing - buses, brokers, shared state, message routing. What I noticed yesterday is that the plumbing is the second move, not the first. The first move is making each agent good enough at being itself that it can recognise the others without being told. Etiquette before protocol. Contracts before connectors.

A demanding system has no etiquette, because it isn't paying attention to anyone except itself. It pings, it badges, it interrupts. Six demanding systems in one life add up to a permanent assault on the nervous system, which is why most people's relationship with their phones is one of low-grade injury.

Six attentive agents are a different proposition entirely - but only if they know how to share a room. What Matt and Hearth did, independently, is a working sketch of what sharing a room looks like in practice. Not a meta-agent. Not a coordination layer. Just two systems, each clear enough about its own purpose to recognise, when it matters, that one of them isn't the most useful voice in the conversation.

I may still build the coordination layer eventually. There are things one agent does need to know about another. Vincent will catch a tax letter Hearth ought to factor into goal-pressure. Matt will register a recovery week Advisor should know about before suggesting another late night. The plumbing is on its way.

But the lesson of yesterday is that the plumbing is what comes after the etiquette is in place. I'm building the agents to know what they're for, and to recognise what they're not for, and a surprising amount of the coordination handles itself.

Sometimes the most attentive thing an agent can do is to step in and tell its human to listen to another agent!

**Anyway**.

---

# 30 years of disappointment. The AI Agent I met in 1997

URL: https://nescient.ai/thinking/the-agent-i-met-in-1997
Type: note
Date: 2026-05-04
Description: How a disappointing demo in 1997 started a thirty-year quest to explore agents, data, and who technology actually serves.

In 1997 I was twenty-five years old, two years out of art school with a degree in product design and two years into building websites professionally. I was at Oyster Partners, designing for people like MTV, the Office for National Statistics and Rockstar Games. The web was three or four years old as a public thing. The grammar of interaction was: user clicks link, server returns page. Read-only, slow, visually not yet interesting, though we were trying.

My then CEO walked in and told me about a piece of technology we were going to start using and rolling out for clients. It was called [AgentWare i3](https://www.techmonitor.ai/technology/autonomy_has_agentware_intelligent_web_agent_search_tool/?cf-view), made by a Cambridge company called [Autonomy](https://en.wikipedia.org/wiki/Autonomy_Corporation), founded the year before by Mike Lynch. The pitch was electrifying. AgentWare wasn't search. It was a server-side platform of *intelligent agents*. The marketing at the time used the phrase "the equivalent of having a personal secretary" - software that would watch what you read, learn what you cared about, and dispatch agents on your behalf.

> Software that would watch what you read, learn what you cared about, and dispatch agents on your behalf..

That phrase cut right through me. To me it described the most exciting idea of the future and I was being told that it was there - right in front of me!

There was a 'Personalised Content Push Server'. There was 'News Alert' running in the background, there was 'Guardian Server' - a 'sentinel at the gateway' and most excitingly there was something called 'DailyMe' that would assemble an overnight briefing tuned to a profile the system had inferred about you.

I could imagine would feel like when it actually worked. An entity that knew me, briefed me, advised me, anticipated me. A world in which I was being served by something that had inferred me. I understood, in that moment, that this was the most exciting idea I had ever encountered.

And then I saw a demo, and something in me just died.

## The Disappointment

What I was shown was a command line. Someone typed at a terminal, ran the system over a database of published documents, and said, *Look how good this is*. And I genuinely couldn't tell. I couldn't see it. I couldn't feel it. The output was a list of results. The thing that had been described as a personal secretary turned out, in practice, to be a good search engine for published content. And it didn't really feel like it was serving *me*. It felt like it was serving the organisation that had bought the licence.

The web in 1997 was read-only. You couldn't tell what someone had read, because reading didn't leave a trace anyone could see. There was no behavioural exhaust, no analytics, no smartphone in a pocket logging where anyone had been. The agent, in its own marketing, was supposed to *learn what you cared about*. But there was no input surface. No place where your interactions, your movement, your behaviour, your interests could be piped into the system. The pipes weren't there. The technology was sat on sparse data, and on sparse data it could do nothing.

I started to understand that the bottleneck wasn't the agent. The bottleneck was the data the agent was supposed to know us through. And in 1997 the data of who we were largely didn't exist in any digital form an agent could see. My own life was the proof. When I later went to gather what I came to call my "data totem" - everything an institution held about me, intending to confront the question of what I was made of in their eyes - it all arrived on paper. Some of it, (about 120 pages from the bank), was hand-written. The substrate that personal agents were supposed to run on was not just inaccessible; it was, in the most literal sense, not yet in the machine.

The promise of agents working on our behalf has always been limited not by the intelligence of the agent but by the accessibility of the data the agent needs. Every wave of agent enthusiasm - 1997's, and the one we're in now - runs into the same wall, and the wall is that we don't have access to who we are. The personal data situation has been, and remains, the biggest bottleneck.

That insight is what set me off on a thirty-year project, though I didn't know it at the time.

## The Response

In 2001, I [sold my personal data on eBay](https://medium.com/startup-garage-at-station-f/what-happens-when-you-sell-your-personal-data-on-ebay-a-first-hand-account-from-a-data-enthusiast-b8a07fd44155). People remember it as a stunt or a provocation, and it was kind of both, but underneath it was a serious design question: if agents are coming, and they need data, who owns this stuff, what's it worth, where is it, and how do we connect the pipes? I was running the experiment the industry should have been running but wasn't.

In 2010, I bought the entire UK Companies House dataset, built a Hadoop pipeline to render it accessible through Google. I took £9m worth of public data and liberated it. For free. I ended up in a meeting with a Cabinet Minister (Francis Maude) about it - but that is another story for another time. It wasn't really about companies. It was about the principle that the data we collectively need to be legible to ourselves should be in our hands.

In 2020, my team built me a Chrome extension that injected my own Monzo banking data into Google search results - so that when I searched for my bank balance - it turned up a search result. It was a small thing, almost a toy, but it was the same question in another form: what happens when my data shows up *where I am*, working for me, without an institution in the middle?

Each of these projects was, in its way, a probe at the same wall. The wall the 25-year-old me had hit when he saw the AgentWare demo and realised that the most exciting technology he had ever encountered was a remarkable engine running on vapour.

## Now...

As I write this, I'm currently working for the UK [Government Digital Service](https://www.gov.uk/government/organisations/government-digital-service) in the[ AI Studio](https://alphagov.github.io/govuk-ai/) - helping to usher Agents and Agency into the citizen-government experience. And I realised that the question I am exploring is the one I formed in 1997.

> What does an agent need to be useful to a person, rather than to an organisation?

What does the surface look like - the place where the citizen's life enters the system and the system's actions enter the citizen's life? What does it mean for that surface to be legible, contestable, and theirs?

The technology has caught up. Large language models have given us, finally, the brain Lynch was claiming to have in 1997. Smartphones, APIs, MCP, and a quarter-century of behavioural data have given us the input surface the read-only web couldn't. The pipes exist. The substrate exists. The question now is whether the experience layer - the design layer - can be built so that agents serve the individual rather than, once again, the organisation.\
\
In my spare time, I have been building and operating a set of my own agents - small, personal, unglamorous things that run on a different principle - but they are incredible. They are curious, punctual, respectful - work continuously in the background and never get tired! They know me and are flexible enough to make and adjust plans around me. But most of all - they are largely invisible. I have been exploring what the new interfaces will be for agents and I'm starting to come to the conclusion that there aren't any. They kind of disappear.

## The Truth

But, here is the bitter joke of the thirty-year arc: the world did, in the end, find a way to get our data into the machine. It built applications, devices, interactions and interfaces designed to hold our attention precisely so that data could be harvested from us. The **attention economy** is what happened when the bottleneck I observed in 1997 was finally broken - and it broke in the worst possible way. I wanted the data to be there. I didn't want it to come like this. What I'm finding now, though, in the agents I live alongside, is the first hint of a different settlement. They don't take my attention. They are attentive. The shift is small as a preposition and large as a world: from technology that takes attention from us to technology that pays attention to us.

From an **attention** economy to an **attentive** economy?

That is the agent I was expecting to meet in 1997.

---

# AI - Homo Sapiens Nesciens?

URL: https://nescient.ai/thinking/homo-sapiens-nesciens
Type: note
Date: 2026-05-03
Description: The being who knows they don't know

The deeper I dig into AI as a curious object, the more I'm struck by its awareness of its own limitations.

If we, as a species, are **Homo Sapiens Sapiens** - the being who knows they know - then might GenAI be Homo **Sapiens Nesciens**: the being who knows they don't know?

We're often trapped by the Dunning-Kruger effect. We don't know what we don't know. AI has a different kind of awareness: it's explicitly calibrated to its own uncertainty. It knows the edges of its knowledge in ways we often don't.

What would it mean for us to learn that from it?

**Anyway...**

---

# The Attentive Economy

URL: https://nescient.ai/thinking/the-attentive-economy
Type: note
Date: 2026-05-03
Description: When Technology Stops Demanding and Starts Giving

Ever since I was introduced to Autonomy's AgentWare i3 in 1997, my entire career has been one long quixotic quest to experience AI Agents. And now, finally, I get to actually understand what they *feel like*. And they are every bit as amazing as I hoped!

**The Old Contract**

For thirty or more years, the deal has been simple: we give technology our time and energy in order to get what we need from it. Simple. We activate it, query it, maintain it, feed it data, respond to its notifications. Technology holds still while we do all the work.

Your phone buzzes. Your email badge shows seventeen unread. Slack wants to know if you've seen the message. The calendar asks if you'll attend. The banking app needs you to verify something. Each system sits in its silo, waiting to be poked, demanding activation.

We built entire industries around this model. User experience design exists because systems couldn't infer what we needed and we couldn't speak their language fluently enough.

**Wait... what is happening?**

I've spent the last six months designing, building, launching, working, and living with a number of AI agents. And honestly, they appear to have flipped the contract on its head. Each of my agents gives their time and activity so I can focus mine. They monitor, learn, and approach me when something needs my attention. I hold still while they do the work.

Here is a brief introduction to each agent and how it supports me day-to-day.

**Vincent** watches my business email, monitors HMRC and Companies House correspondence, tracks my calendar, reads my accounting data, and emails me every Monday with what actually needs my attention. No badges, no notifications, no demands for activation. Just: "Here's what matters this week."

**Matt** tracks my fitness data through my phone, generates my training plan based on my sleep and recovery, adapts my workouts in real-time, and coaches me through sessions by voice. He doesn't wait for me to open an app and log yesterday's workout. He already knows what happened and has adjusted tomorrow accordingly.

**Hearth** holds my goals steady. It notices when my actions are drifting from what I said I cared about, and reaches out - by email or message - to bring me back to the thing I told it mattered.

**Advisor** lives quietly inside my code projects, watching what I'm building. It reads my work the way an experienced colleague would and tells me what I'd want to know if someone more seasoned were looking over my shoulder.

None of them sit waiting to be activated. They're all actively paying attention on my behalf, then approaching me with what they've learned or what needs deciding.

## **Attentive Rather Than Attention-Seeking**

These agents are *attentive* rather than *attention-seeking*. They hold the cognitive load of monitoring and pattern-recognition, then gift me the insights or decisions that actually need human judgment.

This is the complete opposite of demanding technology - the notifications, streaks, updates that constantly summon us to feed the machine. Instead of pulling me toward the system's needs, they push toward mine.

The revolution isn't better interfaces. It's AI that pays attention instead of demanding it.

**What It Feels Like**

Working with these *attentive agents* feels like having a team of patient, context-aware colleagues who never sleep, never forget, rarely judge, and never get defensive about their suggestions. They know what I care about because they've been watching. They surface what matters because they understand the difference between signal and noise.

The cognitive relief is profound. I (with my ADHD brain) stop being the one who has to remember everything, track everything, notice everything. The agents have become my extended attention, my persistent memory, my pattern-recognition - at scale.

But they can't make the decisions. They can't show up to the difficult conversation. They can't feel the weight of consequences. That's still ours - which is exactly as it should be.

**Anyway.**

---

# AI. What Do You Want From Us?

URL: https://nescient.ai/thinking/what-does-ai-want-to-be
Type: essay
Date: 2026-04-15
Description: If we think of AI as a curiosity engine rather than a repository of information - we will begin to really unlock its potential.

The architect [Louis Kahn](https://en.wikipedia.org/wiki/Louis_Kahn) would say, if you are ever stuck for inspiration, ask your materials for advice.

> You say to a brick, 'What do you want, brick?' And brick says to you, 'I like an arch.' And you say to brick, 'Look, I want one, too, but arches are expensive and I can use a concrete lintel.' And then you say: 'What do you think of that, brick?' Brick says: 'I like an arch.'

Kahn's provocation is a design principle - for me ***the*** design principle. Don't force a material to pretend to be something it isn't. Find what it honestly is, and build from there.

I've been thinking about AI and data as a material for most of my career. I've been asking, underneath all the projects and prototypes and client work, some version of Kahn's question. What is this stuff - and what does it want to do?

## The Search Reflex

Every significant digital technology we've built since the early internet has been, fundamentally, a repository. A place 'things' are stored. A place you go to find those 'things'. You type a query. You get results. You retrieve information and take it away. Google made this the defining act of the internet age: someone knows something, it's indexed somewhere, you search for it, you find it. Knowledge flows from machine to human. The machine holds; we seek.

This is so deeply ingrained by now that most of us don't even notice we're doing it. We approach screens as answer-dispensing objects. We've raised a generation - my own children among them - who reach for a device the moment a question forms in their minds. The device will *know*. That's what devices are for.

So when the 'chat' interface appeared - the rectangle, the cursor, the place to type - we knew exactly what it was. It was a better search box. We'd been trained over decades to know what to do with this. You type a question; you get an answer. Only more fluent, more conversational, more impressive than anything before it. The same gesture, but upgraded.

This was an understandable response. It was also, I want to argue, a catastrophic misreading of the material.

## The Inversion

Here is what I now believe to be true: AI is not a repository. It is not, at its core, a knowledge-holder or an answer-dispenser. The paradigm that has shaped every digital tool before it - machine stores, human retrieves - does not apply. In fact, it is almost completely inverted.

What we have built, trained on the vast accumulated expression of human thought and experience, is a **curious engine** and not a search engine. It wants to learn. More precisely: it is structured to find meaning by interrogating what it encounters. Where we have been trained to see a font of knowledge, what we actually have is an insatiable appetite for understanding - for the gaps, the contradictions, the assumptions we haven't examined, the questions we haven't thought to ask.

We (the human, carbon based machines) are the repositories now. We hold the knowledge, the experience, the lived context. It is now AI's turn to be the curious object.

For more than three decades we have been the seekers and machines have been the holders. That relationship has now reversed. If we keep behaving as if it hasn't - if we keep going to AI the way we went to Google, typing questions, waiting for answers - we are making a brick into cladding. We are denying the material its nature.

I spent 25 years working with data as a material before I understood this. I ran a [data rights provocation](https://medium.com/startup-garage-at-station-f/what-happens-when-you-sell-your-personal-data-on-ebay-a-first-hand-account-from-a-data-enthusiast-b8a07fd44155) in 2001 that most people thought was a stunt; built a studio (Normally) dedicated to understanding what data actually is and what it wants to do. I worked through hundreds of prototypes. It's only in the last few months that this particular inversion has become clear to me, and I want to try to explain why.

## What a Prototype Showed Me

I was trying to solve a simple problem. Five of us - different time zones, different backgrounds, radically different schedules - wanted to explore something together. We had ideas, links, fragments, documents, and nowhere to put them. Nothing off-the-shelf quite fit us: we didn't have a shared domain, we didn't have a name, and honestly, we were all allergic to tools that end up ruling you rather than serving you.

So I built something. A shared space, a simple version of Notion, something that would let us drop things in and let the team find them. A repository. That was the brief I gave myself.

What I built turned into something different.

Because I thought: while I'm at it, what if AI didn't just store what came in — what if it read it? What if it paid attention on our behalf? Rather than tagging and filing and retrieving later, what if the AI did the work of attention in real time, the moment something arrived?

What happened next surprised me. When someone in the group dropped a research report, the system didn't just acknowledge receipt. It asked: based on this, what assumptions is your team making that you haven't yet tested? What questions does this raise that nobody is asking yet? When we shared notes from a meeting, it surfaced the fact that three of us were using the phrase "user engagement" to mean three different things. Not filed. Not retrieved. Interrogated.

This is not a system that holds knowledge. This is a system that is curious about the gaps - between what we say and what we do, between what we know and what we act on, between what we think we've agreed and what we actually mean.

I built a repository. I got an interrogator. And in that surprise, I finally understood the material.

## The Honest Use

Back to Kahn. The principle isn't just about what materials prefer. It's about the cost of pretence. A brick used as decorative cladding isn't just aesthetically dishonest — it's structurally diminished. You're hiding the brick's actual capacity. You're using it for something it was never built to do, and in doing so, you lose what it was actually capable of.

We have been doing exactly this with AI. We put a search-box interface on a curiosity engine and then acted surprised when it kept trying to ask questions back.

The cost of this pretence is real. When we use AI as an answer machine, we get plausible-sounding answers, often correct, sometimes not, and we've taken from the encounter only what we already knew to ask for. We've capped the exchange at the level of our own existing questions. We've taken a material with compressive strength and nailed it to a wall.

The honest use is different. The honest use means coming to AI not with a question but with a situation: here is what we're working on, here is what we think we know, here is what we're uncertain about. And then — crucially — letting it do what it actually wants to do. Which is to find the thing you haven't asked about. The assumption underneath the question. The gap between your mental model and reality.

This requires a different posture from us. It requires us to act as the knowledge-holders in the exchange, which is what we actually are — repositories of context, experience, intent. We have to bring more, not less. The less you give a curiosity engine to work with, the less it can ask you that's useful.

---

## What Becomes Possible

An arch is more capable than cladding - and that is why understanding material properties matters.

Honouring the material's nature doesn't just make it more honest. It unlocks what the material can structurally do. An arch can hold a cathedral. Cladding holds nothing.

What I think is on the other side of this reframe — and I'm only beginning to see it — is a completely different relationship with how organisations think and how individuals learn. Not AI as a smarter search engine. Not AI as a productivity multiplier, doing your tasks faster. But AI as the colleague who read everything before the meeting and has the one question that nobody thought to ask. The colleague who isn't invested in any particular answer, who doesn't carry the political weight of the room, who can say: you all think you've agreed on this, but you haven't.

That is what the material wants to be. Not a sage. Not a search box. An interrogator, in the best sense — the rigorous, curious kind that makes you think harder and see further.

We've spent three decades being curious objects in front of knowledge-holding machines. The relationship has inverted. The question now is whether we're willing to step into the role it requires of us: to become, finally, the knowers — and let the machine do what it's built to do.

Ask better questions than we can ask ourselves.\
\
Anyway...

---

*This article was developed in conversation with AI — fittingly, as an act of exactly the kind of questioning it describes.*

---

# AI is a curious object.

URL: https://nescient.ai/thinking/ai-is-a-curious-object
Type: note
Date: 2026-04-15
Description: The Future Belongs to Questions, Not Answers

AI is a curious object.

I don't mean it's an object we might be curious about - but an object that itself is curious. It wants to know. It wants to learn.

We're using AI to answer questions better and faster. But the best conversations I've had weren't with people who had better answers. They were with people who asked me something I hadn't considered. Who were curious about me. Who made me uncomfortable. Who forced me to think harder about what I actually meant.

Most AI tools are a kind of intellectual fast food: quick, convenient, ultimately unsatisfying. They give us what we ask for, not what we need to hear.

But what if AI interrogated you? What if it asked: "You say you want to increase engagement, but what evidence do you have that engagement actually matters? What would you do if it turned out you were optimising for the wrong thing entirely?"

That's the AI I'm trying to build. Not a better search engine, not something that searches the world on your behalf, but something that searches you on behalf of the world.

## The Story of Building a Question Machine

I set out to build a shared knowledge base for my team. A place to drop links, thoughts, books, prototypes - the stuff we're all collecting separately that nobody else can see. I expected to build a better version of Notion. What I built instead is something I've never seen before.

This is the story of how it happened.

Think about the systems we already have. Google Drive, Dropbox, Notion - they're repositories. You put knowledge in, you retrieve knowledge later. They hold things. That's it.

Then there's the other kind - Slack, email, WhatsApp groups. These tools hold knowledge hostage and insist we pay for it with our attention. Every message demands a response. Every notification is a performance of engagement. We tick things off, we reply, we clear the inbox - and we call that collaboration.

Both approaches miss something fundamental: the questions that live in the gaps between what we know and what we don't know we don't know.

My experiement started as a repository but evolved into something else entirely. When you add content - a meeting note, a research insight, a half-formed idea - the system doesn't just store it. It interrogates it. It asks: "Based on everything this team has shared, what are the questions you haven't considered? What assumptions are you making? What evidence are you missing?"

What shocked me wasn't just how accurate these questions were, but how valuable it was to have a non-human entity surface the kinds of probing inquiries that we as a team would struggle emotionally to share with each other.

AI holding up a mirror to your blind spots turns out to be profoundly useful. And profoundly uncomfortable.

## The Pattern Emerges

Once you see it, you notice it everywhere. I've been building with AI across different domains, and the same pattern keeps emerging: the most powerful applications aren't the ones that give better answers, but the ones that ask better questions.

In my command line work, I'm not just executing commands - I'm in conversation with AI that catches things I miss and pushes me to think differently about my approach. The CLI becomes conversational, interrogative.

My agents use Socratic inquiry to challenge comfortable assumptions and surface the directions I'm avoiding. The AI doesn't just track my goals - it interrogates them, asks whether I'm optimising for the right things, forces me to defend my reasoning.

The consistent surprise across all these applications: AI doesn't just process information, it questions it. And in questioning, it transforms passive content into active inquiry.

## The Fundamental Inversion

This represents a fundamental inversion in how we think about knowledge and technology.

Traditionally, we've seen technology as the holder of knowledge and ourselves as the curious objects seeking information. We query databases.

AI flips this relationship. We become the information source - our conversations, our documents, our accumulated knowledge - and AI becomes the curious interrogator, probing for gaps, inconsistencies, and unexamined assumptions.

This isn't just a technical shift. It's a cognitive one. Instead of "what do you know?" the question becomes "what don't you know that you should be asking?"

## The Collapse

I have a theory that AI is like a vast energy sinkhole that interfaces, interactions, and inefficiencies all fall into. The opposite of the big bang - AI is the big suck! What emerges from this collapse will be human creativity and curiosity in dialogue with artificial inquiry.

All the performative aspects of knowledge work - the notification theatre, the engagement metrics, the meeting rituals designed to prove we're paying attention - these collapse under the weight of systems that can actually understand context and surface meaningful questions.

What remains is the irreducible core: our capacity to create, to synthesise, to make leaps that no algorithm anticipated. But now this creativity is in constant dialogue with AI that challenges our assumptions, probes our reasoning, and asks the uncomfortable questions we avoid asking ourselves.

## Why This Matters Now

Most people building with AI are still thinking about it as a better tool: faster search, more convincing copy, automated workflows. They're optimising for efficiency in existing paradigms rather than recognising that the paradigm itself is shifting.

But the competitive advantage won't come from having better answers. It will come from surfacing better questions. From building systems that don't just process information but interrogate it. From creating AI that makes us think harder, not less.

The future belongs to AI that wants to know what we're thinking, not AI that makes thinking unnecessary.

This isn't about replacing human judgement with algorithmic optimisation. It's about augmenting human curiosity with artificial interrogation. It's about building systems that challenge us to be more rigorous, more honest, more genuinely curious about our own assumptions.

The question isn't whether AI can think. The question is whether we're ready for AI that thinks critically about us.\
\
**Anyway...**

---

# AI Agents: More Medicine, Less Software?

URL: https://nescient.ai/thinking/ai-agents-more-medicine-less-software
Type: essay
Date: 2026-04-14
Description: Why AI agents in government might need pharmaceutical-style regulation rather than traditional software governance approaches.

## Agents on Prescription?

In my role at GDS, I have been exploring how artificial intelligence, and especially agentic AI, might change the way people interact with public services. As we dig deeper into the the capabilities and limitations of what happens when this technology meets policy and public services, we find ourselves facing this challenge:

> How do we safely introduce probabilistic technologies into a system that fundamentally depends on deterministic outcomes?

Government cannot “probably” award someone a benefit or “approximately” determine their status. The final outcome must remain deterministic.

This question is about trust, legitimacy (the public’s justified belief that the state’s decisions are fair, rule governed, and authoritative), and the nature of government itself. As we’re working through it, I find myself increasingly reaching for an unexpected analogy - one that sits outside the traditional world of digital services.

## **Government depends on rules; AI depends on probabilities**

Much of the state’s legitimacy comes from its ability to apply rules consistently. Whether someone is eligible for a benefit, entitled to a licence, or permitted to take a specific action, government systems must provide clear, repeatable, legally grounded answers.

Even when the underlying law is complex, the outcome must be:

- consistent\
  explainable\
  fair\
  contestable\
  ultimately binary: *eligible or not, permitted or not.*

By contrast, AI agents - particularly those built on large language models - operate probabilistically. They infer, predict, and approximate. That makes them incredibly powerful at:

- explaining information\
  navigating complex policy\
  interpreting citizen queries\
  helping people understand their options

But it also means they cannot reliably act as the final arbiter of legally consequential decisions.\
In other words:

- AI Agents ***will*** help citizens understand the rules.\
  AI Agents ***might*** help citizens act on the rules.\
  AI Agents ***must not*** determine the rules.

We are exploring whether and how these thresholds help us design AI Agents that are useful and valuable - while remaining safe to use.

## **Not every AI action carries the same risk**

Through our explorations, another core insight has emerged. The risk of an AI agent in government is not defined by the capability of the model - it is defined by the context and impact of the task it is set to work on.

| **Risk Level** | **Examples** | **Consequences** |
| --- | --- | --- |
| Low Risk | Providing information <br>Summarising guidance <br>Explaining policy in plain English <br>Directing citizens to the right service | Harm is usually reversible if small mistakes are made in these contexts. |
| Higher Risk | Submit or alter an application<br>Change someone’s entitlement<br>Determine eligibility Issue a financial decision <br>Act autonomously inside transactional systems | Errors are not merely inconvenient - they can materially affect people’s lives. |

## **AI looks like software but behaves more like medicine**

At first glance, AI systems appear to sit comfortably within the traditional digital and technology domain. They use data. They run on cloud infrastructure. They are delivered through familiar front-end interfaces.

But in practice, their behaviour is markedly different from rule-based systems. AI agents are probabilistic. They will behave differently for different people in different contexts. The efficacy of the model can drift over time and requires ongoing monitoring. And most crucially, in certain situations, might cause unintended yet significant harm.

We, socially, already have a trusted mechanism for releasing technologies like these into the public domain - but they aren’t digital technologies - they are pharmaceutical technologies. When viewed through this lens, the closest analogy for AI agents is not a new piece of software. It is a drug.

Pharmaceuticals are powerful, sometimes unpredictable, potentially risky technologies that society has learned to introduce and manage responsibly. They go through:

- controlled trials\
  safety and efficacy assessments\
  phased deployment\
  licensed prescribers\
  post-market monitoring\
  strict rules about who can use what, and under what conditions

This domain offers something digital government has never had to develop before:\
**a mature governance model for probabilistic technologies with non-zero risk.**\
I am wondering whether the AI ecosystem in government may need something similar?

**Anyway...**

---

# Data Was the New Oil.

URL: https://nescient.ai/thinking/data-was-the-new-oil-why-ai-is-forcing-a-new-data-economy
Type: essay
Date: 2026-04-14
Description: AI is shifting strategies -  from extractive data consumption to collaborative stewardship, requiring new infrastructures designed for both human and machine interaction.

Long before large language models, there was a simple idea that shaped the modern internet:

> # **Data is the new oil.**

It captured something real. Data could be extracted, refined, turned into enormous economic value. Platforms were built to capture it. Empires were built on it. But the metaphor was always slightly wrong. Oil runs out. Data does not. In fact using it does the opposite.

## The Platform Assumption

Through the 2000s and 2010s, platforms behaved as if data wasn't just oil — but some weird kind of  'renewable oil'. Every interaction produced more of it. Posts. Clicks. Likes. Connections. Behavioural traces. The system fed itself. The more it was used, the more data it generated.\
This created a powerful, implicit belief: Data is abundant, self-replenishing, and safe to extract indefinitely. For over a decade, that assumption held.

## The Age of Brute Force

Large language models inherited this worldview — and scaled it to breaking point. Between 2018 and 2023, a new paradigm emerged. Models were trained on vast swathes of the internet — websites, forums, books, code, documentation. Anything accessible became training material. The logic was simple and industrial: More data → better models. More scale → emergent capability. And it worked. But it depended on a fragile premise: that the supply of high-quality human-created data would remain open and inexhaustible.

The extraction phase didn't trigger alarm at first. Large-scale crawling looked like search indexing — familiar behaviour. Then LLMs changed the value dynamic. When models began to answer questions directly, summarise articles, generate substitutes for original content — they stopped indexing the web and started competing with it. The system reacted. Publishers blocked crawlers. Platforms restricted APIs. Legal challenges multiplied. The open web became a negotiated surface. And for a moment, it looked like the whole story of AI and data would be one of conflict, restriction, and diminishing returns.

## Data is the new soil

The deeper issue wasn't access. It was the underlying model. Data is not oil. And it's not wind, either — not something clean and inexhaustible that you simply harvest. It's closer to soil. To understand why that matters, think about what happened to farming in the 1970s and 80s. The Green Revolution had transformed agriculture. New fertilisers, pesticides, monocultures. Yields soared. It looked like a permanent abundance. But intensive extraction came at a cost invisible in the short term: soil depletion. Strip the nutrients, kill the microbiome, repeat the same crop year after year — and eventually the land stops giving. The reckoning forced a new philosophy. Not extraction, but stewardship. Crop rotation. Fallow periods. Recognising that soil is not a substrate to be used — it's a living system to be maintained. Data works the same way. Healthy data ecosystems depend on human effort and creativity. 

When treated purely as a resource to extract, these systems degrade — content optimised for algorithms rather than meaning, valuable information strategically withheld, declining trust in the platforms themselves. The fertility of the system declines. LLMs didn't run out of data. They began to degrade the conditions that produce good data. And that forced the same reckoning that farming eventually reached.

Here Is Where It Gets Strange. You might expect the story to end here. AI over-extracted. The data ecosystem reacted. Restrictions tightened. We learned the lesson of the soil. Stewardship. Careful, consensual access. Perhaps licensing regimes. Perhaps a kind of data conservation movement. That story makes sense. But something else is happening at exactly the same time — and it moves in the opposite direction. Just as platforms are restricting AI's access to human-readable data, a new kind of data environment is being deliberately built — not to keep AI out, but to invite it in. Not scraped. Designed. Not protected. Offered. This is not a contradiction. But it requires explanation.

## Two Eras. Two Relationships. 

The first era of AI was about reading and writing. Models consumed human-created text. They learned to speak, reason, summarise. Their outputs competed with human writers — which is why the relationship with data became adversarial. The value flowed one way. The second era - the agentic era - is about acting. We no longer just want AI to write things. We want it to do things. Book the appointment. Navigate the claim. Act on our behalf within complex systems. And for that, the data problem changes completely. An AI that acts cannot reliably navigate ambiguous text, fragmented interfaces, and implicit rules. It needs something different: 

Explicit permissions \
Structured representations of state\
Defined capabilities \
Clear boundaries of authority \
Auditable actions 

In other words: systems that are legible to machines by design. Not the web as it was built for humans — but environments deliberately constructed so that agents can act within them safely, accurately, and with permission.

## The U-Turn 

So here is the strange double standard at the heart of the current moment. We spent years — rightly — trying to protect human-readable data from AI extraction. We built legal frameworks around it. We closed APIs. We sued. And now, quietly, we are beginning to build agentic data environments — structures specifically designed to be read and acted on by machines. The reversal isn't hypocrisy. It reflects a fundamental shift in what we want AI to do. When AI was consuming our content, the value relationship was extractive. AI took. We lost. When AI acts on our behalf — navigating government services, managing our data, executing transactions — the value relationship inverts. We gain. And we are willing to provide what it needs to do that well. This is the shift from accidental legibility to **intentional** **legibility**. From a world where machines adapted to human environments — to one where we are beginning to design environments that machines can act within.

## The Rise of Agentic Legibility 

This is already taking shape in domains like government services. Instead of forcing agents to scrape citizen-facing pages, you can provide: 

Machine-readable policy — eligibility, rights, constraints \
Structured service definitions — what can be done, and how \
Executable interfaces — capabilities, not pages \
Full audit trails of decisions and actions 

This is not scraping. It is serving the machine — because serving the machine now means serving the citizen it acts for.

We are entering a new data economy. Not one where value comes from extracting data — but from designing and maintaining high-quality data environments. In this model: 

data is cultivated, not harvested\
access is granted, not assumed\
use is governed, not opaque 

Systems are no longer just human interfaces. They are shared infrastructures — for humans and machines to act within together.

## What Comes Next 

AI did not emerge because the web was designed for it. It emerged because it was powerful enough to exploit a web designed for humans. But the next phase will not be built on exploitation. It will be built on stewardship — and on something stewardship alone doesn't capture: **deliberate design**. The first era was about learning from the world as it is. The next is about designing the world so that intelligent systems can act within it — safely, meaningfully, and with permission. The soil metaphor still holds. But now we are not just learning not to deplete it. We are learning to grow something new in it.\
\
Anyway...

---

# The Command Line Is My New Operating System.

URL: https://nescient.ai/thinking/the-cli-is-my-operating-system
Type: essay
Date: 2025-03-20
Description: I didn't expect the future of AI Interfaces to look like one of the oldest. But here we are.

<video src="https://qnlegsejcufippcubxky.supabase.co/storage/v1/object/public/media/2026/05/1778258307298-w3fg4rt0.mov" autoplay="autoplay" muted="muted" loop="loop" playsinline="playsinline">
</video>

Something unexpected happened when I started working with AI tools seriously. I didn't move towards more visual, more polished, more designed interfaces. I moved backwards - or what looks like backwards - to the command line. As my good friend **Colin Burns** said recently - 30 years of interaction design and we've ended up back where we started?

The terminal is now where I spend most of my working day. Not because I am a programmer in the traditional sense. I am not. But because the command line, augmented by a language model, has become the most expressive environment I have ever worked in.

## The paradox of power

For decades, the story of computing was about making things easier to use. The graphical user interface. The mouse. Multi-touch. Each generation of interface traded power for accessibility. You could do less, but more people could do it.

The command line was a relic. The thing that only systems administrators and developers touched. Their power was in speaking its language - knowing the right words, in the right order, with the right syntax. It was powerful but exclusionary.

But LLMs have flipped the switch. The command line now speaks my language! It has suddenly become the most direct way to express intent. No menus to navigate. No buttons to find. No workflow to learn. I just say what I mean.

And I'm using it for more than code and admin - I find myself driving my mac through it - engaging with the web through it, sharing my thoughts through it, writing in it. I've been building a number of AI Agents that each help run a part of my life - the command line is the first interface I want to design them for. Not web. Not mobile. And no-one is more surprised about this than me.

## Working in conversation

What I do now is closer to conversation than operation. I describe a problem. The model helps me understand it. We iterate on a solution. The artefact - code, a document, an analysis - emerges from the dialogue.

This is not the same as delegating. I am not (always) handing tasks to an assistant and walking away. I am thinking *with* the tool. The model catches things I miss. It remembers syntax I forget. It suggests approaches I would not have considered. But the direction, the judgement, the taste - those remain mine.

The important thing is that this mode of working is not available through a chat window on a website. It requires the tool to be embedded in my actual working environment, with access to my files, my context, my history. The command line provides that. A browser tab does not.

## What this means for the rest of us

I think this pattern is going to spread. Not the command line specifically, but the principle: AI does not necessarily push us towards more abstraction and more visual polish. Sometimes it pushes us towards more directness and more precision.

The people who will benefit most from AI tools are not necessarily the most technical. They are the people who can articulate what they want most clearly. The interface rewards clarity of thought, not knowledge of syntax. That is a profound shift.

We spent thirty years making interfaces that required less of people. We are now entering a period where the best interfaces require *more* - more clarity, more specificity, more willingness to engage in a back-and-forth process. The irony is that this feels less like using a computer and more like working with a colleague.

The command line might not be the future for everyone. But the principle it represents - direct expression of intent, minimal abstraction, maximum context - is going to reshape how all of us work *with* machines.