Context engineering is the practice of assembling the context an AI system needs to do a specific job well: the brand rules, the ICP, the positioning, the constraints that separate useful output from generic output. An intelligence layer is the system that holds and serves that context continuously, so the assembly happens the same way every time instead of living in one person’s working memory. The first is work. The second is where the work should live. Most of the industry is currently confusing the two: hiring for the first when it should be installing the second.
Open a job board and you can now find postings for “context engineer.” Give it six months and there’ll be a certification. That’s usually the moment to get suspicious — the point where an industry turns a temporary gap into a permanent headcount.
The gap is real. Scott Brinker recently framed 2026 as “halftime of the Decade of the Augmented Marketer.” Ana Mourao at MarTech keeps making the same argument: the context around AI tools matters more than the tools. They’ve named the work: context engineering, designing and maintaining the context AI systems need to produce anything useful. McKinsey’s 2026 research points the same direction: deploying agentic AI is an experiential problem, not a technical one. The models can already do the work. Most companies just haven’t built the context around them.
All correct. And all of it is being answered with the wrong instrument: a person.
What Is Context Engineering?
Context engineering is the discipline of deciding what an AI system needs to know to do a job, and getting that knowledge in front of it: who the buyer is, how the brand speaks, what claims are off-limits, how you position against the alternative the prospect is already using. Done well, it’s the difference between an agent that drafts something publishable and an agent that drafts something plausible. The work is legitimate. The question is who — or what — performs it.
Here’s what “context engineering as a job” actually looks like. Someone (a context engineer, a RevOps hire, an ops-minded marketer) sits between your knowledge and your AI. They translate your brand voice into a prompt. They paste your ICP into an agent. They remind the content tool how you position against a competitor. When positioning shifts, they go update it in the six places it lives. When a new agent comes online, they brief it from scratch.
You’ve just rebuilt the bottleneck AI was supposed to remove. Your context now lives in one person’s working memory and a scatter of prompt docs. It goes stale the day they take vacation. It’s inconsistent across tools by design, because a human is retyping it each time. And it doesn’t compound: every prompt starts near zero.
That’s not a discipline problem. It’s an architecture problem. And architecture problems don’t get solved by hiring.
What Is an Intelligence Layer?
An intelligence layer is a governed, persistent home for your go-to-market context: one place where brand voice, ICP, positioning, and proof live as structured knowledge, and from which every tool, agent, and human draws the same version. Update positioning once and it changes everywhere at once. No retyping, no six stale copies, no briefing each new agent from scratch. I’ve written up the six components of an intelligence layer separately; the short version is that it’s the difference between context someone remembers and context the system enforces.
Be specific about which context. This isn’t a generic knowledge base. It’s your go-to-market context, the operating context behind the actual work: composing emails, writing blogs, building content, coaching a rep through a live deal. And GTM context has a property most internal knowledge doesn’t: its output is public. The blog that ranks. The landing page a buyer reads. The answer an LLM gives when someone asks about your category. Get the context right and that public output is right. Get it wrong and you’ve published the mistake at scale.
Ontogent organizes that context along nine dimensions, the facets every piece of context is tagged on, so the right slice gets assembled for whatever you’re composing:
- Persona: the buyer roles and titles the context speaks to.
- Competitor: the alternatives it positions against.
- Vertical: the industries it applies to.
- Buyer stage: where in the journey it lands, from awareness to decision to retention.
- Topic: the subject matter it covers.
- Product: the products and features it describes.
- Channel: which GTM motion it feeds — email, social post, blog, paid ad, landing section, DM.
- Goal: the business objective it serves.
- Creative: the visual treatment, and the point of view a visual is meant to argue.
Tag context on all nine and the tool composes for a real job (a cold email to an unaware VP of Ops in freight, a mid-funnel blog on a topic your buyer is actually searching, a landing section for a solution-aware buyer) instead of handing an agent a generic brand doc and hoping.
Half of that points inward: making your own agents and team sharper. The other half points outward, at every machine your buyer consults before they talk to sales: the Series B CTO asking Perplexity “what are the best alternatives to [competitor]?” long before they fill out a form. That’s why the context carries its own machine-readable output: JSON-LD, entity definitions, an llms.txt file, citation structure that makes an LLM quote you instead of paraphrasing you.
When Does a Job Become a Tool?
Here’s the test: work that is repeatable, rule-governed, and has to stay consistent across systems is not a job. It’s software that hasn’t been written yet. Payroll used to be a room full of clerks. Ad bidding used to be a person on a phone. The work didn’t disappear; it got encoded, and the humans moved up to the parts that need judgment.
Context engineering fails the “keep it a job” test on every count. Your brand voice is a set of rules. Your ICP is structured knowledge. Your competitive framing is a position that needs to read the same in your CMS, your email, your ad copy, and every agent prompt at once. Rules, structured knowledge, and consistency across systems: that’s the exact spec for a tool, not a hire.
How Do the Two Compare?
The cleanest way to see the difference is side by side:
| Context engineering (as a practice) | Intelligence layer (as a system) | |
|---|---|---|
| Scope | One prompt, one agent, one task at a time | All GTM context, served to every tool, agent, and human |
| Owner | Whoever wrote the prompt, usually one person’s working memory | The system; humans govern the rules instead of retyping them |
| Time horizon | Session-length; starts decaying the day it’s written | Persistent; one update propagates everywhere at once |
| Failure mode | Drift: six subtly different versions of your positioning in the wild | A wrong rule enforced everywhere, which is why governance and review matter |
Note the failure modes. The practice fails quietly and constantly, through inconsistency nobody notices until a buyer does. The system fails in one consistent way, which is also the version of wrong you can actually find and fix. I’ll take the correctable failure mode.
Where Do AI Agents Fit?
Agents are the reason this distinction stops being academic. A human contractor with a vague brief asks clarifying questions. An agent with a vague brief produces confident output anyway, and produces it fast. Whatever context gap exists in your setup, agents don’t expose it — they publish it.
So the sequencing matters. If you’re evaluating AI agents for SEO or looking at AI agents for marketing more broadly, the question that decides whether the pilot works isn’t which agent framework to pick. It’s whether there’s governed context for the agent to draw from: brand rules it can’t violate, positioning it can’t contradict, an ICP it doesn’t have to be re-told. Teams that adopt agents on top of an intelligence layer are briefing a system once. Teams that adopt agents without one are signing up to do manual context engineering for every agent, forever: the exact job-shaped trap this post is about. The same logic applies one level down: even using ChatGPT for marketing well is mostly a context problem wearing a tool’s name.
Which Do You Need First?
The honest answer: the practice precedes the system, briefly. You can’t encode context you’ve never articulated. If your positioning lives in the founder’s head and your ICP is “companies like our current customers,” a stretch of context engineering (writing it down, resolving the contradictions) is the prerequisite for everything else.
But do that work with the intent to encode it, not to staff it. The articulation phase is a project measured in weeks. The moment the output exists (voice rules, ICP, competitive frames) it belongs in a system, because from that point forward the job is distribution and consistency, and humans are the wrong instrument for both. What you’d have to believe to hire a context engineer instead is that your context will keep changing faster than software can track it, across more tools than software can reach. For a GTM org, neither is true. Positioning shifts quarterly, not hourly; the tools all speak API.
You Don’t Have to Take This on Faith
The hardest, most repetitive part of that layer (turning your context into rules an agent actually obeys, and deciding which rule wins when two of them collide) is already open source. It’s ontogent-core: an MIT-licensed engine published in June. You hand it your standards as a “pack” and the facts of a specific case, and it returns two things: the hard constraints an agent cannot violate, and the ranked context it should weigh. Its own metaphor is bumper bowling for agents: it takes the gutters away.
The behavior is deterministic, which is the whole point of a tool. A hard guardrail can never be out-ranked by something merely relevant. When two sources conflict, the higher-authority one wins on a fixed order: regulatory over expert over canonical over inferred. And if the context is incomplete, the guardrails still fire instead of silently disappearing. A person does this inconsistently, on a good day. Software does it the same way every time.
The split is the design. The engine is open; your domain knowledge lives in packs that stay yours: your brand, your buyers, your positioning, never in the repo. Read the code today and run it against your own context, and the difference is immediate: context engineering as a role someone performs, versus context engineering as a system that runs.
FAQ
What is context engineering in marketing?
Context engineering in marketing is the work of giving AI tools the operating context they need to produce on-brand, on-strategy output: brand voice rules, the ICP, competitive positioning, claims that are approved or off-limits. Without it, AI produces generic content in your industry’s average voice. The debate isn’t whether the work matters (it does) but whether it should be performed repeatedly by a person or encoded once into a system.
Is context engineering a real job?
The work is real; the permanent headcount is the mistake. Articulating your context (writing down voice, ICP, and positioning, resolving contradictions) is a legitimate project and needs human judgment. But the ongoing part, keeping that context consistent across every tool and agent, is repeatable and rule-governed, which is the definition of work that belongs in software. Hire for judgment. Install for consistency.
Do I need an intelligence layer?
A rough test: count the places your positioning currently lives: prompt docs, agent configs, CMS, sales decks, one person’s memory. If the answer is more than two and they’ve drifted apart, you already have the problem an intelligence layer solves. Teams running a single tool with one operator can defer it. Teams adopting agents, or publishing AI-assisted content at volume, can’t: the inconsistency compounds in public.
How is an intelligence layer different from a knowledge base?
A knowledge base stores documents for humans to search. An intelligence layer serves governed context to machines: it’s structured on dimensions like persona, competitor, and buyer stage, it enforces hard constraints an agent can’t violate, and it resolves conflicts by authority instead of leaving them for a reader to notice. A wiki holds what you know. An intelligence layer determines what your tools do with it.
The companies pulling ahead aren’t hiring the discipline. They’re installing it. Before you write that job description, read the engine, then ask whether you’re about to hire a person to do the work of a piece of software.