Context Engineering Isn't a Job. It's a Tool.
The industry is minting a job title for work that should be software. The engine is already open source.
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 calls 2026 "halftime of the Decade of the Augmented Marketer." At MarTech, Ana Mourao 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 "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.
The line between a job and 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.
What the tool holds: your go-to-market context
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. Human-authored content is 8x more likely to rank #1 and be cited than AI-generated content, but only when it's built to be cited. 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.
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.
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.
Originally published at strategnik.com/thinking/context-engineering-vs-intelligence-layer.