Tools like n8n, Make, Langflow, and Flowise usually give you a single input box called “System Prompt."
That single box ends up containing everything:
- identity
- instructions
- business logic
- edge cases
- response formatting
- conversation rules
This creates something that looks powerful but is actually fragile.
I recently encountered a problem while building a WhatsApp sales AI agent that had a massive impact on my learning and changed how I prompt AI agents and LLMs in general. If you stick with me through this article and haven't adopted this way of prompting agents, then I’m certain sooner rather than later you will if you work with LLMs extensively.
The workflow I was building was simple: The system handled inbound customer messages, collected order details, and saved them to a database for the sales team. All the while, making the conversation seem human-to-human.
The agent needed to collect six pieces of information:
- Colour
- Size
- Quantity
- City
- Location pin
- Name
Each conversation followed the same sequence. Ask for the next missing field, save it, and move forward.
The first problem appeared early. The agent would ask customers for information they had already provided. A customer would say, “I want medium," and two turns later, the agent would ask for their size again.
The fix seemed obvious: add an instruction (prompt).
instruction:
Never ask for a field that already has a value in the database.
I added it. The re-asking stopped.
Then a new bug: the agent would confirm a size — “great, I’ve noted medium for you”—and then ask for size again in the same message. Over-confirming.
Another instruction:
one confirmation maximum before moving to the next question.
Then the step sequencing broke. The agent would collect colour and jump straight to asking for a name, skipping size, quantity, and city entirely.
Another instruction. Then another. Then another.
If up to this point you haven't figured out the problem, hold on; I will spill it out to you soon.
I kept asking why the agent was misbehaving, knowing very well that the quality of my system prompt was top-notch. It contained every recommendation an expert or a prompting guru would advise. Yet the agent wasn't predictable, and the length of my system prompt was starting to scare me.
I had one question: will I keep adding to the prompt for every edge case I encounter? This isn't even the finish product or the worst-case scenario for the agent handling spontaneous human conversations. More unideal customers were going to come in. What then?
What I was experiencing has a name.
Prompt bloating (All-in-One Prompts)
Prompt bloat is the inclusion of unnecessary, redundant, or overly detailed information in an AI prompt. It often stems from the misconception that “more details always equal better results."
This happens when every bug is treated as a prompt problem. Instead of changing the architecture, we add instructions. Each rule solves one issue. But each rule also increases the complexity the model must manage. Eventually, the prompt becomes the largest component in the system. And that is where the real problem begins.
A language model has a limited cognitive budget every time it runs.
It must:
- Read the system prompt
- Compress those instructions internally
- Interpret the user message
- Apply the rules
- Generate the response
The longer and more complex the prompt becomes, the more effort the model spends parsing instructions instead of understanding the user.
At some point, the model spends more time managing rules than performing the actual task.
This is when strange things begin to happen. Agents start to repeat questions, contradict instructions, skip steps, confirm values twice, or mix up stored data. The system looks unpredictable. But the model is not malfunctioning.
I was asking the model to do two fundamentally different kinds of thinking at the same time.
The first: understanding a human: Reading a WhatsApp message from a customer, extracting what they wanted, navigating the small talk, and handling the moment when someone asked about pricing mid-flow. This is what language models are genuinely extraordinary at. It is what they were built for.
The second: computing deterministic logic: Deciding which question to ask next based on which database fields were empty. An if/else chain. Pure sequential lookup. The kind of thing a ten-line JavaScript function handles without breaking a sweat—and handles reliably, every single time, with no ambiguity, no mood, and no attention budget to manage.
Both of these responsibilities lived inside my system prompt. The model was simultaneously a language specialist and a logic engine, and every token it spent on the second job was a token it couldn’t spend on the first.
To demonstrate this in practice, let’s look at how the customer interaction is handled by this prompting style for the WhatsApp sales agent.
Scenario
Customer: "I’d like to order the red shirt please."
System State: The database has "Red" saved under Colour.
The next required field is Size.
------------------------------------------------------------------------------
1. The "All-in-One" Prompt (The Bloated Way)
In this version, the single "System Prompt" box in your no-code tool
contains every rule, edge case, and logic step the agent might ever need.
The Prompt:
"You are a WhatsApp sales assistant.
Your goal is to collect: Colour, Size, Quantity, City, Location pin, and Name.
Business Logic Rules:
1. Always check if a field is already in the database before asking.
2. If the user provides a field, confirm it briefly then move to the next.
3. Do not ask for more than one piece of information at a time.
4. The sequence must be: Colour -> Size -> Quantity -> City -> Location -> Name.
5. Never repeat a question once the data is saved.
6. If the user asks about price, answer them then return to the sequence.
[Plus dozens of other rules added to fix previous bugs...]"
The Resulting Risk: Because the model is juggling all these rules simultaneously, it often hits a “cognitive budget” limit. It might get confused, over-confirm the colour, or skip “Size” and jump straight to “City” because it is overwhelmed by the logic chain.
The Solution: Decoupling Logic from Language.
The fix is not another instruction. The fix is a separation of concerns. I stopped treating the system prompt as the place where everything lives. Instead, I started thinking about what the model should never be responsible for in the first place.
Once I realised I was forcing the model to be a logic engine and a language specialist simultaneously, the solution became clear: I had to strip the deterministic logic out of the “System Prompt” and move it into the workflow architecture itself.
I call this moving from the “All-in-One Prompt” to a Modular Instruction Set.
In a modular system, you don’t ask the LLM to remember which fields are missing or what the next step is. Instead, you use your no-code tool (like n8n or Make) to handle the “if/else” heavy lifting, passing only the necessary “Micro-Instructions” to the agent for that specific turn.
See this style in practice below:
Scenario
Customer: "I'd like to order the red shirt please."
System State: The database has "Red" saved under Colour.
The next required field is Size.
-----------------------------------------------------------------------------
The Modular Instruction Set (The Modern Way)
In this version, we decouple the logic (deciding what's missing) from
the language (talking to the user). The workflow does the heavy lifting
before the prompt is even sent to the LLM.
## Layer 1: The Contextual Core (Identity)
"You are a helpful sales assistant. Your tone is friendly, professional,
and concise."
## Layer 2: The Dynamic Instruction (Injected by the Workflow)
The workflow’s "State Manager" (a code node) sees that "Colour" is filled but
"Size" is empty. It injects this specific instruction for this turn only:
instruction:
"The customer has chosen Red. Acknowledge the colour choice
and then ask them what Size they would like."
The Resulting Benefit:
- Predictability: The model has zero chance of skipping to “City” because the prompt doesn’t even mention that City is a requirement yet.
- Precision: The model spends its entire “cognitive budget” on being human and conversational rather than parsing a manual of business rules.
- Reliability: By treating the model as a “language specialist” and the workflow as the “logic engine,” the agent becomes 100% reliable
The difference is clear: one style forces the AI to be a clumsy logic engine, while the other allows it to be a brilliant conversationalist.
The Shift in Prompting Philosophy: From “Smart Prompts” to “Modular Systems”
While the WhatsApp build provided the “aha” moment, the real lesson isn’t about sales agents — it’s about a fundamental shift in how we approach prompt engineering. For a long time, the industry has chased the “perfect” system prompt, operating under the misconception that “more details always equal better results." We’ve been treating every edge case or logic failure as a prompt problem, leading to the “All-in-One Prompt” that eventually collapses under its own weight.
To solve Prompt Bloat, we must stop trying to make the prompt “smarter” and start making the architecture "leaner." This requires a radical departure from traditional instruction-heavy styles.
The most critical reason to adopt a modular style is the model’s cognitive budget. Every time an LLM runs, it has to parse the system prompt, compress those rules internally, and apply them while simultaneously trying to understand what the user is saying.
By moving logic (like “if size is missing, ask for size”) into a separate code node or workflow, you are essentially offloading the “thinking” requirements. In this new style of prompting:
- The workflow handles the deterministic logic: the sequential “if/else” chains that a computer does perfectly every time.
- The LLM handles the Nuanced Language: The spontaneous, human-to-human conversation that models are built for.
When you strip away the logic-heavy rules, the model no longer spends its limited tokens managing instructions; it spends them performing the task.
Moving forward, your goal shouldn’t be a comprehensive system prompt but a dynamic instruction set. This style follows three core principles:
- Strict Separation of Concerns: If a rule can be calculated via code (like checking a database or counting items), it should never appear in your system prompt. The prompt should only know the result of that calculation.
- Task-Specific Injection: Instead of giving the model 50 rules for 50 scenarios at once, give it only the one rule that matters for the current turn [from query]. This prevents the model from getting confused or skipping steps.
- Minimalist Identity: Keep the “Contextual Core” focused on persona and tone [from query]. An agent that knows who it is but is told only one thing to do will always outperform an agent buried under a mountain of business logic.
The “unpredictable” behaviour we often blame on LLMs—repeating questions, contradicting instructions, or hallucinating logic—is usually just a symptom of Prompt Bloat. When a model is over-encumbered, it ceases to be a reliable tool.
By decoupling logic from language, you transform the AI from an overwhelmed “everything-specialist” into a precision instrument. The solution to building more powerful AI agents isn’t more words in the prompt box; it’s a better architecture outside of it. Stop building “Smart Prompts” and start building Modular Instruction Sets. Your system’s reliability depends on it.
I Swapped All-in-One Prompts for a Modular Instruction Set (and Why You Should Too) was originally published in Towards AI on Medium, where people are continuing the conversation by highlighting and responding to this story.