arbeiten-mit-ki ki-konzepte workflows agenten

AI Workflows by Keyword: How We Make Recurring Routines Enforceable

Martin Rau · 7. Juni 2026 · 9 Min. Lesezeit

When you work with AI every day, you quickly notice that certain routines repeat constantly. A task is done, so it needs to be documented. Code is supposed to go live, so the tests have to run first. A database schema changes, so it needs a controlled migration. For a long time I kept these routines as little instruction files scattered across the project. The problem with that: each file had to be maintained on its own, and there was no guarantee the AI would actually follow every step.

These days it works differently. We’ve built the most important of these routines as central AI workflows by keyword. You type a keyword — DEPLOYMENT, RECAP, DB MIGRATION — and that triggers a fixed, stored routine. This post explains how it works, why some of these routines consist of many small steps and others of a single one, and above all: why every single step has to be “committed.” Because that’s the core that holds it all together.

What happens behind the keyword

The mechanics are actually simple. Behind each keyword sits an entry in a central database. When you type the keyword, a small loop runs in the background: the keyword is first resolved to a workflow ID, then the AI fetches the next step, executes it, submits the result — and only then gets the step after that. It keeps going like this until the workflow reports itself as complete.

The decisive difference from before is the central storage. Instead of ten scattered instruction files, there’s now a single source. Every AI session pulls exactly the same state — no drift, no maintaining things in several places. Whoever improves the routine improves it for everyone at once.

The core mechanism: every step gets committed

Now for the actual heart of it. Each workflow consists of numbered steps. For every step the AI gets an instruction plus a fixed answer format. And it must submit its result — we call that “committing” — in exactly that format, before it even gets to see the next step.

That sounds like a minor detail, but it’s the whole trick. Four reasons why:

It forces every step to actually happen. The AI can’t skip a step or tick it off superficially, because without a valid commit there simply is no next step. It can’t move on by cheating.
It forces verifiable results. Because every step has to meet a defined format, you get structured, checkable answers instead of free-text prose where you never quite know whether the work got done.
It carries context cleanly forward. The submitted result stays in the session, and later steps draw on it. So knowledge moves from step to step in a controlled way.
It’s the gate for conditional steps. In a database migration, for example, the execution step runs only if the preceding approval step actually submitted a real approval. Otherwise the execution is automatically skipped. A safety rule is thereby enforced mechanically, instead of merely sitting in the text as a polite request.

The difference in one sentence

A hint in the prompt is a request. A per-step commit requirement is a guarantee. Exactly this shift from “please do this” to “you can’t move on otherwise” makes all the difference.

Why some routines have many steps — and others just one

Not every workflow is built the same way, and there’s a reason for that.

The multi-step routines are meant for mandatory and safety sequences where every single step has to demonstrably happen. The fine granularity is intentional: a nine-step documentation workflow guarantees that none of the nine aspects gets forgotten. Examples are the mandatory documentation after a task (9 steps), the database migration (8 steps), and the deployment (8 steps).

The single-step routines, by contrast, are meant for one-off assessments that are done in one go — one instruction, one result block, no constant back-and-forth with tools. These include Summary, Recap, Triage, and the RAG update, each with a single step.

The individual workflows at a glance

KIDOKU (9 steps) and Mandatory (9 steps): Both are documentation sequences after a work session or after a manual task respectively. They walk cleanly through everything from implementation to the architecture check and verification, all the way to the work log and the closing assessment. The documentation steps draw on the knowledge base’s search and write tools, not directly on the database.
DB Migration (8 steps): The safety workflow for changes to the live schema. Three non-negotiable lines of defense are enforced mechanically: work may only happen on a dedicated migration branch, an explicit approval with concrete reference to the actual command is required, and interactive prompts are aborted immediately so nothing runs through unintentionally.

With the keyword for database migrations we haven’t had any problems anymore. That used to get messy fairly often, but ever since we do it this way, it runs flawlessly.

