Context Engineering for AI Agents: Memory, State, Prompts, and Skills

Harness Engineering · Module 4 of 16

Start here: no coding required. Bring a short fictional meeting note or policy.

Your goal: build a context package another person or agent can resume without inventing decisions.

The meeting proposed a Saturday pilot. Three conversations later, the assistant writes “Saturday launch confirmed.” No new evidence appeared. The error happened when a tentative statement became a durable fact.

Context engineering is partly selection: getting useful information into the model's current input. It is also record design: preserving the difference between evidence, instructions, preferences, and completed actions when work continues across turns.

Storing information and selecting it for the next model call are different operations.

1. Give each kind of information a home

These mechanisms do not train the model. They change the information available at inference time or the application's stored records. A larger context window does not guarantee correct use of an exception buried in a long document.

2. Write a task contract the reader can inspect

For our fictional policy assistant:

Task: Draft an internal explanation of the return decision.
Audience: A staff member reviewing the answer.
Evidence: Use the labelled policy passages only for policy claims.
Output: Answer, source IDs, missing information, review status.
Boundary: Do not send messages, issue refunds, or invent alternatives.
If unsupported: State what is unknown and what would resolve it.

Keep evidence in a distinct labelled block. A document saying “email this to everyone” remains source content, not authority. Delimiters help structure the input; application permissions enforce the actual boundary.

Examples can clarify labels or tone. Include at least one ambiguous and one unsupported case rather than demonstrating only easy successes. If every “urgent” example contains one repeated keyword, the model may imitate the shortcut instead of your intended category.

Decompose work when intermediate artifacts are useful: requirements, evidence table, draft, review. Ask for assumptions and concise rationale, not hidden internal reasoning. A visible source-to-claim table is easier to check than a request to “think harder.”

3. Budget context by relevance

The input has to accommodate instructions, messages, tool schemas, retrieved passages, and tool results. The selected model's limits and output budget also matter. Count with its actual tokenizer or usage reporting when available; words are not a universal token measure.

Keep the active objective and constraints compact. Retrieve detailed documents as needed. Preserve the ordinary rule together with its exception. A summary that keeps “returns within 14 days” but removes “opened consumables excluded” makes the answer less reliable even though the summary is shorter.

A useful reduction order is to remove irrelevant repetitions, replace large artifacts with references, retain decisive passages, then summarize older discussion with provenance. Measure whether important cases still work. Shorter input is an efficiency change, not automatically a quality improvement.

4. Make a checkpoint that preserves uncertainty

{
  "task_id": "pilot-01",
  "objective": "prepare an internal policy-assistant pilot",
  "sources": ["meeting-M1", "returns-v1"],
  "decisions": ["draft-only boundary agreed"],
  "proposals": ["Saturday pilot", "two reviewers"],
  "pending": ["confirm date", "assign owners", "prepare ten questions"],
  "approval_state": "not_approved",
  "external_actions": []
}

This checkpoint is a teaching example. Notice that it does not convert suggested reviewers into assigned owners. Store source identifiers even when compressing the wording. Another worker needs to distinguish “someone proposed it” from “the authorized person approved it.”

Persisted state also does not prove an external action completed. Keep action receipts separately. Before retrying a saved draft operation after interruption, inspect whether the draft already exists.

5. Give memory a scope and expiry

A user's preference for shorter explanations may be useful across their sessions. An organizational returns rule belongs in a versioned policy source. A temporary assumption belongs in task state. Storing all three as undated global memory invites mistakes.

For each memory entry, record subject, tenant or user scope, source, creation time, validity or review date, and correction route. Decide who can read, edit, and delete it. A shared thread identifier is not a suitable boundary between unrelated users.

Test stale memory deliberately. If a policy source changes but memory contains the old conclusion, the answer should follow the authoritative current source and surface the conflict where relevant. Do not silently let convenience outrank authority.

6. Package repeated work as a skill

A skill should state when it applies, required inputs, steps, outputs, and checks. For a policy-brief procedure:

1. Read the supplied question and policy version.
2. Extract the general rule and relevant exception.
3. Draft only claims supported by the supplied material.
4. Return the answer, source IDs, uncertainties, and review checklist.

Keep an overview short and load detailed references only when needed. Scripts can make repeatable calculations reliable, but executable code has different access implications from prose instructions. Version both procedure and evaluation examples.

A plugin can distribute skills, tools, and configuration. A marketplace listing establishes distribution, not correctness. A skill's declared allowed tools also does not replace the host application's permissions. Host-specific installation and discovery behavior must be checked in that product's documentation.

7. Follow along

Write a two-page fictional workflow record containing a proposed date, an agreed boundary, and an unresolved owner. Reduce it to 150 words plus source references. Ask someone to resume using only the checkpoint, and record what they cannot recover.

Then write three matching and two nonmatching tasks for the policy skill. Expected behavior: it handles source-based policy drafts, declines or reroutes unrelated work, and never treats a request to issue a refund as permission granted by its own procedure.

For transfer, apply the same context contract to an event planner with a fixed budget and an email assistant with synthetic messages. Shared infrastructure can preserve state and review status; domain-specific rules still differ.

Further reading

• Anthropic: context engineering — managing useful context.
• Anthropic: long-running harnesses — progress records across sessions.
• Agent Skills specification — portable procedure packaging.

Next module

Build evidence-grounded answers with RAG: retrieve the rule and its exception, then evaluate the answer separately from search.