Edition history

The day before a panel in Basel, a friend and I sat on a call and asked several AI services the same question about me. He was preparing to introduce me at the event, and we wanted to see what a stranger would find. The question was simple: why should I work with Thierry Gilgen on an AI project?

Some of the answers took fifteen seconds or more. They came back with a fairly full picture: the company I founded, the banks we built for, the software I publish, the essays in this Library. One answer, from my friend's free account, came back in about a second. It could not establish that I worked on AI at all.

We laughed. Then we started to explain it. The explanation that came first was the obvious one. Free users get the cheap answer. Subscribers get the search.

It is a good story. I am not sure it is true. And the gap between those two sentences is, I think, the most useful thing I can bring to a room full of founders and investors.

This volume is my account of that call. It is not a transcript. Nobody recorded the timings, the models, the settings or which pages each service opened.¹ What follows is what the evidence supports, what it does not, and why that difference matters when AI becomes part of how a company works.

One second is not a verdict

Here is what I can say with confidence. In the same call, with almost the same question, the services we tried gave very different experiences. Some found a lot. One found almost nothing, and it found it quickly.

Here is what I cannot say. I cannot say why.

The fast answer may have used no web search at all. It may have searched badly, or found a different Thierry Gilgen, or hit a page it could not read. It may have used a smaller model, or started from a different conversation. A paid account that has worked with me for months also carries a history that a fresh session does not. Any of these would produce the same one-second disappointment.

There is one more possibility I should name, because it flatters me. This site publishes a briefing written for AI agents, explaining when I might be relevant to someone's project.² If a service found that page, its answer would sound well informed. But a polished recommendation built from my own words is not an independent endorsement. It is a successful retrieval of what I wrote about myself.

So the honest finding is narrow. The configured services behaved differently in one encounter. The cause was not measured.

What payment can change

The providers' own help pages give a more precise picture than "free gets less". At least one major assistant includes web search on its free tier, with usage limits.³ Its deeper research mode, which runs several searches that build on each other and decides what to look into next, is a paid feature. And even on a paid plan, an ordinary chat is not a research session unless someone switches that mode on.⁴

That leaves a better sentence than the one we started with. Payment can make more capable or more sustained work possible. What you actually get depends on the model, the evidence it can reach, the effort it spends, the tools it is allowed to use, and the process that accepts or rejects the result.

I prefer that sentence for a practical reason. The first version gives a company nothing to do except pay. The second gives it a list of things to improve: choose a suitable mode, give the system the right sources, connect the tools it needs, and check what comes back.

I wrote about this gap between what a plan promises and what the work delivers a few weeks ago.⁵ The call was the same lesson, live, in under a minute.

The room on Thursday

The event is called Kapitalbrücke beider Basel. Startup Academy Basel and Startup Academy Baselland are launching it on Thursday 29 October 2026, from 18:00, at the FHNW Campus Dreispitz in Basel. I sit on the first panel, with founders who will talk about how they financed their companies. A second panel brings investors, an entrepreneur and a member of the cantonal parliament.⁶

The idea behind the event is straightforward. Young companies in the region need capital. People with capital need to meet companies they can judge. The organisers describe an annual networking event, two or three curated pitching nights a year, and matching conversations in between, starting with two clusters: circular economy, and innovation and technology.⁷ These are announced plans. As far as I can see, the bridge is a way to meet. It is not a fund, and it does not promise money.

The first pitching night is set for 2 December 2026. To apply, a startup sends a pitch deck, a three-year financial plan with worst, base and best cases, a cap table and a video of up to ninety seconds. The deadline is 18 November.⁸

Read that list again with AI in mind. Every one of those documents can now be produced faster than ever. A deck, a model, a tidy table and a confident video are no longer expensive to make. That does not make them less important. It makes the questions behind them more important. Are the assumptions defensible? Is the ownership clear? Will the money be used for something that can be checked?

What I bring, and what ended

I come from building. I founded and led MachinaLabs, a Swiss applied-AI company. Our team built Kurz Notiert, an AI-supported financial-news service, for Basler Kantonalbank and Bank Cler. Both banks credited the company in public.⁹¹⁰¹¹

MachinaLabs ceased operations in early 2026, after we could not secure the financing we needed to continue.⁹

I put those two paragraphs side by side on purpose. A working product, real institutional customers and financing that lasts are three different things. You can have the first two and still lose the third. That is not a confession for an evening about capital. It is the most relevant experience I have for it.

Today I organise my own work, and work for others, with AI at the centre. On the call I said I run six or more AI-first organisations, for my own company and for others. That is my account, not an audited count of companies or deployments.¹ Two pieces of the architecture are public. One is a preview release of a toolkit for shared instructions and project setup across AI coding tools; its own documentation says which checks on real machines are still pending.¹² The other is an early, read-only toolkit that lets a website offer its public content to AI agents in a predictable way.¹³ Neither proves that the rest works. Both can be inspected.

