The DSV Fund AI Dinner Club — August 2026 Member Showcase

Tuesday 25 August 2026 · The Clermont London, Charing Cross

Cleaned transcript — corrected speaker names, sponsor name, and garbled phrases; soundcheck noise and unintelligible crosstalk removed. Timestamps refer to the original recording.

---

23:01 — Welcome to the Summer Party

Host (Erik Schwartz): Hello, AI Dinner Club. Welcome to the summer party.

Tonight is honestly one of my favorite events of the year. Normally we bring outsiders into the room to share what they're doing, but tonight we said: let's share back with each other what we're doing in this room. For those of us who've been here the last two, three, four years — look how far we've come. It started as a conversation of "isn't AI interesting, isn't it going to change our business?" — theoretical. And here we are today, and it is changing our business. AI is becoming part of our daily lives, part of every conversation we have, and tonight we get to share back with each other how we're making that happen.

We've got a packed schedule tonight. My job is the hardest job in the room — keeping everyone to time. Speakers are guided to speak for about ten minutes, then we'll open up for questions.

A couple of housekeeping notes: if there's a fire alarm, please go outside — the stairs are that way. And of course, Chatham House rules inside the room — things we disclose are meant to be shared within the community, not outside. Enjoy the evening, and please bring your questions.

One quick announcement: no "Ship Your First App in a Day" sessions this month — we'll get those back on the calendar in October.

So — welcome, Kieren. Let's get you buckled up.

---

25:47 — Kieren Johnstone: Excessive Engineering, Extreme Engagement

(Primordial Soup)

Kieren Johnstone (Owner/Director & CTO, Red River Software):

Every creature in this world began its life as a few sentences described by someone at our stand. Those sentences became code. That code became behavior. And the behavior led to what we see here. And of course, when one species gets too dominant, the cat jumps in — with lasers.

I'm Kieren Johnstone, CTO and co-founder of Red River Software. We've spent 18 years building bespoke business software and solving difficult problems. For a tech conference in June, I wanted to create an AI experience that people could participate in, compete in, and keep coming back to. This is Primordial Soup.

To start, you scanned your attendee badge. A model extracted your name and company and added you to a team on the leaderboards. Suddenly you had something to play for — there were stakes, because you'd put your own name to it.

Then we asked you to describe a creature and its behavior in ordinary English — not its backstory or superpowers, but the rules: when it should move, eat, attack, defend, sleep, reproduce. An AI then turned that description into a JavaScript "brain." It suggested names based on your description, and a mathematical formula randomly generated appearance options for the creature. You picked a name, picked an appearance, and released it into the world.

This wasn't a chatbot pretending to be a creature. The JavaScript brain actually ran in real time, in a sandbox, for each creature, continually, with a 5-millisecond time budget for each decision. If it overran that budget, the creature was penalized.

And it did exactly what you told it — not what you meant. If you told it to eat but forgot to tell it to move, it would just stay still. Gaps and ambiguity in the description became visible behavior.

When a creature did something unexpected, we didn't leave people guessing — we added a "why did it do that?" feature you could press to see what was going on. That made the hidden decision process visible: what the creature could see, and which action it selected at each moment. A separate analysis AI would highlight which parts of the original description and which parts of the generated code were relevant to what you saw — so you could understand what happened and try again. Each person had up to five attempts.

Because there were leaderboards — individual creature, individual person, and company as a team — it gave people something to shoot for and compete on. And we did see people coming back. What showed us people were engaged wasn't what they said, it was that they tried again: 53 people submitted a creature (mostly students, since it looked like a game), and between them there were 155 attempts. About 80% made at least a second attempt, and 15 people used all five.

Those 155 submitted designs didn't stay as 155 creatures — they bred. Over the course of the day there were over 66,000 creatures, with more than 3,000 confirmed combat kills.

But there was an issue: once a strong species established itself, its descendants occupied the world and effectively took over. A newcomer wasn't competing on equal terms — it was arriving in someone else's empire. So we added aging, protection for newcomers, population and generation limits, food controls, and around 70 balance settings needed to keep the world playable. And then — the Cat God — healing newcomers and firing lasers at dense clusters of incumbents to try and balance things. It looked ridiculous, but it was solving a genuine balance problem.

The whole thing was 2D until two days before the event — there was no Cat God until the night before. In a conventional project, "what if this was 3D?" at T-minus-two-days would be insane. Coding agents moved that boundary enough for us to make the idea real and judge whether it would work.

Describe, build, observe, refine — that part isn't new; it's how good products have always been built. What AI changed is the cost of the middle step: making an idea real enough to judge. That cost became so much smaller that you can iterate far more often.

