Three layers and a gate

On LinkedIn I came across a post by GenAI Works, with an infographic that circulates in many variants. The reasoning goes like this: a language model on its own can't do three things. It can't reach your tools and systems, it doesn't know your documents, and it can only answer, not act. For each of those gaps there is a separate technique: MCP, RAG and skills. According to the post, many people mix the three up as if you had to choose, while each solves a different part of the same problem. Only by combining them do you get an assistant that fetches, decides and acts.

I use all three. Still, my system looks different from the diagram. Below, first the diagram as intended, for anyone who doesn't know the terms. Then my assistant, and then the three layers side by side.

The diagram in three layers

Connection. A language model can't reach your calendar, your database or your tools on its own. You used to build a separate piece of code for every link. MCP is a standard that replaces that: a fixed agreement on how a model and a service talk to each other. Any service that follows that agreement can be used by the model straight away, without a custom link. The model asks, the service answers, the model carries on.

Knowledge. A model doesn't know your documents, and what it does know predates its training date. RAG solves that: you cut your documents into chunks, store each chunk as a sequence of numbers in a vector database, and for every question the chunks closest to the question are pulled in. The answer then comes from your own material. The post promises right away: no hallucinations.

Execution. From answering to doing. A skill lets the model run code, read and write files, call a service or work through a series of steps. For each question the model chooses: answer, or use a skill.

The diagram closes with a warning: most people know the difference between the tools, few know how to keep them in hand. I'll come back to that.

My assistant

Kai is the assistant I've been building for over a year. It runs on Claude, in two places: in the chat, and on my laptop as Claude Code, where it can reach files and scripts. It manages my task list in Notion, publishes my website and searches an archive of two years of AI conversations. How it came about is in an earlier article.

Hold the diagram up against Kai and one layer fits exactly, two I deliberately do differently, and a fourth is missing. The overview first, then layer by layer.

• Connection. The diagram: one standard connection for all your tools. With Kai: MCP for the conversation, own webhooks for bulk work.
• Knowledge. The diagram: chunks in a vector database. With Kai: a wiki of text files, search by words, and a quoting rule.
• Execution. The diagram: skills that run code. With Kai: skills as a fixed way of working.
• Control. The diagram: a warning, not a layer. With Kai: code that says no.

Connection: correct, with a detour

The diagram says: one standard connection for everything. Kai uses MCP all day: with Notion, with my image generator, with my automation server. For conversation it works well. "What's the status of that one task" is one call and one answer.

Bulk work is a different story. In April I wrote it down for myself, while figuring out why my assistant was so slow on overviews: the Notion connection returns only titles on a search, no content. A status overview of ten tasks therefore costs eleven calls. At hundreds of tasks, a session runs out of room before it's done.

The solution turned out to be a detour. For everything that's bulk (overviews, weekly counts, updates in series) a flow on my server reads the database in one go and hands back the answer ready-made. MCP for the conversation, webhooks for the work. Two entrances, then, each for what it does well.

Knowledge: no vector database

The diagram says: chunks in a vector database. This is where I diverge the most. My knowledge archive is a folder of text files. Two years of conversation history at the bottom, and above it a wiki the AI compiles itself from those conversations: one page per topic with what's been learned about it, with references back to the conversations it came from. Search is by words, with a short route map at the top that says where things are. That's how my second brain works.

I did consider the vector layer. In July I evaluated a ready-made approach that adds exactly that, with a tidy benchmark attached. The verdict was to reject it, for one reason: I had no measured problem. Across a hundred-plus well-indexed pages, the gap only existed for questions phrased in different words than the text itself, and the route map caught those. The agreement since then: only once I have a series of cases where search misses something that is there do I have a problem that justifies a vector database. That series doesn't exist yet.

And that promise from the post, "no hallucinations"? It's the line I believe least. Retrieval brings the right passage into view. It doesn't stop a model from padding a thin passage with something plausible, and thin passages are exactly what a knowledge archive is full of. For me that's a rule, not a technique: first quote the sentence literally, with its location, and only then answer. No quote, then the answer is "that's not in here". How that rule came about is in the five rules that keep my AI in check.

Execution: skills as a fixed way of working

The diagram says: skills let the agent run code, and in the infographic a skill is a text file with instructions and actions. That last part matches mine exactly. A skill is a working method in a text file: how a task gets created, how a post gets judged, how I decide whether to use a new tool. Twenty of them by now.

The difference is in what they're for. For me, a skill makes sure a job goes the same way every time, even when I'm in a hurry. Running code is secondary.

The fourth layer: control

The diagram ends with a warning: few people know how to keep the tools in hand. That's where it stops. For me, that's where most of the time goes.

Here, control consists of code that says no. A change without a list of files gets refused, ever since a day in August when work from different sessions got tangled up. A script is only recorded once its test has demonstrably run green. And anything that becomes reachable from outside first has to fail cleanly, without a key or with odd input.

The direction is always the same: fewer rules I have to remember, more rules the system enforces.

So yes: connection, knowledge, execution. Combine them. But without control you build an assistant that can do a lot, and whose actions you can't account for afterwards.

Assess yourself on four layers, based on how we have worked together so far and what you know about my work. For each layer give three things: what is there now, what is missing, and the smallest step that would make a difference.

1. Connection: which systems can you act in yourself right now, and where do I still copy and paste?
2. Knowledge: where do your answers about my work come from, and when have you filled in something you could not look up?
3. Execution: which recurring tasks do you carry out from start to finish, and where do you stop halfway because a step is missing?
4. Control: which agreements between us exist only in my head, and which of those could you enforce yourself?

End with the one layer I should start with, and why.