# Context engineering: the 3-layer setup that stops AI agents going generic > A practical guide to context engineering for AI agents: how to split your setup into a knowledge base, a library, and dynamic data, and build workflows on top. Source: https://contengi.com/blog/context-engineering Author: Stefan Maritz Published: 2026-10-03 Better prompts help for about a week. The lasting fix sits underneath the agent, in how you structure what it knows, what it can look up, and what it fetches live. ## TL;DR - Context engineering is deciding what information an AI agent can reach, where that information lives, and when it gets pulled into a request. - Start by listing the questions you need answered and mapping each one to its source, before you buy or build anything. - Layer one is the knowledge base: small, stable, hand-curated context like positioning, audience, competitors, and tone of voice. - Layer two is the library: working material such as transcripts, playbooks, and meeting notes, vectorised so the agent pulls only the passages it needs. - Layer three is dynamic data: live or snapshotted numbers from APIs like Google Search Console, Google Analytics, or your CRM. - Workflows sit on top and point at each layer, which lets one conversational agent replace dozens of single-purpose ones. - Keep the layers strictly separate. Dumping everything into the knowledge base is the fastest route to unreliable output. Every team building with AI hits the same wall. The first dashboards and drafts look great, then the answers start drifting into beige, could-be-anyone territory. Swapping models rarely fixes it, and better prompts help for about a week. The fix sits underneath the agent, in how you structure what the model knows, what it can look up, and what it fetches live. That discipline is called context engineering, and the setup I use splits it into three layers. It works whether you run content on your own or across several teams. ## What context engineering means in practice Context engineering covers everything a model can see when it answers a request, from standing instructions and reference documents to retrieved passages and live numbers from your tools. Anthropic has a solid technical write-up on [effective context engineering for AI agents](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents) if you want the developer view. For a marketer the working version is simpler. Get the right information to the agent at the right moment, and keep everything else out of its way. Generic output, the stuff people call [AI slop](https://contengi.com/blog/how-to-prevent-ai-slop), usually means the agent had too little context or far too much of the wrong kind. ## Step zero: map your questions before you pick any tools The temptation is to start with the platform. Copilot or Claude, Azure or a vector database, which connectors to switch on first. Park all of that for now. Write down the questions your team needs answered on a regular basis. Which competitors launched something this month? Which blog posts lost clicks? What did customers say about pricing on recent calls? Then map every question to the place its answer currently lives. You learn two useful things from this. You see which sources do the heavy lifting and which ones nobody touches, and you spot middleware you can cut. Plenty of stacks pull data through a third-party tool that re-packages a platform's own API. If the first-party API gives you the same data directly, connect to it and drop the middle step. Once that map exists, sort each source into one of the three layers below. Each of them have a different job. ## The three layers at a glance Layer What goes in How the agent uses it How often it changes Watch out for **Knowledge base** Value propositions, audience profiles, competitors, brand strategy, tone of voice, writing guidance Loaded in full on every request Rarely, it stays evergreen Bulk uploads and anything that isn't hand-curated **Library** Playbooks, transcripts, campaign notes, webinars, podcasts, meeting notes Vectorised, so the agent retrieves only the relevant passages Constantly Uncurated shared drives and internal material reused word for word **Dynamic data** Traffic, rankings, pipeline, campaign performance Fetched through an API, live or from a scheduled snapshot Daily or faster Storing numbers as text in the other two layers, where they go stale ## Layer 1: the knowledge base The knowledge base is the agent's long-term memory about who you are. It holds the stable, evergreen context that should shape every output: - Value propositions and positioning - Customer segments and audience profiles - Competitors and how you differ from them - Brand strategy and point of view - Tone of voice and writing guidance The agent loads this layer on every request, so it has to stay lean. Every line you add is something the model weighs up each time it writes. Hand-curate it, write it yourself or edit it down hard, and never fill it by bulk-uploading whatever is sitting in a shared drive. You can't dump 400 PDFs into this and expect it to be clean. Spring-clean, and load only what you really need an agent to know. Give the knowledge base an owner. It belongs with the team responsible for the organisation's core story. At larger organisations, product marketing should own the value proposition and the files around it, and changes should go through an approval step before they reach the agents. If you're a solo founder the owner is you, and the approval step is reading every change before it goes live. If you're starting from scratch, our guide to [AI knowledge base setup](https://contengi.com/blog/how-to-set-up-a-brand-knowledge-base-for-ai) walks through each section. ## Layer 2: the library The library holds runtime material, the working content an agent dips into when a task calls for it: - Playbooks and process documents - Call and interview transcripts - Campaign notes - Webinars and podcasts - Internal meeting notes This content is long, it changes constantly, and only a slice of it is relevant to any single request. So you don't inject it wholesale. You vectorise it, which turns each chunk into a searchable representation of its meaning, and the agent retrieves only the passages that relate to the task. Ask for a blog post on pricing and it pulls the few paragraphs from last month's customer call where pricing came up, and leaves the other 40 minutes alone. Transcripts are the richest thing you can put in here, because they carry the way you and your customers talk. There's more on that in [how to use transcripts for content](https://contengi.com/blog/how-to-use-transcripts-for-content). The library still needs curation. Pointing an agent at a large shared drive is the knowledge base mistake all over again, just slower to show up. Clear out duplicates, dead drafts, and anything nobody would want quoted. Confidentiality rules belong here too. Sales notes and customer-success calls are gold for briefs and analysis, but the agent needs to know they're internal. Write explicit usage instructions: use these insights to shape the angle, and never reuse them word for word in anything external. ## Layer 3: dynamic data The third layer is operational data, the numbers that change daily and lose their value when stale. Traffic, rankings, pipeline, and campaign performance all live here. None of it gets stored as text in the other two layers. The agent fetches it from source through an API when a request needs it. You have two options for how fresh that data is. - **Live queries** run at the moment of the request. Use them when the current value is the point, like asking how organic clicks changed last week against the [Google Search Console API](https://developers.google.com/webmaster-tools/v1/searchanalytics/query) or a Google Analytics property. - **Snapshots** pull data into your own database on a schedule, and the agent reads from there. In one setup, Salesforce gets a daily snapshot, so the agent isn't hitting the API all day for pipeline numbers that only need to be accurate to yesterday. The request itself becomes the query. A plain-language ask like "compare UK organic traffic for September with August" already carries the date range and the location, and the agent turns that into the right API call. Standards like the [Model Context Protocol](https://modelcontextprotocol.io/docs/2026-07-28/getting-started/intro) give agents a common way to connect to these sources, whether that's Search Console, Salesforce, HubSpot, or something else. ## How workflows sit on top of the three layers Once sources, knowledge base, and library are defined, building a workflow gets simple. Each step points at a layer. A typical sequence reads the knowledge base, retrieves source data, analyses it, and presents the result through a defined template. A blog workflow on this setup runs like this: 1. Load the tone of voice and writing guidance from the knowledge base. 2. Retrieve the relevant transcript passages from the library. 3. Apply the SEO playbook, also from the library. 4. Generate the draft. The same structure works for a competitor digest, a newsletter, or a performance report. Swap the template and the sources, and keep the layers. It also changes how many agents you need. I went from 50 separate agents to one conversational assistant with the specialist capabilities built in as flows. SEO research, for example, became a flow you call from inside the assistant. You ask for an outcome in plain language, and the assistant picks the flow and the layers it needs. For a look at what this does to the people running the system day to day, read [how AI content team workflows look now](https://contengi.com/blog/ai-content-team-workflows). ## Why the layers have to stay separate Getting the foundation right is what kills generic answers. When the knowledge base stays small and accurate, the library stays clean, and the numbers come fresh from source, the agent has no reason to fall back on the averages in its training data. You also get far more control over what comes out. Blur the lines and everything degrades together. Put live data in the knowledge base and it goes stale. Put every transcript in there and the brand voice gets drowned out. Leave the library uncurated and the agent retrieves an outdated playbook with total confidence. Use a simple test for every new piece of content. Will it still be true in six months, and should it shape every single output? If the answer is yes to both, it goes in the knowledge base. Long-form, changing, or only useful for some tasks, it goes in the library. A number that moves comes from an API. ## Add quality controls once the foundation holds Source checks and hallucination logging are worth adding, but later. Once the layers run, track which sources produce unreliable answers, then fix or remove them. Doing this before the foundation is in place means measuring a system that is bound to wobble. The order runs like this: map sources, structure the knowledge base, set library boundaries, connect dynamic data, then build workflows and controls. It's slower than spinning up another agent. It's also what turns a handful of prototypes into a system other people can use. ## FAQ ### What is context engineering? Context engineering is the practice of deciding what information an AI agent can access, where that information is stored, and when it gets pulled into a request. Done well, the agent answers with your positioning, your material, and your current numbers instead of falling back on generic training data. ### What is the difference between a knowledge base and a library? The knowledge base holds small, stable context such as positioning, audience, competitors, and tone of voice, and the agent loads it on every request. The library holds long, changing material such as transcripts, playbooks, and meeting notes, which is vectorised so the agent retrieves only the relevant passages. ### Should I use RAG for my AI knowledge base? Retrieval belongs in the library layer, where long-form content like transcripts and webinars lives. Keep the knowledge base lean and hand-curated so it can be loaded in full, and use retrieval for everything too large or too task-specific to send with every request. ### When should an AI agent use live API calls instead of snapshots? Use live calls when the current value is the point, such as last week's organic clicks from Google Search Console. Use scheduled snapshots, for example a daily CRM export into your own database, when a slight delay is fine and you want to avoid hitting an API repeatedly. ### How many AI agents does a team need? Fewer than you think. One conversational assistant with specialist capabilities built in as callable flows, such as SEO research, is easier to run than dozens of separate agents, because you ask for an outcome and the assistant picks the flow and the context it needs. ### Who should own the knowledge base? The team responsible for the organisation's core story, usually product marketing in larger companies, with an approval step for changes. For a solo founder, the owner is you, and every change should be read before it reaches the agents.