AI-ready means: everything has an API

Our website now says it more prominently than ever: we make companies AI-ready. This post explains what that means at its core — and it is simpler and more uncomfortable than most AI strategy papers put it.

The thesis

An AI agent is exactly as useful as the surfaces it can operate. Software without an API is a locked room to an agent.

“Becoming AI-ready” therefore does not primarily mean “introducing an AI tool”. It means: choosing and building every layer of the company so it can be driven via API or command line. Only then can an agent actually take over processes — instead of merely drafting texts that a human then types into forms.

The practical test: one week of my own migration

This series documents the rebuild of my own digital life. What did the agent actually get done in the last week — without me clicking anything?

Repaired a deploy pipeline: detected missing CI variables, generated a deploy key, authorized it on the server, set the variables via API, retried the job, verified the health check.
Created merge requests, merged them once the pipeline was green, monitored the deployments.
Extended the website with partner logos it fetched from the partners’ public sites and recolored to fit.
Wired up an analytics system: registered the site in the database, embedded the measurement script, extended the privacy policy.
Created a daily build schedule so that prepared blog posts (like this one) appear automatically on their date.

None of that is magic. All of it was possible only because every system involved — git hosting, CI, server, analytics, DNS — has an API or a command line.

The counter-test: where services failed me

Just as instructive is the list of services that got cut:

My old password manager (Dashlane): no Linux app, no usable CLI. Invisible to an agent → replaced by Vaultwarden with a complete CLI.
Exchange for the mailbox: automation only through proprietary detours. The exit is underway — not because mail doesn’t work there, but because it isn’t operable there.
Even the analytics choice wasn’t decided by feature count but by: can the agent read the numbers via API and tell me on Monday morning which post brought customers?

The evaluation checklist

This has become a rule that we now check before features and before price. Whoever evaluates software — as an individual or as an SME — asks these questions in this order:

Is there a documented API or CLI for everything the UI can do? Not “has an API” — many products have a fig-leaf API covering 10% of the features. API-first means: the UI itself uses the API.
Can I export my data completely and machine-readable? Without that, every migration is a hostage situation.
Can I run the system myself, or at least host it in Switzerland/the EU?
Is the configuration text instead of click-paths? What is text, an agent can read, change, version and justify.
Only now: features, price, looks.

Points 1–4 decide whether software becomes a building block or a manual-labour reservation. In five years, the difference between companies that work with AI and companies that talk about AI will run exactly along this line.

And your own company?

For companies, becoming AI-ready then means concretely: document the processes, choose or retrofit systems with APIs, move knowledge out of heads into structured, machine-readable form — and only then let agents loose on it. In exactly that order. That is the core of what we offer, and the next post shows the biggest piece of evidence we have for it: a complete platform, built end-to-end by agents.

Questions, objections, evaluation stories of your own? Write me — I answer personally.