There is a mistake almost everyone makes when they first start building automations with AI.
They put everything in the prompt.
The persona. The formatting rules. The decision logic. The thresholds. The delivery instructions. The edge case handling. Everything the AI needs to do the job, in one long block of text, because the prompt is where you tell the AI what to do — so naturally, you tell it everything there.
This works fine for one automation. It becomes a problem the moment you build a second one.
You copy the first prompt, tweak it, and now you have two automations with 60% overlapping content. Then a third. Now you have three prompts, each three to five thousand characters long, each containing slightly different versions of the same logic. When you need to update the formatting rules, you update one. You forget the other two. They drift. The automations start behaving differently from each other and nobody notices for a week.
This is not an edge case. It is the predictable outcome of treating the prompt as the place where intelligence lives.
It isn't. The prompt is a signal. The intelligence lives somewhere else.
The remote control principle
Think of it like a television remote.
The remote does not contain the electronics that produce the picture. It contains a signal — a specific instruction that points to the right device and tells it what to do. All the complexity is inside the television. The remote just needs to be precise enough to reach it.
Your automation prompt is the remote. The skill is the television.
The prompt's job is to load the right skill, call the right function, point to the right config file, and specify where to deliver the result. Four lines. That's it. Everything else — the logic, the rules, the persona, the formatting, the decision criteria — lives in the skill, where it is testable, maintainable, and shared across every automation that needs it.
When you need to update the formatting rules, you update the skill once. Every automation that loads that skill gets the update automatically. No drift. No forgotten copies. One source of truth.
What four lines actually looks like
e.g. Load the skill, call its entry point, point to the config, and specify the destination. The scanning logic, deduplication rules, formatting templates, and staleness criteria belong in the skill or config — not in the prompt.
The three places things should live
The skill holds everything that is logic: decision rules, formatting templates, persona instructions, problem criteria, and output structure. Fix it once, and it is fixed everywhere.
The config file holds everything that is a setting: thresholds, file paths, space names, delivery targets, and timing values. Settings can change without changing the logic.
The prompt holds the pointer: load this skill, call this function, config is here, deliver there. Nothing else.
The test for every line in an automation prompt is simple: does this belong in the prompt, or does it belong in the skill or config? If it is logic, it belongs in the skill. If it is a setting, it belongs in the config. If it is neither, it probably should not be there at all.
The presence question
When you are in a live conversation with AI, talking naturally and iterating in real time, structure is largely unnecessary. You are there to correct it.
When an automation runs without you, the same forgiving conversational prompt fails because nobody is there to close the room for interpretation. The rule is simple: precision scales with absence.
When you will be present to correct it, talk naturally. When you will not be present, be precise. A conversational prompt in an automation produces inconsistent, drifting output. A structured prompt in a live conversation is unnecessarily rigid.
What precision means in practice
A live request can be loose: ask the AI to look at a list and flag terms that seem outdated. An automation needs the specific file, measurable criteria, output structure, destination, and edge-case behaviour.
None of those decisions can be left to interpretation when you are not there to make them in real time. If you did not give the automation enough, it will guess. If it guesses wrong, it runs wrong until someone notices.
Building it right from the start
First, figure out what it should do in a live conversation. Then move the logic into a skill. Extract changing settings into a config file. Write the four-line prompt. Finally, test it and put any fixes in the skill or config — not back into the prompt.
This order matters. Most people write the prompt first, which means they put everything in the prompt, which brings them back to the beginning of this article.
Why this matters beyond your own automations
A lean prompt is not just faster and more reliable. It is maintainable by someone who is not you, on a day when you are not there. That is the entire point of building something that runs without you.
The intelligence is not in the prompt. It never was. The prompt is the remote control — a signal that points to where the intelligence lives, precise enough to reach it, simple enough for anyone to read.
Build the television well. Keep the remote small.
This is part of the Parenting Your AI series, a practitioner's guide to building AI skills that are safe, effective, and worth trusting. Written from inside enterprise AI systems by someone who has spent years diagnosing what goes wrong when AI meets real work at scale.
Read the full series at Parenting Your AI