For an entirely different project, I needed a visual effect. Rather than asking which idea sounded best, I had agents implement all 60 candidates, run them, record them, and bring me the footage to rate and refine. I iterated on the strongest and discarded the rest. The agents weren't giving me a recommendation — they were giving me evidence. The judgment to narrow it down still had to be mine.

So — the title of this talk is "excessive engineering," but more accurately, the engineering wasn't excessive; the exploration was. We could afford to test possibilities that would previously have been unthinkable or economically unviable — 60 different visual effects, which is a crazy amount for us. But the more alternatives you can generate, the more important it becomes to know what to ask for, and what to reject.

The agents wrote the code. My role was to design and direct the system they were building — conceive the overall experience, decide how the pieces fit together, define the constraints, inspect the behavior, and redirect the work when the result was wrong. My team spent about a solid week testing it, trying different creatures, and helping refine all those controls.

That's the user-experience side. There's also a deep engineering layer underneath: simulation, generated-code control, networking, GPU rendering. Agents can implement these — the real work was knowing which decisions the system needed.

There's a great quote — Seth Godin puts it well: the most important skill in prompting is expertise in the domain you're prompting for. Primordial Soup makes engagement conspicuous, but engagement doesn't have to mean a game or lasers. In business software, it may mean clarity, immediate feedback, confidence, or a process that stops fighting the user. Our customers bring deep domain expertise; we bring software and UX expertise. Between us, AI makes more of the solution space affordable to explore together. AI makes variation — your expertise decides what survives.

So the question I want to leave you with: what in your own domain has become worth trying?

Q&A:

Q: What have you put into practice from this in your day job?

Kieren: The prototyping part, mainly. If we have an idea, there's no reason not to try it out — rather than "we'll have a prototyping phase," we can produce ten or twenty different options and build a whole pipeline around that. It's hard to overstate how much impact it has to put something visual and polished in front of a customer. Even something as small as a progress bar — we added parallax scrolling and a small flourish when it completed, and it engaged people enormously. That level of polish used to be something you'd never spend weeks on. Now I think it's exactly the differentiation people should be looking for, at least until everyone catches up.

Q: So it's AI-generated, and then humans select?

Kieren: Yes — but it's still the expertise of the client and us together that decides what aligns best. There's still a great deal of value in people using software and directing agents.

Q: How do you get the domain expertise into the agent in the first place?

Kieren: We tend to use Claude, which works well for us — but it's about the agent harnessing the expertise. The expertise itself still has to be human. It's well worth partnering with someone who has domain or technical expertise to use these tools properly. Humans are still very much in the loop.

---

39:29 — Mike Jones & Rob Warner: Import Skills, Ship Governed Agents

(RedOS — "Human Systems, Human Problems")

Rob Warner (Co-Founder, Red First): I'm Rob — Mike's here in spirit; he didn't make the shirt today. I'm going to talk about AI, but from a very human perspective. When we come to AI, the problems are very much human problems — human systems, human problems, and why AI implementations fail.

Michael's — sorry, our — business model is AI. So the question is: is that the right model? Why do some AI implementations succeed and others fail? We ran the numbers across several models, and they broadly agree: AI implementations that fail don't fail because the technology isn't good enough. If you're prepared to spend the money and find the right system, the tech is perfectly good enough. They fail to deliver P&L impact, and projects get cancelled, because of us — the humans implementing them.

When a business decides "I want AI, I want to transform," we hit two barriers, over and over:

1. "I think I know what I want" — but no idea what the transformation actually looks like, and even once they do, does it put their own role at risk? If you want to make a project fail, make sure it affects someone directly, and they can derail it.
2. Leaders not managing the change — because change is uncomfortable, and nobody wants to be "the bad guy" who tells the team something they built isn't working, or that a role isn't needed anymore.

So what do we do? We send in engineers — the "forward deployed engineer," a very fashionable job title right now: take the most expensive technical people you can find, send them into a business, and have them talk "human" to people to get buy-in for a transformation project. The trouble is, the person who's brilliant at talking to humans and the person who's a top-level coder rarely come in the same body — and that's where the money is going. AWS has put over a billion dollars into this. OpenAI has a deployment company for it. There are roughly 17,000 of these people in the US right now, and they start at $300,000 a year — completely unaffordable for anyone outside the very largest businesses.

So what do these engineers actually deliver? An AI system, in our view, needs six things: something to listen to the outside world, something to listen inside the business, somewhere to store that information once it's filtered and organized, something to do a defined piece of work with a start and an end (a workflow — not everything is an agent, please don't confuse the two), agents that use those workflows to deliver tasks, and somewhere to see what's actually happened — a dashboard.

