What Is Context Engineering?

Context engineering is the practice of deciding what information an AI model sees in its context window for a given task, when it sees it, and how much of it gets included. It covers everything besides the prompt text itself: retrieved documents, conversation history, memory, and tool outputs. Prompt engineering asks what to tell the model. Context engineering asks what to show it, and how much.

Why context engineering became its own discipline

Through 2025 and into 2026, industry vocabulary shifted from "prompt engineering" to "context engineering." That shift tracks a real change in where AI agents actually break in production.

A well-written system prompt doesn't help much if the document retrieved underneath it is irrelevant, or if conversation history has crowded out the question actually being asked. Large language models also run into a well-documented "lost in the middle" problem: when a context window is stuffed with a lot of text, the model pays less attention to whatever sits buried in the middle of it, even when that part matters most. Correctness and cost turn out to depend as much on what surrounds a prompt as on the prompt text itself.

The instinct is to fix this by adding more: more retrieved chunks, more memory, more history, on the theory that more context can only help. It doesn't. Every extra token is something the model has to weigh against everything else in the window, and irrelevant context measurably lowers response quality, not just cost. The disciplined fix is a token budget: deciding in advance how many tokens each type of information is allowed to use, and enforcing that limit everywhere context gets assembled, not just hoping it stays reasonable.

Matimo builds to this discipline directly, in two places most platforms treat as a single afterthought. We first laid out this five-part engineering framing in Introducing Matimo.ai; the previous post in the series, What Is Prompt Engineering?, covered the instructions and tool descriptions a model receives, and the series closes with Graph Engineering: How Matimo Studio Is Built for It. Matimo OSS decides what an agent's own tool and domain knowledge should load. Matimo Workbench decides what a conversation's retrieved knowledge, memory, and history should carry. Here's both.

How Matimo applies context engineering

Matimo is an AI agent platform that applies context engineering at two layers. Matimo OSS controls which agent skills and domain knowledge load into context. Matimo Workbench controls the context of each request through explicit budgets for instructions, retrieved knowledge, memory, conversation history, and the current user input.

This turns context engineering from a prompt-design practice into an enforceable execution policy: every component has a limit, selection rule, and audit trail.

Matimo OSS: progressive disclosure, not a wall of skills

Every provider package in Matimo OSS ships a Skill, a knowledge file that teaches an agent how to use that provider correctly. Dump every skill an agent has access to into the system prompt on every call, and you've recreated the exact problem context engineering exists to solve: irrelevant tokens burning budget and pulling the model's attention away from the one skill that actually matters for the request in front of it.

Matimo's skills system avoids that with three levels of progressive disclosure:

• Level 1: list only. An agent can list every registered skill as a name plus a short description, roughly 50 tokens per skill. Enough to know a skill exists and what it covers, nothing more.
• Level 2: full or section-scoped content. Only when a skill is actually relevant does the agent load its full content, or a single named section of it, capped to a maxTokens limit you set. A Slack skill with a "Rate Limits" section and a "Thread Replies" section can load one section at a time instead of the whole file at once.
• Level 3: bundled resources. Scripts and reference assets that ship alongside a skill load on demand too, not as part of the base content every request pays for.

On top of that structure sits a semantic search layer that decides which skills are relevant in the first place, so an agent doesn't have to load every skill's metadata and guess. It's TF-IDF (term frequency, inverse document frequency) cosine similarity search, zero external dependencies by default, with a pluggable embedding provider if you want to swap in OpenAI or Cohere embeddings instead. The default helper that assembles this into a system prompt, buildRelevantSkillPrompt(), selects the top 3 most relevant skills, and only above a minimum relevance score of 0.3, before injecting their content. A query with no skill above that threshold injects nothing, on purpose, rather than padding the prompt with a low-confidence guess.

The result: an agent serving many domains, Slack, GitHub, Postgres, and a dozen more, carries the cost of one relevant skill per request instead of all of them. That's skill-level context budgeting, decided before a single conversation-level token gets spent.

Matimo Workbench: the Context Engine's hard budgets

Once a request reaches Matimo Workbench, the Matimo Context Engine assembles what the model actually sees for that turn, against explicit, per-component token budgets rather than one soft ceiling for the whole prompt:

Token counts are estimated at 4 characters per token, and each component is truncated independently against its own ceiling, not just at the very end. Conversation history is capped to the five most recent turns, folded in newest-first until the running total hits the 1,000-token ceiling, so a long conversation degrades gracefully to its most recent exchanges instead of silently truncating mid-sentence somewhere in the middle.

