From idea to running operation.

How an initiative becomes a system that holds: the decisions it hangs on, and the order in which they are taken. Executive briefings for managing directors and division heads, in a small group. The basis is not a slide deck but a studio in which AI agents carry the business functions and the human keeps the approvals — with products running in production.

For decision-makers, not for users.

This format is aimed at the level that decides on budget, responsibility and liability — not at teams who are meant to operate a tool. No prior knowledge is needed; honesty about where you actually stand is. The questions answered here are the ones nobody likes to ask in front of a full room.

4 questions that actually decide it.

Approval architecture

Who approves what, and what stops a change that has not been approved? An approval process you can go around is not one. What is shown here is how approvals become a build condition rather than a declaration of intent — on a system in which anything unapproved does not exist in the production state in the first place.

Model selection

Not one model for everything, but the right one for each task — with a primary and a fallback model, documented reasons for rejection and measurable criteria. Anyone who does not test models has not selected, they have guessed.

Running costs

What a call costs, how costs can be attributed per task, and why a conversation that runs longer costs more rather than less. The aim is to know the running costs before the first invoice arrives.

Classification by personal reference rather than by server location. Which data genuinely needs protection, where the choice of provider matters, and where the server question answers itself.

Half a day, a full day — or cut to fit the house.

The half day is an overview: the 4 questions, the stack as a living example, room for your own cases. The full day goes deeper and works on a concrete initiative from inside the house — with the result that by the evening there is a basis for a decision rather than a collection of ideas.

Both are off-the-shelf formats, and off-the-shelf does not fit everywhere. Where the need lies elsewhere, the briefing is cut to fit the house: to the areas actually affected, to the state of things actually there, and to the obstacles actually in the way — not the ones that turn up in conference talks.

On site or remote. In a small group, so that what genuinely interests people can be asked. Preparation follows a short preliminary conversation, so the examples come from your own house and not from a textbook.

Both sides, from first-hand experience.

No observer is advising here. Anyone who works with these tools themselves knows the places where they jam: the answer that sounds plausible and is wrong, the automation that nobody understands 3 weeks later, the effort that lies not in the building but in the checking. None of these pitfalls appear in a vendor presentation.

And the other side with it: more than 2 decades inside companies, with responsibility in marketing, communications, business development and management. Anyone who has worked in corporations knows that initiatives rarely fail on the technology, but on responsibilities, budget cycles, the works council, procurement, and on the fact that nobody wants to carry the blame for a mistake a machine made.

And today the studio itself covers every business function — legal, finance, sales, marketing, support, operations, content. On a small scale, but completely. That is why the conversation with IT is a different one from the conversation with sales, and both are possible.

What is claimed in the briefing can be checked against a running system: AI stacks, operational agents, a language-learning app in production with 10 language versions and over 2,900 automated tests. Read the track record →

Enquiries.

Conditions on request — they depend on format, location and preparation. Write a short note about what it is about and who should take part; a preliminary conversation clears up the rest.