Agents
I build agents to learn what they can carry.
Four agents, from a weekly check of our websites to an iPhone and iPad app built with a team of coding agents. Each one shows what it does, where it went wrong, and what changed. The list grows as new ones earn their place.
Most organisations have bought the tools and run the pilots. Far less has reached production. I build agents myself because it is the fastest way to learn where they break. Some run inside my team at work, some on my own time, and all of them meet real pages, real users, or real data.
Spot
A weekly check that finds what is broken on our websites before a customer does.
Every web team knows the moment. A campaign goes live, someone opens it on a phone, and a headline breaks mid-word, a button label spills onto two lines, a row of product cards turns into a staircase. Nothing is down. It just makes a brand look careless, and with hundreds of pages in many languages across Europe, nobody can check them all every week.
Spot is an agent whose job description fits on a sticky note: check the pages that matter on a phone-sized screen, find what is broken, and show exactly where. It mapped about 190 key pages on its own and now runs every Monday at 7:00. The first full run checked 186 pages in under four minutes.
The most important decision was not mine. The brief said to look at screenshots the way a human reviewer would. Spot proposed to measure instead: load each page in a phone-sized browser and read the layout directly. Does text overflow its box, does a button wrap, do cards in a row differ in height, does a link lead nowhere? Only then does it crop a screenshot of the faulty element. That made it fast, cheap, and repeatable: the same page gets the same verdict every week.
Illustration: Spot scans a product page on a phone-sized screen. It finds a headline that splits mid-word because the text overflows its box by 14 pixels, and files it as a high-severity issue with a cropped screenshot.
It also got things wrong. It reported menu links as broken that only open a submenu; it re-tested them, marked them as false alarms, and changed its own rules. In its second week it closed two issues as fixed that were still broken, so an issue can now only be closed when the page was rechecked in the same run. Every issue lands in a shared database with its screenshot, updates itself when it comes back, and closes when it is fixed. People decide what to fix, and Spot asks before it deletes anything.
- Status
- Runs every Monday inside my team at work.
- Built with
- A Grok bot, Cursor, and Notion agents, with a phone-sized browser doing the measuring.
Hirsla
A native iPhone and iPad app, built with a team of coding agents.
Hirsla is a small place for the things in between: door codes, claim numbers, the restaurant a friend recommended. You share it in, your phone writes the card, and you ask for it later. The AI runs on the device, and nothing goes to a server of mine.
Illustration of Hirsla in four steps. One: a restaurant page is shared into Hirsla from the share sheet. Two: it is kept in the library at once while the iPhone reads it. Three: the phone writes the card, Trattoria Rosenweg, Rosenweg 12, Old Town, with four facts. Four: asked where the place Marco mentioned was, Hirsla answers Trattoria Rosenweg, Rosenweg 12 in the Old Town, names the card it came from, and notes that it answered on this iPhone, from the cards only.
I am a product leader, not a Swift developer. Hirsla is how I tested whether that still matters. I directed a team of coding agents one decision at a time, from the first entry in the decision log on 5 October 2026 to submitting version 1.0 to App Review on 19 October: about 33,000 lines of Swift, an iPhone app with a share extension, widgets, and an Apple Watch app, 331 automated tests, and 17 languages.
The method mattered more than the model. Each agent reads its working rules at the start of every session, replies with a plan, and waits for my go. It makes the small calls itself and writes each one down; the decision log holds about 370 of them. It has to stop and ask before anything that touches user data, costs money, or cannot be undone. Every mistake becomes a rule. When a sample door code in an instruction came back as a real answer, the rule became “no concrete values in instructions”. When App Review rejected build 4 over a single word, every language was checked before the next upload.
Illustration: Niklaus: Sync crashes. Plan first, then wait for my go. Agent: Six suspects checked, one cause found. Plan attached. Niklaus: Go. Agent: Fixed, tested, and logged in the decision log. Niklaus: App Review rejected build 4. Agent: One intent text named Apple. Rule added, all 17 languages checked.
Before 1.0, six reviewing agents with no history of the build read the code, one area each. They found about 50 issues; 15 were fixed before 1.0, and one finding was wrong. Translation ran the same way: a glossary per language, three translating agents, and one reviewer.
App Review turned down build 6 as well, under guideline 3.1.1: Restore room asked for the Apple Account password, which purchases like card packs cannot use. Build 7 removed the button, and room now comes back by itself from the purchase history.
Version 1.1 followed the same method. It brought Hirsla to iPad and iPhone Duo, added drawing with Apple Pencil, and numbered every sentence of an answer to its source. Before the first 1.1 build went out, six fresh reviewing agents read everything since 1.0, one area each.
- Status
- On the App Store.
- Built with
- Claude Code and Swift, with Apple’s on-device models.
Briefing
A campaign brief goes in, and a wireframe with the real copy comes out.
My first agent built finished-looking landing pages from our design system. It worked, and it was the wrong tool: shown a polished page, people discussed the colours instead of the argument. Several asked for something rougher they could push around. So Briefing builds a wireframe: grey blocks, real copy, nothing to admire. You drag the blocks, click any word to rewrite it, and hand the result to design.
Illustration: a brief for a city bike subscription asks for sign-ups, says there is no minimum term, and rules out prices. The agent pulls out the goal, the must-say and the never, then builds the wireframe block by block: a hero, Ride all winter, stop any month, with one button, Start your subscription; a proof block, rated 4.8 by riders, marked VERIFY because the source is missing; three benefits; and a closing block with the same button. You can drag a block or rewrite a word, then export the page and a handover that lists what is in and what was left out.
The agent writes the page, and plain code checks it: copy limits, one primary action per page, banned phrases, no prices where they are not allowed. If something fails, the model gets one repair pass with every error at once. Facts it does not know stay marked as [VERIFY] or [LEGAL] instead of being invented.
Illustration: a brief goes in and comes back as nine blocks, checked in code. The headline passes its copy limit. Two calls to action, where one is allowed, are fixed in a single repair pass. A test result marked VERIFY and a footnote marked LEGAL are left for a person to check. What fails goes back to the model once, with every error at once; what it does not know stays marked, never invented.
Most of the work was taking things away. The brief form went from 20 fields to four, because the brief itself was the place for the detail. The building blocks went from 18 to nine. A length rule that threw away good pages became a warning: a check that rejects output claims the output is unusable, and that claim had better be true. And when nobody used either export, the tool learned to write a handover that lists what is in the page and what was left out.
- Status
- Used on real briefs since September 2026, behind a password.
- Built with
- Claude on a Cloudflare Worker, with the checks in plain code.
Handshake
What buying looks like when both sides have an agent.
A shopper asks their assistant for filter bags. The assistant talks to the shop’s selling agent, and each one works for its own side. Handshake is a working demo of that exchange, built for one question: what does a business that sells through people do when the customer sends software?
The answer depends on what is being bought. For refills and accessories, the agent should just buy. For a large appliance, the right answer is often a demonstration at home, not a checkout, and the shop’s agent has to make that case well enough that the other agent accepts it and puts it to the person. Software cannot be charmed; the argument has to stand on its own. And when the purchase goes through, it still ends with a named person who takes it from there.
Illustration of the two answers. Your assistant: Filter bags for the vacuum, please. We are nearly out. Shop agent: One pack fits your model, and it is in stock. Your assistant: Under your limit, so it is ordered. Your address goes over at checkout. Your assistant: They are also asking about the new kitchen machine. Shop agent: For that, a local advisor shows it at home first. It costs nothing and commits to nothing. Your assistant: Putting it to them. Nothing is booked without their tap.
The rules do not live in the prompt. Prices come from the catalogue, in code, never from the model. The shopper’s spending limit is enforced in code, and anything above it waits for a tap on the phone, because an approval is an event, not a sentence. The address stays private until checkout. The shop’s agent may propose a demonstration twice at most. When a rule holds, the screen says so.
Two lessons stuck. Each agent sees only what its own side would see, built in code rather than two prompts sharing one transcript. And an agent copies the units it is shown: after the catalogue moved to euros, prices kept appearing in pounds until the examples changed.
What it does not prove matters as much. It shows that this is buildable now and that the rules can live in the system itself. It does not show that customers want to buy this way, or that their agents will choose to show you at all. I treat it as a specification of what a shop has to be able to do, not as evidence that the market has moved.
- Status
- A prototype for the stage.
- Built with
- Two Claude agents, with the rules and prices in plain code.
What carries over
Four rules hold across all of them.
- Give it a goal, not a script
- Spot’s best idea was its own. Describe the problem and the end state, and leave room for a better route than yours.
- Measure rather than trust
- Checks in plain code catch what a model will happily miss. The model judges; code verifies.
- Keep people on the decisions
- Agents flag, propose, and draft. People approve, spend, and delete.
- Build the correction in
- Every mistake on this page became a rule. The value is in how fast that happens, not in never failing.
This is also what I bring to Advisory: helping leadership teams move agents from the pilot into the work, with the guardrails that make them worth trusting.