The Short Answer
The scarce AI skill in 2026 is retrieval and context engineering — deciding what an agent sees, from which source, at what point in a task — not prompt engineering, which is becoming baseline competence. Everyone can call the same models, so the proprietary knowledge layer is the differentiator. On ibl.ai you own all the code and the data, including the index and embeddings built from your corpus.
The shift is visible in job titles before it is visible in strategy decks. The roles being hired are RAG Developer, LLM Engineer, and AI Platform Architect — not Prompt Engineer.
Why is prompt engineering losing its premium?
Because the models got better at inferring intent, and because the practice got written down.
Structured prompting and evaluation still carry real value; a team that cannot evaluate its outputs is flying blind. But the techniques are now documented, teachable in a week, and increasingly handled by the model itself.
Context engineering has risen above prompt engineering as the differentiator in multi-agent systems — the structured design of what information reaches an agent across the full interaction lifecycle, including memory management, tool selection and dynamic context injection.
Put plainly: the question moved from what do I ask to what does it see when I ask.
The usage data points the same way. Among OpenAI's enterprise customers, Codex accounted for 64% of combined Codex and ChatGPT output tokens as of June 2026 — the volume moved to tool-using, context-heavy work rather than single-turn prompting.
What does retrieval engineering actually involve?
More decisions than the phrase "we added RAG" suggests. Each one is a place a production system quietly degrades:
- Chunking strategy. How a 90-page credit policy is split determines whether the relevant clause is ever retrievable as a unit.
- Ranking and reranking. Vector similarity finds things that look alike; a reranker decides which of them actually answers the question.
- Source routing. Which corpus for which question — and how the system knows the difference between a policy question and a transaction question.
- Freshness and versioning. A retrieved document that was superseded last quarter is worse than no document.
- Knowing when not to retrieve. Injecting irrelevant context degrades output. Restraint is a design decision.
The tooling that clusters around this — vector search across data warehouses, dedicated vector databases, grounded retrieval services — sits at the intersection of data engineering and generative AI, which is exactly why the skill is scarce. It requires both.
Why does this matter most in financial services?
Because the model is the same for everyone, and the corpus is not.
Every bank, asset manager and insurer can call the same frontier models on roughly the same terms. There is no durable advantage in model access.
What differs is proprietary: two decades of credit memos, the exception log that explains why a policy has eleven revisions, the deal history, the internal guidance that has never been published.
An assistant that can find the right paragraph in that corpus is worth something a general-purpose chatbot is not.
The same logic holds in healthcare, law and government. Financial services just feels it earliest because the regulatory record is dense and the cost of a confidently wrong answer is quantifiable.
The adoption gap makes the point sharper. Roughly 99% of companies plan to put AI agents into production and only about 9-14% have, per a Ness Digital Engineering report from August 2026 — and the pilots that stall rarely stall on model quality.
If the knowledge layer is the moat, should you rent it?
This is the strategic consequence most teams under-weight, and it follows directly from the premise.
If the differentiator is your corpus and the system built on top of it, then a managed platform that ingests, chunks, embeds and indexes that corpus is holding your differentiator — in a schema you did not choose, on infrastructure you cannot inspect, under retention you do not set.
| Asset | Managed RAG platform | Platform you own |
|---|---|---|
| Source documents | Copied into vendor storage | Stay in your systems |
| Embeddings and index | Vendor's, in vendor's format | Yours, portable |
| Retrieval logic | Opaque, tuned by the vendor | Yours to inspect and tune |
| Embedding model change | Vendor's schedule, full reindex | Your schedule |
| If you leave | Export the documents, rebuild everything | Nothing moves; it is already yours |
The last row is the real cost. Documents are portable. The tuned retrieval system built around them, over months, usually is not.
What should a team hire for?
Someone who can answer "why did the agent see this document and not that one" with a mechanism rather than a shrug.
In practice that means data engineering fundamentals, evaluation discipline, and enough domain understanding to know what a good answer looks like in your corpus. The vector database is the easy part; the judgment about what belongs in context is not.
It is also worth noting what no test catches: retrieval quality degrades silently. A system that returns plausible, well-formatted, subtly wrong context looks identical to a working one until someone with domain knowledge reads the output.
Cost shape matters here too. Per-seat assistants run roughly $30-60 per user per month — Glean is commonly cited around $40 — so a tool meant to be used constantly by a research team gets rationed by licence count rather than by value.
How does ibl.ai handle the knowledge layer?
ibl.ai is the agentic AI platform where you own all the code and the data. You self-host the entire stack inside your own perimeter, run it model-agnostic across any LLM and switch anytime, and pay by usage with no per-seat pricing — so you can deploy anywhere: your cloud, on-premise, GovCloud, or fully air-gapped.
For retrieval specifically: the documents, the embeddings, the index and the retrieval logic all live on infrastructure you control. Nothing about your corpus is copied into a vendor's storage to make the product work.
Because the platform is model-agnostic, the embedding model and the generation model are both configuration. Changing either is a decision you schedule, not one that arrives with a vendor release note.
1.6M+ users across 400+ organizations run the platform this way, including NVIDIA, MIT, and Syracuse University.
Rent the model, own the knowledge
The models will keep improving and keep converging, and your competitors will have the same ones.
The part that is genuinely yours is the corpus and the system that makes it findable. That is the asset worth building carefully — and the one worth keeping.
Related: What Is a Data Ontology? · Model-Agnostic AI: The Real Risk Is Vendor Lock-In