Mike Jones (Co-Founder & CTO, Red First): Going in as a forward-deployed engineer, or even trying to implement this yourself, you're essentially starting from scratch every time. And there's no good, shared explanation of what an agent actually is — even Microsoft and OpenAI don't agree. We asked ourselves: what does an agent actually need? We settled on nine facets that define an agent, in our system, RedOS:

1. Soul — who am I, what do I do, how do I do it.
2. Knowledge — your price lists, how you deal with clients, whatever it needs to know.
3. Skills — repeatable procedures it can learn and use on demand.
4. Capabilities — what it can actually do, what it's allowed to do.
5. Listeners — read-only access to the outside world.
6. Connections — what it can connect to, and the governance around that (we've all heard about agents doing crazy things — deleting databases, wrecking file systems — because they had access they shouldn't have).
7. Surfaces — does it need a canvas, a spreadsheet, a UI to work in.
8. Heartbeats — a schedule for when it wakes up and does its work.
9. Guardrails — mechanical, programmatic controls so agents don't go off and do something they shouldn't (like emailing clients to say you don't want them anymore).

Demo: RedOS lets you edit all of these facets directly. One feature we built is agent import — if you've already built an agent (say, in Claude Code) and it's missing some of these nine things, we built an import flow: give Claude an extraction prompt, wrap everything up, and bring it into RedOS. When we import, we analyze the skills you set up, the MCPs you connected (that you're probably not sure what they still do), map all of it into the nine facets, then ask: can we make this better, give it proper guardrails, refine the skills, and make it safe enough to actually run in a business. In real time, you can import a Claude, Hermes, or OpenClaw-style agent in three or four minutes.

Q&A:

Q: Capabilities, listeners, and connections sound like the same thing?

Rob: It's a fair question — we've thought about it a lot. Capabilities are tools: can it use an app, can it search the web, can it do a task. Connections are things like MCPs and APIs — reaching out. Listeners are specifically read-only access — in our system we call this "RedNet," our listener system, which gives specific access to, say, a data warehouse.

We actually published an article on our site (posted the day before this dinner) asking: have we over-engineered this — could it really be nine, could it be eight, could it be fifteen? We ran a stress test: take each of the nine away, one at a time, and see if things break. If removing something made things worse, it was necessary — and all nine passed that test. We then tried merging neighboring pairs (e.g., capabilities and listeners) — and each time, it turned out we'd conflated two things with genuinely different purposes and muddied the spec. So far, we think nine is right. It may not be — but we tried hard to break it.

---

54:19 — Tom Mortimer & Anthony Basker: Posture Studio

(Locally-run, AI-powered motion capture)

Tom Mortimer: It was a Friday morning, and Mike phoned me and said, "Tom, come to a meeting." I said, "When?" He said, "This afternoon." The client wanted something for Pilates. Pilates and me don't exactly go together, so I called Anthony, who I knew could help.

We drove out to the client's place — turned out it was a children's football club, and they wanted to be able to capture children doing Pilates and track how well they were doing it, without needing photos or video of children. So the brief became: can we do full-body motion tracking locally, using AI, without storing any images — just data points?

Anthony Basker: We built this over about ten weeks. Every time a new model came out — Fable, for instance — we'd think "great, I can solve this now," and then it would get pulled back, so we'd switch to Codex and try again. It went back and forth for a while until we got a stable system. We even asked an ex-colleague who'd been head of motion capture at a games studio, and even he wasn't sure it would work.

Where we've landed: you can capture full-body movement on an ordinary webcam, in your living room, from a reasonable distance away. It's tracking around 533 points across the body — joints, face, expressions, hands, eyes and gaze — not video or photos, just the "bones."

Live demo: two people stand in front of a webcam; the system builds a skeleton model of each, overlays them, and scores how closely one person's movement matches the other's — like a game of "follow the leader," or a home fitness/dance game. (Demo run live in the room, with some technical hiccups from conflicting webcams.)

On privacy: because nothing is captured except skeletal data points, there's no image ever stored or transmitted — it never leaves the machine.

Tom: We're now working with a therapist who does EMDR therapy, where a lot of the technique involves tracking eye movement left and right — we can track whether a patient is actually doing the exercise correctly. Put this in an enclosed setting — medical, or sports — and you're suddenly able to do with a laptop webcam and a bit of AI what used to need dedicated motion-capture hardware.

We may end up not even using this for the children's Pilates brief that started it — we're realizing there may be other, better applications for it. Our ask: if anyone knows of other applications for this kind of technology, we'd love to hear about it.

---

1:02:50 — Dinner Break

(Guests move through to the dining room; toasts, birthday wishes, and table conversation — not substantively transcribable.)

---

1:24:21 — Sponsor Thanks & Second-Half Kickoff

Host: Before we move into the next part of the evening, I want to take a moment to thank Simon and John from the DSV Fund. Without their sponsorship and investment, we couldn't put on an evening like this. Please join me in a round of applause — they've been core supporters of this event.

Next up, we've got a man who's promised to get his talk done in eight and a half minutes... he's been with us for a while, and he reconnects us with the spirit of why we're doing this. It's not just about the technology — it's about making us better humans, and finding better ways to connect. Over to you.

---

1:25:34 — Baiju Solanki: Why Humanity's Edge Is Even More Relevant in the Age of AI

Baiju Solanki (Performance Psychologist; author, Humanity's Edge):

For those who don't know me, I'm a performance psychologist. We're living in an extraordinary time — we've been given this incredible tool, AI, which has already changed how this room thinks and works. But the thing we most need to focus on isn't the tool — it's the human using it.

All three talks tonight so far have touched on the same bottleneck: humans, and our attitude to change. AI is never the bottleneck — the tool is never the bottleneck. If you're a leader or a founder in this room, the single biggest issue is accepting and driving change.

So — is AI the differentiator, or are you? I want to walk through six shifts.

Shift 1 — Output stops proving value. Being does. If we all had the same tools and the same approach, we could all produce roughly the same outputs. The differentiator is the person behind it — how you're showing up, what you're doing to develop your own thinking and your team's.

Shift 2 — Judgment outranks knowledge. Knowledge is now a commodity — anyone can ask an AI model about, say, diabetes for an hour and sound like an expert. What isn't commoditized is judgment, and judgment is shaped by your emotional state, your confidence, your sense of self-worth. AI knows more than anyone alive — it never gets tired, never has an off day, never says "I'm not good enough." That means our judgment is more important than ever, not less.

Shift 3 — Trust becomes the scarcest currency in business. We're so used to polished content now that the first question anyone asks is "is this real?" A mentor of mine once told me: attention is your greatest commodity, but attention without trust is worthless. Trust can be destroyed by one lapse in judgment — I know of a case where an apprentice sent a client an email drafted, unedited, by a free chatbot; the client's reply was simply, "my trust in your company has gone down." One email, no personal touch, and trust was gone.

Shift 4 — Self-led humans beat the best AI. Self-leadership is about how you show up between the meetings, between the versions of yourself. A team of self-leaders is accountable, keeps its word, is on time, and owns its mistakes before someone else finds them. A company full of people leading themselves from their own values — and the company's values — has a real differentiator.

Shift 5 — Accountability loses its excuses. A report that used to take two days can now take a couple of hours. "I got too busy" doesn't hold up anymore. My rule with my own team: manage your expectations, stay in communication — that's it. Life happens, but tell me before, not after.

Shift 6 — Undeniable humanity becomes the edge. My premise is that AI will bring humanity back together, not pull it apart. There are more ways than ever to meet people — apps for friendship, apps for dating — and yet more people are lonely than ever. If AI isn't adding value to you as a human, what's it actually for? In a world full of artificial intelligence, the most valuable thing a leader can offer is their own, undeniable humanity — story and wounds included, still standing. Ask yourself: are you the best human you can be? If not, who do you need around you, and what conversations do you need to have?

Q&A:

Q: (to Baiju, on age) How old are you?

Baiju: 55. [Discussion of AI knowing more than any one person's lifetime of accumulated experience, and what that means for younger generations who've grown up with it — his own adult children, for instance, use AI and Snapchat but still prefer meeting friends in person over staying in their rooms.]

Q: Shift five mentions courage — what's the role of courage?

Baiju: When every resource is one prompt away, "I didn't have what I needed" stops being valid. What's left is whether you're courageous enough to change, and to admit you might be wrong instead of just wanting to be right. Most people in leadership want to be right, rather than to make progress — and that's what really limits accountability.

Q: Do people need to be trained to make friends?

Baiju: Not trained exactly — more that they need to let go of assumptions about the other person and simply have the courage to be interested in them.

---

1:43:38 — Calum Miller: Custom Applications With AI

(Millersoft — "Sheetloom")

Calum Miller (Founder & Director, Millersoft):

I'm based up in Edinburgh, but it's been my pleasure to come down most months for the AI Dinner. We produce a product called Sheetloom. The problem it solves is collaboration across enterprise boundaries.

You'd think, in the age of automation, that communication between organizations would be fully automated via files and APIs — but it isn't. There's still a huge amount of manual, brittle paper-shuffling via Excel, because different organizations have different security requirements, different geography, different legal bases, and different levels of AI maturity.

The example I want to give is delayed hospital discharges — a very topical issue in the UK, costing millions a day, where patients who could be moved to a care home stay in hospital because information isn't flowing. We've also worked on a similar problem with a health organization in Australia. On one side you have the hospital team — doctors, nurses, a discharge coordinator — and on the other, the care home providers. Information about patient readiness and bed availability moves between them with a huge lag, causing real allocation problems.

The same pattern shows up in justice, and in any organization that's grown through acquisition without ever integrating its systems. Sheetloom exists to get everyone onto the same page of context. It's a cloud collaboration platform that connects to the operational APIs and databases underneath, generates a tailored, up-to-the-moment spreadsheet for an individual, and then writes changes on that spreadsheet back into the operational systems — either directly to a database or via API calls.

We built the first version as a very generic, one-size-fits-all application — we went round accountants and care home providers and built something we thought met everyone's needs. But once we'd incorporated every feature, it became a solution built by techies, for techies, and it was hard to sell. So we used AI to dumb it right down: a tailored version for the care home, built with Claude generating the reports, with a simple workflow — the care home downloads what the hospital knows about them, updates it, and that update triggers an event back to the hospital. We did the same for the hospital side.

Then we asked: can we simplify this further, and just get rid of the standalone application entirely, and work where the users already are — in Excel? So now there's a plugin in Excel: users select the reports they want, the data downloads into Excel, they make their changes, and hit submit. As far as the end user is concerned, our application has basically disappeared — despite the years of engineering behind it. Clinicians and care providers are both just working in a spreadsheet.

Three takeaways: you don't need to build a sophisticated application just because AI is a sophisticated tool — you can take an existing, over-complicated application and use AI to make it radically simpler. We're now teaching ourselves to have "complexity intolerance," and we finally have the tools to act on it. And we've shifted who we sell to — not the IT departments who never quite understood "Sheetloom," but the CEOs who understand "a patient discharge system that solves a problem they can see."

Q&A:

Q: How does this differ from Copilot / an AI agent?

Calum: It doesn't replace Copilot — the spreadsheets we generate are Copilot-compatible, so Copilot has the data it needs to build a model, dashboard, or regression analysis. Sheetloom just makes sure Copilot and the right data are in the same place — and that data can come from your own backend systems or from a CSV someone's handed you.

Q: How is it delivered technically?

Calum: It's delivered as a PaaS platform, run on your own AWS environment. Events — like a bed-forecast update — can trigger your own downstream processes inside that environment, including analysis by one or more agents. It's a completely open architecture you can build on.

Q: (Comment) I love that you've built the solution inside the way people already work, rather than forcing a new workflow on them.

Calum: That's exactly it — if you build your applications on a clean API, AI tools like Claude can work directly from that context and tailor the experience without you having to force a new interface on anyone.

---

2:10:26 — Angus Gow: "Dark Factories" — The Future of Software Development

(introduced as "my good skiing buddy")

Angus Gow (Fractional CTO):

I've had a client — Regroup, a huge UK recruitment consultancy — who'd spent millions and years of development on an AI tool set with a previous supplier, and it still wasn't working properly. They called me back in and asked for help fixing it. I told them: why don't we just build the whole thing from scratch? They were horrified, understandably, given what they'd already spent — but I thought we could do it quickly.

So we built a complete, enterprise-ready AI recruitment marketplace for Regroup, from scratch. It's a regulated business. We deployed 150 developer agents, across ten waves of development — 16 services, 13 runtime agents and apps, and a fully normal, old-fashioned relational database underneath with about 130 tables. It was built by two developers doing most of the specification, in six and a half hours.

That got us a strong starting point — it then took another three months to finish properly. What we learned along the way:

The speed of software development right now is genuinely disorienting. We're doing around 100 pull requests a day, where a single developer might normally do three a week. At that speed, if you're not careful, you end up with code that looks plausible but doesn't actually work — and you won't find that out for a long time. So we've had to build new disciplines around this, and the main one is harness engineering — we now have a dedicated harness engineer whose entire job is to keep the harness in check. The harness specifies everything about the business: every decision, every input into Claude Code, everything it needs to know, and it's the mold the agents get poured into to build the software — covering business decisions as much as technical ones.

We specified this project the way you'd have specified a mainframe system in 1989 — the initial spec ran to around 400 pages and took about eight weeks to write, with three people working on it, before any code was written. Agile had quietly let us forget how to do this, so we had to relearn it — we now have more business analysts and knowledge-management people than developers. Everything has to be evidence-backed: every line of code is traceable back to the specification that produced it, with cryptographic tracking so we can say exactly which agent produced a given line and who was supervising it. Nothing appears in the code without a source — and if it does, it gets caught and stopped.

Guardrails before genius. Agile, done badly, can turn into a kind of free-form jazz — try something, if it doesn't work try something else, and eventually land on something that works. AI tools can do that, but you cannot "vibe code" a bank platform or a regulated environment. The guardrails sit at the edge of the harness: architecture, tooling, design patterns, database rules — all specified up front, alongside the business, legal, and HR rules.

The agent team is structured like a traditional SDLC: investigate, specify, build, verify, repeat — wave after wave, 150 agents across ten waves, which produced that initial six-hour build. At the end of each wave there's a gate where the work is checked against requirements, and a human decides whether it's good enough to move on. Anything that goes wrong gets discarded, and what went wrong feeds back into the harness.

What we ended up with is a live platform — read.ai (Regroup's recruitment platform) — covering the entire recruitment lifecycle: employers set up accounts, run AI-driven candidate matching using an agent modeled on James Reed's voice, interact with candidates, schedule interviews, handle compliance (Regroup does a lot of government and MOD work, so there are dedicated compliance agents), make offers, and seal contracts. The whole thing took about 13 weeks with two developers — one of whom doesn't usually write code anymore. It went through a full CREST-accredited penetration test, and came back with just one advisory: that the API token timeout of one hour was considered too long. I've never seen a result like that before.

Underneath all this sits Flow Machine — an enterprise-grade agentic control plane that can run in Google Cloud or AWS and controls all the agents — and Flow Rama, which I built as a spiritual successor to an old IBM tool called Rational Rose, for managing the entire specification and requirements harness that feeds into Flow Machine. If you had a good specification, Flow Machine could build something like HubSpot or Salesforce — I reckon that would be about seven hours' work.

So — fast is easy, we know that because we're all doing it. Governed fast is the future, and that's where enterprise software is going. That's the "dark factory."

Q&A:

Q: How long did the specification take?

Angus: About five weeks, with three people. We thought that would be plenty — it wasn't nearly enough.

Q: What did it cost to build?

Angus: The first build was about £100 in token spend. Ongoing, we're running at roughly £1,000–£1,500 a month per developer.

Q: Is Flow Machine / Flow Rama available to license?

Angus: Possibly — I haven't fully worked out what to do with it yet. I've got a long list of other software I want to build with it first.

Q: Do you capture why each agent made each decision, not just what it did?

Angus: Yes — there's a full knowledge graph of every decision made, including the bad ones.

Q: Could you run five parallel builds of the same feature and have an LLM judge which is best, rather than getting the spec right up front?

Angus: You could, but I think it's faster just to get the specification right in the first place.

Q: Can you use AI to help build the harness/specification itself?

Angus: Yes — that's what Flow Rama does: it uses an AI agent to produce the harness that then feeds into the build. My sense is that for every project the harness will be slightly different — there's no one-size-fits-all, especially at enterprise scale.

---

2:26:06 — James Puddicombe: Inside My AI Foundry

James Puddicombe (AI Business Strategist; former Innovation Director, Yamaha Music):

I've been amazed, like everyone here, at what we've seen tonight. I'm the light entertainment at the end of the evening — the contrast to everything technical you've just heard. Today I want to talk about taking control of "one-shotting."

Who's tried one-shotting? Give an AI a broad intent — "go and build me Skynet" — maybe with a bit more detail, "make no mistake," and it goes off and builds it for you. Maybe it takes six hours. You celebrate — you got exactly what you asked for. Then the real world hits: you're live, you're getting feedback, maybe the legal team wants you to handle some new "robot rights" regulation. You think, "I'm good at one-shotting, I'll just one-shot it again" — but you can't, because now you've got live users, production data, and security to worry about. You've run out of one-shotting; now you have to do the real work.

So I built myself a small, deliberately unprofessional, amateur system whose job is to build systems — to explore what it actually takes to do this properly. It's called coder-team, and it's been running for 147 days, across 45 different projects — some experimental (build Skynet), some real product launches, and some "platform takeovers" (someone rings you and says, "I've got this system, I don't know how it works, can you take it over?").

Some numbers from those 147 days: over 4,000 "changes" processed (a change being the full unit — specification, tests, everything — not just a pull request); 22,000-plus agent instances spawned; 79 billion tokens processed. My own bill was more than Angus's £100 — mine is an inefficient, exploratory system, not a lean one. But what I did build in was a self-improvement loop: the system constantly examines what's happening, what problems it's hitting, and improves both its own code and how it operates.

I discovered I was actually getting in the way. I'd look at a problem and tell the system what to do differently — and then realized I should just ask the system what it thought it should do differently. I worked my way up through three or four levels of "getting out of the way": from "you're being inefficient with tokens, fix that" all the way up to "the process we're following is broken — what should we be doing differently at a higher level?" Eventually the system was able to consider, at a fairly high level of abstraction, what it should change about itself.

Four things I'd do differently, or that I've learned:

1. Don't let the "buggers" talk to each other. I thought it'd be clever to let agents message each other directly, like a team having conversations. It was a terrible idea — they get into chaotic, time-wasting chatter (make of that what you will about human middle management). The fix borrows from termites — this is called stigmergic communication: rather than holding meetings, they leave signals on a shared board and each agent decides what to do based on what's there, rather than talking to one another directly. The ratio is now about 264 board-signal reads for every one direct message — a very "urgent" mode reserved for rare occasions.
2. No model can build well from a bad spec. If you get the spec wrong, no amount of expensive model will save you.
3. You often only need cheap models — if the spec is good. Across a bank of maybe 100 different LLMs the system can choose from, we found up to a 78x cost variation between models that succeeded equally often, once the spec was solid.
4. A good spec describes the goal, not the implementation. Early on I was over-specifying how to achieve things — security mechanisms, performance optimizations, specific UX choices — rather than describing the standard to reach and letting the AI work out how. It's a bit like raising children: when they're young you spell out exactly what to do; as they get more capable, you give them a long-term goal and let them work out the "how."

Summary: don't let them talk to each other; no model builds well from a bad spec; you usually only need cheap models if the spec is good; and a good spec describes the goal, not the implementation.

Q&A discussion: touched on replacing the underlying SDK with an open, model-agnostic layer so any LLM can be swapped in; and testing a large bank of past "changes" against a range of LLMs to build heuristics for which model suits which type of problem, rather than hand-writing those rules.

---

2:38:40 — Steve Forbes: Building 14 Products With AI

(unlisted bonus talk)

Steve Forbes:

I've been building information systems for other people for 40 years, and I thought maybe now's the time to build them for myself. Creating a digital product from an idea used to mean an 8-to-10-person team and roughly £1,000,000 a year — which meant most ideas simply never got built. I had ideas, though, and over the years I registered a lot of domain names — some over 20 years old — that were really just bookmarks on ideas I felt I had to build one day.

Now, with AI, I'm building 14 products for around £500 a month, total. A quick tour:

• Trainio — like Airbnb for corporate training: lets small independent trainers supply their services to large companies that wouldn't otherwise have the contracting relationship to hire them.
• NEWT — built on a mainframe simulator I wrote; effectively a "Friends Reunited" replacement, since the original was shut down and people still want a way to reconnect.
• Liberaite — a family-friendly search engine (harder to filter than you'd think — currently around 200,000 vetted sites, working toward far more).
• Email Alert — checks all your email accounts every 15 minutes and buzzes your phone only for VIP senders or urgent keywords, so you never miss what matters in the noise.
• Family Internet — lets families pool and store shared documents, stories, and information across generations.
• Lightning Classics — helps people find and rediscover out-of-copyright books.
• BenchServe — a B2B marketplace connecting consultancies whose staff are "on the bench" (between projects) with companies that have work.
• Dinner For Eight — a connection/dinner-matching concept, in the same spirit as tonight — meeting people over food, in a large organization or with strangers.
• cOnDoLiFe — a rebuild of an old (1999) web comic project, using AI to piece the site back together from fragments of old files and scraps found online. Won't make any money, but was a fun three-hour exercise.
• Smart360 — a 360-degree feedback tool for organizations.
• First Invoice — a simple invoicing platform, originally just for himself.
• Gig Direct and Exec Direct — connecting people to gig-economy work, and connecting boards/senior managers to individuals who can help them.
• GovWork — built by asking AI to design a profitable online business with no further direction; it came back with a system that aggregates roughly 300 government tender/work websites and alerts you to relevant opportunities.

His process: weeks of thinking, often waking at night to write ideas down; feed everything into AI until you're "dry"; ask it to interrogate you with up to 100 questions (can take up to ten hours); turn that into a product book, which becomes the specification handed to the AI development team in batches. The longest single batch of work he's given an AI team took 30 hours. His first product, Trainio, took 18 months and three restarts to get right; his most recent, BenchServe, took five days using the same process, refined.

The method, in short: create a product book, build in large batches, then refine with humans. Building the system isn't the bottleneck anymore — the real world is: user experience (making something people actually love), professional services (making sure it's compliant and legal), marketing (making people aware it exists), and sales (paying customers are the only real litmus test) — and all four still need people.

Q&A: discussion of which tools he uses (a mix of ChatGPT and Claude — "it doesn't really matter which"), and pushback that this isn't really "vibe coding" so much as engineering supported by AI, since it still involves stress-testing the business model, competitors, and pricing before any code is written. On which of the 14 might make money first, the group's consensus leaned toward BenchServe (simplest, clearest value) and Family Internet (strong potential PR angle around family archives).

---

2:54:07 — John Small: Agent Harnesses Use Freeform Prose

(Ontology Engineering)

John Small (MSc, MMath, MInstP — 40 years programming; Founder & Developer):

We already know what prompt engineering is. Context engineering? Yes. Harness engineering — which we just heard about? Yes. Ontology engineering? Also yes, for a few of you — and that's the point of this talk.

There's a clear progression here: prompt engineering, to context engineering, to harness engineering — at each stage we're putting more structure around our agents to get them to do what we want. And it's basically the theme of the whole night: give the agent more structure, more skills, get the specification right. That's really just people fumbling their way back to a very old, very IBM-style discipline of getting specifications right and spending real time on them.

The next step is that agent harnesses, today, mostly run on freeform prose — markdown files. And that freeform text turns out not to be structured enough. Google, for instance, has come up with an "open knowledge format" that adds structure to markdown files; Obsidian adds its own extensions to markdown. But adding extensions to something that's fundamentally a bit primitive is a sign the format wasn't good enough to begin with.

If we look back, there's already a technology built for exactly this: XML — extensible markup language. It didn't catch on widely in the past because writing all the schemas and specifications was too much cognitive load for humans. But now, with AI doing a lot of that work, that barrier has mostly disappeared — and AI actually wants more structure in its instructions, not less.

That's what ontology gives you: it makes meaning clear. I was building my own harness using Atlassian Confluence and Jira — which is brilliant, it produces beautifully detailed tickets and specifications. But it's designed to look good for humans — not to be meaningful for an agent. I got increasingly frustrated realizing I was writing things to look good on a page for a person, rather than to be unambiguous for the agent — and that's exactly where ontology comes in.

Going back to the standards work done in the 2000s around XML, there are already well-established ontologies for project management, for exchanging financial information, for compliance information — all worked out years ago, and still in active use by enterprises today. What's happening at the community level right now — people experimenting with markdown-based harnesses — is that they're gradually rediscovering the value of good schemas. I sometimes call Google's open knowledge format "XML for slow learners."

Ontologies matter enormously once agents start communicating with each other: if one agent sends loose prose to another, which sends prose to a third, meaning drifts and gets lost along the way. Structured ontology lets you preserve intent across a whole chain of agent-to-agent communication. So what I'm doing is going back to old, established XML-based project-management schemas and ontologies, and stitching them together — which is far easier today, because AI is very comfortable doing that stitching, in a way that used to be too much cognitive overhead for people.

A classic example of the underlying problem: "fruit flies like a banana" — genuinely ambiguous to a human or a machine without more structure. With a clear ontology, you could unambiguously mark whether "flies" is a verb (insects enjoy bananas) or "like" is a verb (fruit, thrown, falls the way a banana does) — removing the need for the AI to guess from context alone.

Ontology engineering, I think, is going to be the essential skill for enterprise AI in particular — for a small website it barely matters, but at enterprise scale, where you're exchanging financial or compliance information, "close enough" isn't good enough.

Q&A:

Q: Isn't that just... grammar?

John: In a sense, yes — AI has become very good at inferring grammar from context, but "very good" isn't "perfect," and when you're exchanging financial or compliance information, you need something closer to perfect. A good, unambiguous spec means fewer assumptions for the AI to fill in.

Q: Should UML be part of this?

John: UML is excellent for the design layer, and UML designs can themselves be expressed and exchanged in XML format between organizations — the two work well together.

---

Closing

Host: Nine talks, eight-and-a-half minutes each, in a bit over three hours — and it felt like ten minutes. Thank you to every speaker for such a brilliant, generous night.

Please join our WhatsApp group if you're not already in it — that's where the conversation continues between now and next month. The next AI Dinner will be 29 September 2026 — a big one, with NVIDIA and Alpha School joining us. Come and join us — it's going to be epic.

(Group photo; event closes.)