The short version: AI projects rarely fail because the model isn’t smart enough. They fail because the work was never written down in an executable form. If a competent freelancer couldn’t pick up your process from your documentation alone, neither can an AI. Document-first work design is the prerequisite everyone skips.
Key takeaways
- Most “AI failures” are actually specification failures: the process only exists in someone’s head.
- The litmus test: could a capable outsider execute this task from your docs alone? If not, an AI can’t either.
- Context-setting is the hidden tax. If you re-explain your business every session, you haven’t built a system — you’ve built a chat habit.
- Fix the order: document → structure → automate → then add AI. Teams that invert this pay for the inversion in rework.
- The payoff compounds: documentation written for AI execution turns out to be excellent documentation for humans too.
Why do AI projects actually fail?
Not for the reasons in the post-mortems. When I audit stalled AI initiatives at SMEs, the pattern is almost always the same: the team pointed a language model at a process that was never defined in the first place.
The invoice workflow lives in Sandra’s muscle memory. The client onboarding checklist is “just how Mark does it.” The pricing logic is a spreadsheet with three generations of undocumented exceptions. Then someone asks an AI to “automate this,” and the AI does what any new hire would do with zero documentation: it guesses. Confidently. Wrong.
The model gets blamed. The real defect is upstream: there was nothing to execute. An LLM is an execution engine for described work. Undescribed work is not automatable — not by AI, not by software, not by the next employee.
There’s a second constraint people forget: AI can only output text. It generates code, emails, documentation, analyses — it does not manipulate the world or navigate arbitrary software by itself. So if you want AI to complete a task, that task must culminate in producing documents. The single most useful planning question I know: “What documents would exist if this work were complete?” Answer that, and you have both your AI deliverables and your definition of done.
What does “document-first” mean in practice?
It means the definition of done for any recurring process is a document that a capable outsider could execute without asking you anything. Three properties matter:
| Property | Bad (tribal) | Good (executable) |
|---|---|---|
| Trigger | ”When it feels needed" | "When an invoice email arrives in facturen@” |
| Steps | ”Process it as usual” | Numbered steps with the exact system, field, and decision rule for each |
| Edge cases | Live in someone’s head | Written down, with an explicit “escalate to human” rule |
Notice this is exactly the standard you’d hold for delegating to a freelancer. That’s not a coincidence. AI-ready and delegation-ready are the same property. The vocabulary of “prompt engineering” obscures this: you’re not engineering prompts, you’re finally writing the operations manual you owed yourself years ago.
Why is context-setting the hidden tax?
Because it’s paid per-session and never amortized. The typical AI workflow at a company without document-first discipline looks like this: open a chat, spend fifteen minutes explaining the business, the client, the constraints, the format you want — get a decent output — close the tab — lose everything — repeat tomorrow.
The alternative is a context system: a structured, versioned knowledge base (I use an Obsidian vault; a well-organized folder of markdown works too) where the business context, project state, and process definitions live as documents. Every AI session starts from that corpus instead of from zero. The AI reads the same docs a new team member would.
This is also where the compounding kicks in. Each documented process makes the next automation cheaper, because the context already exists. Companies that skip this rebuild context by hand, in chat, forever.
A starter architecture that has served me for years:
Knowledge-Base/
├── Context/
│ ├── Business-Model.md
│ ├── Customer-Profiles.md
│ └── Operational-Constraints.md
├── Templates/
│ ├── Project-Brief-Template.md
│ ├── Analysis-Report-Template.md
│ └── Communication-Templates/
└── Active-Projects/
├── Project-A/
└── Project-B/The breakthrough moment for me was opening my Obsidian vault inside an AI-enabled editor. Suddenly the AI had access to years of accumulated context about my business, my clients, and my methods — and I stopped repeating myself.
What order should you do this in?
- Document the process until an outsider could run it. (This step finds the contradictions — that’s a feature, not friction.)
- Structure the inputs and outputs: consistent file locations, naming, formats. Machines and models both love boring consistency.
- Automate the deterministic parts with plain software or workflow tooling (n8n, cron, a small script). No AI needed for “move the attachment to the right folder.”
- Add AI only where judgment is required — extraction, drafting, classification, mapping — and keep a human verification step in the loop for anything that touches money or customers.
Most teams run this backwards: they start at step 4 because that’s where the demo-magic is, then wonder why nothing survives contact with real operations. The boring truth is that steps 1–3 are 80% of the value, and they make step 4 nearly trivial.
I call this approach lazy engineering: making AI do the work by designing the work properly. The laziness is the point — every hour spent on documentation is repaid by every future executor of that process, silicon or otherwise.
Where do I start on Monday morning?
Pick one recurring process — the most annoying one — and run this checklist:
Prerequisites
- List every deliverable the process should produce (“what documents would exist if this were complete?”)
- Set up a structured knowledge base (Obsidian, Notion, or a disciplined folder of markdown)
- Choose an AI tool that can access your files, not just a chat window
Execution
- Write the context documents an outsider would need
- Create templates for the recurring deliverable types
- Run one pilot through the document-first approach and refine
Validation — you’re done when the AI produces the deliverables with minimal prompting, the output needs only light editing, and the process feels repeatable without you in the loop.
Don’t try to automate everything at once. Build the document-first muscle on one process, then expand.
FAQ
Isn’t documenting everything a huge upfront cost? Document one process — the most annoying recurring one — and automate that. The ROI on the first workflow funds the discipline for the rest. This is an iterative practice, not a documentation project.
We have documentation. Why do our AI projects still fail? Most corporate documentation describes what a process is for, not how to execute it. Run the outsider test: hand the doc to someone unfamiliar and see where they get stuck. Those gaps are exactly where your AI fails.
Which tools do I need? Fewer than you think. Markdown files in a structured vault, a workflow engine for the deterministic glue (self-hosted n8n is my default), and an LLM with access to your documents. The tooling is commodity; the work design is the differentiator.
Where does a consultant fit in? The useful engagement isn’t “build me an AI thing” — it’s a short discovery scan that identifies which processes are AI-ready, which need documentation first, and what the sequence should be. Then knowledge transfer, so your team owns the system instead of renting mine.
Joris Schelfhout is an independent software & AI consultant in Amsterdam. If you want a second pair of eyes on whether your operation is AI-ready, get in touch or book a call.