What is Context Engineering?
Context engineering is the practice of curating what an AI model receives — the information and the tools — so it can plausibly accomplish a task. The term consolidated in mid-2025, and two definitions are now canonical.
Harrison Chase of LangChain, whose June 2025 post named the practice:
“Context engineering is building dynamic systems to provide the right information and tools in the right format such that the LLM can plausibly accomplish the task.”
Anthropic, in Effective context engineering for AI agents:
“Context engineering refers to the set of strategies for curating and maintaining the optimal set of tokens (information) during LLM inference, including all the other information that may land there outside of the prompts.”
Both definitions treat tools as first-class, which is the part most often lost. Context is not only prompt text with plumbing attached — the set of tools an agent is offered is context, and it is usually the largest and least curated part of it. Anthropic is direct about the failure mode:
“One of the most common failure modes we see is bloated tool sets that cover too much functionality or lead to ambiguous decision points about which tool to use. If a human engineer can’t definitively say which tool should be used in a given situation, an AI agent can’t be expected to do better.”
Nobody invented context engineering. Andrej Karpathy popularised the framing, Tobi Lütke and Ankur Goyal contributed originating takes, Walden Yan called it the most important skill an AI engineer can develop, and Dex Horthy’s 12-Factor Agents argued for owning your context building. Anthropic’s Applied AI team gave it the systematic treatment.
Why the context has to be finite
Three ideas from Anthropic’s treatment explain why this is a structural problem rather than a tuning exercise:
- Attention budget — a model has finite working memory, grounded in the transformer’s n² attention. This is a limit of the architecture, not of the current generation.
- Context rot — recall accuracy degrades as token count rises, and it “emerges across all models.” A bigger context window moves the wall; it does not remove it.
- Diminishing returns — context is a finite resource, and each additional token buys less than the last.
Together these are why “use a larger window” is not an answer, and why curation is permanent work rather than a stopgap.
Declarative vs. imperative context engineering
The industry now agrees an agent should see less. The open disagreement is who decides, and whether anyone can check the decision beforehand.
Imperative context engineering decides at runtime — in a retrieval index, a runtime optimizer, a generated program, or model-side progressive disclosure. It produces a smaller context and no artifact. You can audit what happened; you cannot approve what could happen, because the surface does not exist until the agent asks for it.
Declarative context engineering decides once, in a file: the tools the agent sees, the fields that come back, the upstream operations behind them, and the credential authorizing exactly those and nothing else. It is linted, diffed and reviewed before anything runs. An agent may well have written the file — what matters is that a human saw it in between.
| Imperative | Declarative | |
|---|---|---|
| Where the shaping lives | Optimizer, index, generated code, model harness | A spec file |
| When it is decided | Per request | Once, at authoring time |
| Who decides | The system, adaptively | A human, reviewably |
| How it changes | Silently, as the system learns | A diff, in version control |
| Governance mode | Detection after the fact | Prevention before execution |
| Failure mode | Yesterday’s approved behaviour is not today’s | Staleness — the file must be maintained |
Relocation, not compression
There is a second distinction that matters more than it first appears. Most techniques operate on the same corpus: disclosure reveals fewer of the same tools, search ranks the same catalog, summarization shortens the same payload. All of them accept the work as the model’s and negotiate how much to reveal.
A capability changes what the work is. Choosing among many operations, sequencing three calls, correlating two responses, handling auth and pagination and retries, selecting five fields from sixty — none of these are shown to the model in shorter form. They are not shown at all, because the model no longer performs them.
Compression has a floor: you cannot compress below what the model must reason over. Relocation does not, because it changes the denominator rather than the ratio.
Context engineering in Naftiko
A Naftiko capability is the declared artifact:
- Tool selection as authorship — the capability exposes the operations its author wrote. There is no auto-discovery step mirroring an upstream catalog into the agent’s tool list.
- Output parameter shaping — typed output parameters with JSONPath mapping select the fields the task declared. An undeclared field is not shortened; it is absent, because it is never projected.
- Semantic descriptions — tool and field descriptions are fixed text in a reviewed file rather than metadata fetched from a vendor at connect time.
- Deterministic steps — sequencing and correlation execute in the engine, below the model, and never enter the context window.
- Reviewable before execution — the complete surface is readable, and lintable, before a credential is attached to it. This property is attestation: audit answers what an agent did, while a declared artifact answers what it could ever do.
Why it matters
Curating context is now table stakes; every serious approach does it. What differs is whether the result is something a reviewer can inspect. That question is what decides whether an agentic use case reaches a production system of record — because no amount of model capability tells a reviewer what an agent is able to reach.