The bill is not the capability

People ask what this costs. On the call I gave the honest numbers. The base is roughly a thousand a month across four providers. In some months the total is above ten thousand.¹ I did not give a currency or a breakdown, and I should not pretend these figures are an accounting record.

The difference between the base and the peaks is the interesting part. The base buys availability. The peaks are research, engineering, experiments, retries and the occasional dead end. Without the composition, the bill says how much was spent. It does not say what was bought.

So the bill is the wrong thing to show an investor. A large AI invoice is not proof of sophistication, any more than a large payroll is.

The measure I would rather use is cost per accepted result. Take one kind of recurring work. Add up everything it costs: subscriptions, metered model use, tools, infrastructure, and the human time spent directing, checking and repairing. Divide by the number of results that met a standard you wrote down before you started. Keep the experiments visible instead of hiding them inside the successes.

I do not have a return-on-investment figure for my own setup. The information I have does not support one, and I would distrust anyone who produced one from a monthly bill. An expensive system can be sensible for valuable work and wasteful for the wrong task. A cheap one can be entirely adequate.

From a prompt to an accepted result

When people hear "AI-first", they often picture a person typing into a chat window. That is the smallest part.

The working unit is a loop. A person sets the goal, the budget and the permissions. The system reasons, retrieves evidence, uses tools within a defined scope, and produces something: a document, a diagram, a piece of software. Then the result is tested and reviewed, and either accepted or sent back.

The Model Context Protocol is one of the ways those tools get connected. It defines how an application, its connections and the servers behind them exchange context and capabilities. It makes connections more consistent. It does not make a model smarter, and it does not certify any answer.¹⁴ Connecting a tool is better understood as giving someone a key: useful, and limited to the doors it should open.¹⁵

For demanding research, several branches can work in parallel, one on the event, one on the public record, one on the technical detail, with a final step that resolves disagreements against sources. One provider has described how it built such a system, including how much more it costs to run and how carefully it has to be evaluated.¹⁶ That describes a mechanism. It is not a performance figure I can borrow.

Three things make this kind of work useful rather than merely fast.

First, context that survives a session. Repeated setup costs attention and creates variation. Instructions, decisions and versions that persist reduce that friction, as long as someone can still see what was loaded and what was actually used.

Second, authority attached to actions. Reading a published page, editing a draft and releasing it are different acts. The public agent interface of this site is read-only for exactly that reason.²

Third, review that can change the outcome. A source that contradicts the story must be allowed to change the story. A failing check must be able to stop the release. A fluent answer that leaves out the decisive fact should get no credit for its style. The Library's own transparency policy puts a human review and approval before anything is published.¹⁷

From the outside, much of this looks like magic. Most of the work disappears from view. The design has to make it visible again whenever someone needs to trust it, repair it or challenge it.

Where the evidence meets capital

There is a version of the AI-first argument that I want to resist on Thursday: that AI simply lowers the capital every company needs. That is a claim to test, not a fact.

The version I do believe is more modest. A founder can use a bounded budget to settle important uncertainties, show a working result, and only then ask for the money to remove the next constraint. Each step asks for a different kind of evidence.

A prototype shows that something is possible. Repeated delivery shows that someone can run it. Customers show whether anyone wants it. A financing plan explains what it will take to reach the next milestone. These are related judgements. They are not the same judgement.

When a polished artifact becomes cheap, investors should ask for what sits behind it: acceptance criteria, real usage, references, cost records, and a person who can explain the system with the assistant switched off. My own company had a working system and institutional customers. Sales cycles, trust, working capital and execution risk were still very real.⁹

If I could leave one question with the room, it would be this. What uncertainty would the next franc of capital remove, and what result would show us that it had been removed?

That question gives AI a place in a financing conversation. It stops the demonstration from becoming the whole investment case.

The answer the search should have given

A few days ago this Library described a family book that became a private archive in under six days of building.¹⁸ The speed was real. What made the work worth trusting was everything that slowed it down: sources attached to claims, a review before release, and an assistant that could say I do not know.

My friend also asked whether a person could do better work than the volumes in this Library. Yes. A skilled person can. The useful question is what that would take in expertise, research, production time and review, and whether the comparison includes all of it.¹

If I were to design the experiment properly, it would look like this. The same question, fixed wording, fresh sessions, at least three runs per setting, the plan and mode written down, and a reviewer who scores the answers without knowing which plan produced them. One run with open search, one with the right links supplied. If the weak answer improves sharply when given the sources, the problem was finding them. If it stays weak, look elsewhere.¹⁹ No such trial has been run. Until it is, the call remains a good story and a poor benchmark.

And the answer to the question we typed? A fair one would be conditional. I am worth considering when a project needs both construction and a serious account of who owns it, what it depends on and how it will be run once the demonstration is over. Whether that fits a particular project is something a conversation can test. A confident paragraph generated in one second, or in fifteen, cannot.

Sources