The knowledge base slice of that budget is filled by hybrid retrieval: pgvector similarity search combined with keyword search, not vector search alone, so an exact-match term in a query isn't at the mercy of embedding similarity to surface the right chunk. This runs on the same knowledge infrastructure covered in Introducing Matimo.ai: session memory for in-conversation context, long-term memory backed by pgvector semantic search, RAG knowledge bases, a knowledge graph for relationship-based reasoning, and KB Grounding, which requires agents in regulated domains to cite an approved source rather than answer from general training.

Underneath the budgeting sits a second cost lever: semantic caching, which reuses past LLM responses by meaning rather than exact text match, cutting LLM costs by 50 to 90% at scale for requests that mean the same thing as one already answered.

Every one of these calls also gets tagged with provenance: whether the response came from a live model call, was reshaped by the Context Engine (compression, retrieval, tool pruning, routing), came back instantly from the semantic cache, or some combination of both. That's a meaningful claim to make about a system, so it's worth being precise about what it actually is today. Provenance tagging is real and unconditional, computed for every execution that makes at least one LLM call, written into the audit log. What it isn't yet is something you can see. There's no citation chip, no provenance indicator, no dashboard in Matimo Workbench today that surfaces this to a user or an admin. It's built for observability now, captured on every call in the audit trail, with the UI surfacing it on the roadmap. If you're evaluating this for a compliance use case, that distinction matters: the data exists and is queryable; the point-and-click view of it doesn't exist yet.

Two layers, one discipline

Put together, the two layers answer the same question at two different scopes. Matimo OSS asks it once, at the skill level, before a conversation even has a topic: which of an agent's own domain knowledge files are relevant enough to spend tokens on right now. Matimo Workbench asks it again, at the request level, every single turn: how much of the budget goes to instructions, how much to retrieved knowledge, how much to memory, how much to history, and how much is left for the question actually being asked. Neither layer is a single RAG pipeline bolted onto an agent after the fact. They're the same discipline, applied at two different points in the stack, with real numbers behind both, not a slogan about "smart context."

Frequently asked questions

What is context engineering?

Context engineering is the practice of deciding what information a language model sees in its context window, when it sees that information, and how much of it is included. It covers retrieved documents, conversation history, memory, and tool outputs: everything besides the prompt text itself.

How is context engineering different from prompt engineering?

Prompt engineering focuses on the instructions and tool descriptions written directly into a prompt. Context engineering focuses on everything else that fills the context window on a given call, including what gets retrieved, what memory gets included, and how much conversation history survives. The two are complementary disciplines, not competing ones.

What is the "lost in the middle" problem?

It's a well-documented issue where large language models pay less attention to information buried in the middle of a long context window, even when that information is relevant. It's one reason stuffing more text into a prompt does not reliably improve answer quality, and can make it worse.

What is a token budget?

A token budget is a hard limit on how many tokens a specific type of context, such as system instructions, retrieved knowledge, or conversation history, is allowed to use. Enforcing separate budgets per component, rather than one soft limit for the whole prompt, keeps any single input from crowding out the rest of what the model needs to see.

Does Matimo have a dedicated context engineering system?

Yes. Matimo Workbench's Context Engine enforces hard per-component token budgets, system prompt, knowledge base, memory, history, and the current user turn, capped at 4,000 tokens total, and retrieves knowledge base content with a hybrid of pgvector similarity search and keyword search. Matimo OSS separately manages which of an agent's own skills load into context, using progressive disclosure and TF-IDF semantic search.

Does Matimo show where a response came from?

Every LLM call in Matimo Workbench is tagged with provenance: whether it was a live model call, reshaped by the Context Engine, served from the semantic cache, or some mix of both. That tagging is computed and logged for every call today, but there is no dashboard or citation chip yet that surfaces it to a user or admin; it lives in the audit trail for now.

If you want to see the skill-level layer directly, Matimo OSS is free, open source, and installable now: npm install matimo or pip install matimo. If you want the request-level layer, Matimo Workbench ships the Context Engine, knowledge bases, memory, and KB Grounding on every plan, Freemium included.

The next post in this series covers what an agent is actually allowed to touch: harness engineering. It closes with Graph Engineering: How Matimo Studio Is Built for It, on how the individual steps compose into a workflow. Most platforms treat one or two of these five surfaces as a headline feature and leave the rest to you. We think all five need to be structural, not optional.