Engramic Concepts
What is a context package?
Start with the problem the term exists to solve. An AI agent has no memory of your organisation between tasks. Each time it acts, it acts from whatever it was handed at the start — a system prompt, a connected data source, a few instructions typed into a window — and when the task ends, that understanding is gone. The next task starts the agent over.
A context package is a name for making that handed-over understanding into a deliberate, durable thing rather than an accident of whatever was lying around when the agent started. It is the operating brief an agent carries into a task: what it's trying to do, what it's constrained by, what it needs to know, assembled on purpose. But the word that does the real work is carries. The point is not only that the brief is deliberate; it is that the brief exists as a portable artefact the organisation owns and the agent travels with, rather than as configuration trapped inside whatever runtime the agent happened to start in.
The term is not yet industry-standard vocabulary. The problem it points at is entirely real, and most teams are solving it badly without a name for it.
The Problem underneath the name
Agents are stateless. A language model does not retain what it learned about your business from one task to the next, and the protocols that connect agents to tools and data are built around stateless sessions too. So whatever an agent knows when it acts, it knows because something assembled that knowledge and put it in front of the agent at the start.
The question is what does the assembling, and how deliberately. In most setups today the answer is: whatever happens to be wired up. A system prompt someone wrote months ago. A retrieval system that fetches documents by similarity. A handful of MCP connections to live tools. Each of these contributes something, but nothing owns the result. There is no single, inspectable answer to the question "what was this agent actually working from?" — the operating context exists only as the transient sum of whatever got pulled in this particular run, and it dissolves when the run ends.
That is the gap a context package fills: it makes the operating context a thing in its own right — assembled deliberately, inspectable before the agent acts, and the same on the next run unless someone deliberately changes it.
What a Context Package Is, as a Concept
Independent of any product, a context package is the bundle of operating context an agent is given before it acts, treated as a first-class artefact rather than a transient assembly. Three properties distinguish it from the ad-hoc alternative. Two are about discipline; the third, portability, is the one that makes the concept matter, and it gets its own section below.
It is deliberate. The context an agent carries is chosen, not scavenged. Someone — or some process — decided what this agent needs to know and what it is constrained by, rather than letting retrieval similarity and an aging prompt decide by default.
It is portable. Because the operating context is a defined artefact rather than a tangle of live connections, it can travel. The same brief can move with the agent from one execution environment to another, which matters because the environment an agent runs in is increasingly not the one it was first built in.
It is inspectable. Because it exists as a discrete thing before the agent acts, you can look at it. "What was this agent working from?" has a literal answer you can read, rather than a reconstruction you have to assemble after the fact from logs and prompt files.
None of these requires a particular technology. They describe a way of treating an agent's operating context — as an artefact you author and hold, rather than a side effect you hope came out right.
What it is not
A context package is not a system prompt. A system prompt is part of what might go into one, but a system prompt is typically hand-written, static, and singular, where the point of a context package is that it is assembled from an organisation's actual knowledge and changes as that knowledge does.
It is not retrieved context. Retrieval fetches relevant documents at the moment of need; a context package is settled before the agent acts. The two can coexist — an agent can carry a package and still retrieve at runtime — but they are different operations at different moments, and a pile of retrieved documents is not an operating brief.
And it is not a memory feature. Per-user memory personalises a tool to an individual over time. A context package is about what a given agent is given for a given task, drawn from organisational rather than personal context. They solve different problems and a tool can have one without the other.
The distinctions matter because each of those three — prompt, retrieval, memory — is a real and useful thing that a context package draws on or sits beside, not a synonym for it. Collapsing them is how the underlying idea gets lost.
Why Portability is the part that Matters Most
Of the three properties, portability is the one that turns a context package from a tidiness improvement into a strategic one.
An agent's operating context, if it lives only as the configuration of one vendor's runtime, belongs in practice to that vendor. Change providers and you rebuild it. If instead that context is a portable artefact the organisation holds, the agent can move — to a more capable model, a different execution platform, a new harness — carrying its brief intact. The most routine version of this is model churn: a new model generation arrives every few months, and when the operating context is an artefact separate from the model, upgrading to it doesn't mean recreating the organisation's understanding from scratch. What the organisation authored survives the switch, because it was never locked inside the thing being switched. The package is the unit in which an organisation's investment in its agents stays its own.
This is why the concept is worth naming even though the industry hasn't settled on the name. The teams that treat an agent's operating context as disposable are quietly building it inside someone else's runtime, to be rebuilt the next time something changes. The teams that treat it as a portable artefact are keeping it.
Engramic's approach
How Engramic Approaches it
There are multiple ways to build an artefact like this. This is one approach.
In Engramic, a context package is the signed, portable brief an agent carries into a task — its goals, constraints, decisions, and the context it should be working from, drawn from the organisation's authored knowledge and assembled before the agent acts. It is signed so its origin and integrity can be checked, portable so the agent can carry it into Engramic's own execution or any external harness, and inspectable so the question of what the agent was working from is answered by reading the package rather than reconstructing the past. The concept is general; this is Engramic's specific shape for it. What the shape is built to guarantee is the property that matters: the operating context belongs to the organisation, and travels with the agent rather than staying behind in a runtime.