I scrolled through another twenty posts on Facebook today. Five of them promised "the prompt that will change your approach to AI". Three had clickbait headlines like "this one trick". One even had a PDF download: "50 best prompts of 2026".
And every single one misses what actually makes the difference.
I'm not writing this to dismiss prompts — they matter. I'm writing this because the obsession with prompts is a symptom of misunderstanding how these models work. And that misunderstanding is costly — because teams invest time polishing questions instead of building the system that makes the question not need to be perfect.
The model is a calculator. Your data is the spreadsheet.
Imagine a calculator. You can write equations a thousand different ways — elegantly, concisely, with perfect parentheses — but if you feed it the wrong numbers, the result will be wrong. It doesn't matter how beautifully you phrase the query if the model doesn't have access to the right information.
Language models work the same way. They're phenomenal at reasoning, synthesis, and generating text — but only based on what they receive as input. A generic model without context gets a generic question and returns a generic answer. Not because it's weak. Because it knows nothing about you, your project, your clients, your rules.
That's not a prompt problem. That's an architecture problem.
The 80/20 no one shows you in Facebook posts
The impact of working with AI breaks down roughly like this:
- ~40% — quality and relevance of context (RAG, documents, data)
- ~20% — system instructions (skills, persona, per-task rules)
- ~20% — memory and continuity (memory, past decisions, preferences)
- ~20% — the prompt itself
The entire "prompt engineering" industry focuses on that last 20%. The rest is either ignored or buried in technical documentation most people will never read.
What actually makes the difference: four layers
1. Skills — the agent knows how to behave
A skill is a per-task instruction. Not "be a helpful AI" — but precise rules: what tone to write in, what to do in a given context, which steps to follow, what to avoid.
When I work with Hermes on a blog article — the agent loads a skill with Bearly blog writing rules: tone of voice, section structure, image guidelines, link format. I don't have to explain that in every prompt. The system knows.
The same applies to AI agents in any company — instead of describing how to handle a customer complaint every single time, you write the instruction once and every interaction with that context loads it automatically.
2. RAG with intelligent filtering — signal instead of noise
RAG (Retrieval-Augmented Generation) means giving the model external knowledge. But there's a trap most implementations fall into: they dump everything in and hope the model figures it out.
The problem: the more irrelevant context, the worse the model performs at extracting what matters. This is literally proven by research — the phenomenon is called "lost in the middle". The model loses track of key information when it's buried in the middle of a long context.
That's why in Pokelo we care about semantic search that filters — not "give the model the entire company knowledge base", but "find the 5-8 fragments most relevant to this specific question". Ask about the business model — get business model documents. Ask about onboarding — get onboarding procedures. Not the full company history from day one.
That's the difference between RAG that works and RAG that gives the impression of working.
3. Per-project instructions — the agent understands where it is
Every project has its own stack, conventions, and rules. Without this information the agent works like a new employee on day one — guessing or asking about everything.
In Khirby you can define project context — technologies, naming conventions, processes, linked documents. The agent comes into a project and immediately knows what it's dealing with. You don't have to start every session with "we're using NestJS, Drizzle ORM, we have this code style".
4. Memory — the agent remembers
A human expert you hire year after year remembers your preferences, past decisions, things that didn't work. A generic chatbot without memory starts from zero every session.
Memory is the mechanism that lets an agent build understanding over time — stylistic preferences, architectural decisions, business context that accumulates. With each session the system is better calibrated to your specific style and needs.
A concrete example: you ask about the business model
Let's see what this looks like in practice. Scenario: you have a CRM with a company knowledge base and you ask the agent about the business model of your product.
Without a system: the model knows only what you typed in the prompt. You'll get an academic answer about business models in general, or a wrong answer because the agent is guessing from the company name.
With a system (Pokelo + Khirby): semantic search combs through the company knowledge base and pulls: the strategy document with the business model, meeting notes where it was discussed, the current pricing, customer segments. The agent gets precise context and answers based on your actual company data — not guesswork.
And crucially — it doesn't load the entire email history from the last 3 years, all support tickets, and technical documentation. It loads what's relevant. Signal, not noise.
"But that prompt was really good..."
I hear this often. And yes — a good prompt makes a difference on the margin. If you have a good system, a good prompt gives you results 10% better. If you have a weak system, even the perfect prompt gives you a result 10% better than mediocre.
The cooking analogy: you can have the best chef in the world — if the fridge is empty, they'll make do with whatever. With good ingredients and a chef who knows where to look in the pantry — magic happens. The recipe (prompt) is the last step, not the first.
That's how we think about AI architecture at Bearly. Pokelo is the pantry — company knowledge base with intelligent filtering. Khirby is the chef who understands the project. Memory is the experience that accumulates. The prompt is the last step.
How to start — without reading 200 pages of documentation
If you want to build a system that actually works, start with these three things:
- Write a project instruction — 1-2 pages: what the project is, the stack, conventions, what the agent should not do. This is your equivalent of AGENTS.md or PROJECT.md.
- Connect a knowledge base — documents, procedures, FAQ, decision history. It doesn't have to be perfect. Pokelo will index it and make it available to the agent via semantic search.
- Add memory for preferences — writing style, response format, things that work in your context. Instead of repeating this in every prompt, save it once.
Only after those three things should you start optimizing prompts. Before that you're optimizing something without solid foundations.
Magic prompts don't exist. What exists are systems that make the question not need to be magic — because the context is right, the knowledge is available, the agent understands where it is. That's Pokelo + Khirby in one sentence.
Not magic. Engineering.