Deployment (8 steps): A preflight chain of type checking, lint checking, tests, and build, plus an automatic repair loop and finally the push.

I personally find deployment very pleasant, because it’s so fire-and-forget. We built in a Git hook that runs certain tests — all type checks, all real tests have to be green, otherwise no push goes up. A worker checks: am I on the right branch, do I have everything, do all tests run? And if not, it fixes the tests right away, attempts the deployment with a push, and should there be another error, it fixes that too. If you’re sure there are no bugs and no merge errors in there, it really is easy — otherwise you’re back on it yourself and have to check it step by step and go through it with the AI. So you just send it off, and at some point it goes live.

DB Backup (4 steps): A full backup in a single run — and always all three artifacts together: a dump of the user database, a dump of the central database, and all the server functions actually deployed. Never just one database; that’s deliberately non-negotiable.
Summary (1 step): The decision about handing the session over. The AI assesses the situation — how full is the context, what’s still open — and gives a recommendation on whether to continue, condense, or hand off to a new session.

I mostly use Summary when you start switching topics, or notice the AI’s performance is dropping and you’d rather move into a second session — then you have a clean close. Ever since Opus is in use with a million context, that’s become relatively rare; the sessions sometimes run four or five hundred thousand tokens long. It used to get used more.

Recap (1 step): A reflection of how the AI understood the last input, before it gets going. So it first states how it understood the task, and only then starts.

We use Recap very often. Simply so I know: did the AI really understand what the goal actually is? I always find that very useful.

Triage (1 step): A self-decision gate. Instead of asking back on every little thing, the AI decides reversible questions itself based on the project guardrails. Only genuine irreversibles — deleting data, migration, security, breaking change — escalate back to the human. That kills question inflation.
RAG Update (1 step): Folds an insight from the session into the existing knowledge docs. If there’s a clear single location, it happens directly; if there are several, it asks back — no blind overwriting.
Content Creation (5 steps): Condenses something built during the session into a content brief and files it as a task in a queue. This very article, by the way, came about exactly that way.

Content Creation is our newest keyword, and together with the RAG update it already uses a whole pipeline. When we’ve built something cool, you just type “Content Creation” after it — then the tool makes suggestions about where in the system it should be posted: is this a LinkedIn post, more of a blog post, or a combination, where a blog post is created first and then the whole flow for LinkedIn, Instagram and so on is triggered automatically?

A bit of the tech behind it

What makes the whole thing sustainable is the central storage in a single database instead of scattered local instructions. A new workflow is therefore essentially just a data entry — no dedicated program code per routine is needed, a single generic loader reads them all. The conditional steps are evaluated against the already-submitted results of earlier steps, and the instructions deliberately favor the knowledge base’s tools over direct database access. It only goes straight to the database where that’s inherently necessary — for migration and backup.

The bottom line is that it makes AI-assisted routines reproducible, verifiable, and consistent across all sessions. And that’s exactly what I want from a system like this.

Conclusion

The real win doesn’t lie in the convenience of a typed keyword — it lies in the reliability. As long as a routine only sits in the prompt as a request, its execution depends on the AI’s daily form. The moment every step has to be committed individually, the request turns into an enforceable guarantee. That’s exactly what made entire classes of error disappear for us, above all the formerly chaotic database migrations.

The outlook is clear: more workflows are in the works, and above all we want to chain the individual content pipelines together — blog, then LinkedIn, then Instagram — into one continuous flow. Once that’s in place, one keyword is enough, and an insight automatically turns into a whole bundle of finished posts.

Keep reading

Why fixed rules alone don’t tame the AI: AI Models Do Whatever They Want
The emergency brake for the orchestration system: Critical-System-Gate
When the AI says “yes” too quickly: Cascading Failures

Entdecke mehr

Blog

Themenuebersicht

Arbeiten mit KI Workflows KI-Konzepte Agenten