Instructions, context, and memory

An application can supply standing instructions about the model's role, behavior, and response requirements. Many platforms provide a system-level message for this purpose, with priority defined by their instruction hierarchy. Use it to describe how the model should behave. Access restrictions belong in software controls as well.

Many AI platforms assign different authority to instructions based on their source. The model should follow that ordering when instructions conflict. A retrieved page is usually task material, so a command inside it should not acquire the authority of the application's own rules. Preserving that distinction is part of defending against prompt injection.

A text tokenizer converts text into token identifiers using a particular encoding. Its units may represent whole words, word parts, punctuation, or other fragments. Different tokenizers can split the same sentence differently. Those choices affect context capacity and usage accounting, which is why word counts are only a rough guide to token counts.

What does the model need to make the next decision? Context engineering turns that question into application behavior: selecting instructions, retrieving documents, retaining useful results, and removing clutter. The selection changes as work progresses. A good context strategy supplies relevant evidence when it is needed and gives the system a way to recover details later.

A model has a finite capacity for the information involved in a single inference context. Supplied input and space needed for generation must fit the model's limits. Information stored elsewhere has to be brought into context to be used directly. Increasing the window gives you more capacity; choosing useful content remains part of the job.

Long-running work accumulates more history than the next step needs. Compaction reduces that history, often by summarizing earlier messages and removing redundant material. Preserve decisions, constraints, and unfinished work with care. Since compression loses detail, retain a way to consult the underlying records when the summary leaves an important question unanswered.

Session state lets an application keep track of the current interaction. It may include messages, intermediate results, progress, and a pending approval. Some state is supplied to the model; other parts remain in application storage. Keeping that distinction clear helps avoid stuffing every operational detail into the prompt.

An agent may keep immediate task information in its current context, a scratchpad, or task state. This is often called working memory, though implementations vary. Refresh the selection as the task progresses so the useful notes remain easy to find.

Useful information can survive a session in a file or database. Later, the application retrieves relevant records and supplies them to the model. That retrieval is what makes a saved preference available for the current response. Storing the record changes application memory, not the model's trained parameters.

Imagine a run stopping halfway through a long job. A checkpoint gives its recovery logic a recorded place to begin, including state and completed results.

External changes need separate attention. Restoring a local checkpoint does not undo an order already submitted to another service.

Resuming means restoring the work well enough to continue from retained progress. That involves more than reading a saved file: tools may need to reconnect, permissions may have changed, and an external operation may have completed during the interruption. Recovery logic reconciles those conditions with what the application last recorded.