How to Build an AI Employee Context Pack

§ 01The Context Pack at a Glance

§ 02What Is an AI Employee Context Pack?

An AI employee context pack is a versioned operating index for one standing role. It defines which information should influence the worker, how that information ranks, where current facts live, and what to do when the needed context is absent or unsafe.

It supports task intake; planning; source selection; tool use; output formation; permission decisions; escalation; task-state continuity; and evaluation.

The context pack is not the model’s complete input on every turn. It may point to a current policy article; a saved query; a project folder; a CRM record; a source registry; an approved example library; or a task-state object.

The worker retrieves the relevant slice for the current task.

Anthropic’s context-engineering guide describes context as a finite resource and recommends curating high-signal information, including just-in-time retrieval through lightweight identifiers. That is the right design principle for a role pack: make the route to authoritative information clear without forcing every possible fact into active context.

Context is broader than a prompt

The worker’s effective context can include system and role instructions; tool descriptions; retrieved documents; database results; current task state; message history; memory; examples; approval records; tool output; and delegated work.

A strong system prompt cannot repair an unowned policy source, stale account record, overscoped retrieval, or malicious instruction hidden in a webpage.

Context is not memory

The pack defines approved sources and retrieval behavior. Memory is a lifecycle for information that persists across interactions.

Use the AI employee memory guide for working, episodic, semantic, and procedural continuity, plus provenance, correction, retention, and deletion. The context pack should state what may enter that lifecycle; it should not make every source permanent.

Context is not an SOP

The pack tells the worker which current sources, definitions, and examples govern the role. An SOP tells it how to perform a repeatable procedure.

The AI employee SOP guide covers testable steps, decisions, evidence, exceptions, and completion. Store approved SOP references in the pack rather than pasting several overlapping procedures into the role instructions.

§ 03Start With Ownership and Authority

Before collecting files, assign owners.

One person may cover several responsibilities in a small team. Do not leave the fields ownerless.

NIST’s AI RMF Core calls for documented roles, responsibilities, risk communication, context mapping, measurement, and sufficient documentation for relevant actors to make decisions. A context pack makes those responsibilities concrete at the information boundary.

Define six authority levels

Label every source:

The level should apply to a defined purpose and field. A CRM may be authoritative for account ownership but not for current legal terms. An official webpage may be authoritative for the company’s public statement but not proof that the claim is independently true.

Write precedence rules

Use explicit conflict behavior:

1. Compare source purpose, field, scope, authority, version, and observed time.
2. Prefer the higher-authority source only when it covers the same decision.
3. Preserve both values and provenance.
4. Do not invent a reconciliation.
5. Escalate when the conflict affects the outcome or action.
6. Record the authorized decision and whether the source register must change.

“Use the latest source” is unsafe when the newest document is an unapproved draft.

Treat retrieval as a permission

Technical access does not mean every record should enter context. Define the identity; source; object or field; purpose; task subtype; sensitivity; allowed retrieval operation; duration; evidence; retention; and deletion.

The AI employee permissions model applies to reads as well as writes. Minimum context begins with minimum data access.

§ 04Build the Context Pack Manifest

Create one machine-readable and human-readable manifest.

The manifest prevents a “folder full of context” from becoming the unit of control.

Use stable component IDs

Examples: role-contract/research-analyst/v3 · policy/public-claims/v7 · schema/weekly-change-brief/v2 · source-registry/competitors/v12 · examples/materiality/v4 · state/research-queue/v1.

Identifiers help a task record state which context governed it. A file name such as final_v2_revised.pdf does not.

Store metadata beside content

Each component needs an ID; title; type; authority; purpose; owner; scope; sensitivity; version; effective date; freshness or expiry; retrieval location; conflict rule; retention; deletion method; and related evaluation cases.

The metadata may live in a registry rather than the document itself, but the worker and reviewer must be able to recover it.

Load only the starter set

The default starter set usually includes the current role summary; priority and non-goals; the source hierarchy; the current task and state; the relevant output schema; a tool and authority summary; the escalation map; and stable references to deeper sources.

Retrieve policies, records, examples, and historical evidence when the task needs them.

Define the context assembly policy

The pack should tell the runtime what to assemble for a task. Use a sequence:

1. Load the current role and permission summary.
2. Load the assigned task and durable state.
3. Identify the task subtype and accepted output schema.
4. Retrieve the governing policy for that subtype.
5. Retrieve only the necessary system-of-record fields.
6. Retrieve approved evidence and examples when relevant.
7. Label untrusted input and keep it below governing sources.
8. Check freshness, scope, and conflict.
9. Exclude or redact prohibited data.
10. Record which sources and versions influenced the output or action.

Map the policy by work stage:

This policy can be implemented through retrieval rules, queries, access controls, tool design, and runtime checks. Do not rely on the worker to infer what “relevant” means from a broad search.

Apply a purpose and sensitivity filter

Before retrieval, ask: Is the information necessary for this task? Is the role allowed to use it for this purpose? Does the task need the whole document, one section, or named fields? Does the content include personal, confidential, regulated, or credential data? May it enter model context? May it be retained after the task? May it cross a role, project, user, customer, or tenant boundary? Must an owner approve this retrieval?

Use a simple inclusion decision:

OpenAI Academy’s current agent requirements document template pairs role-specific product and policy context with explicit human review when source data is missing, stale, or contradictory. Use that pattern in the pack: context availability never eliminates an escalation boundary.

Cap context by signal, not file count

Set practical budgets for default role instructions; current task state; retrieved policy; system-record fields; evidence; examples; history; and tool results.

The exact limits depend on the model, task, and consequence. Document the chosen budget and review it after representative cases. The important behavior is predictable curation: prefer current, authoritative sources; remove duplicate passages; retain provenance; summarize only when the summary can link back to evidence; refresh facts near consequential action; keep untrusted content visibly separated; and discard material that no longer helps the current decision.

If the task needs a large corpus, use retrieval and staged analysis. Do not make the worker reason over the whole corpus plus every prior conversation on every run.

§ 05Include the Role Contract and Decision Boundaries

The context pack should reference the approved AI employee job description, not reconstruct it from a chat.

Include or reference the mission; accepted unit; queue; triggers; priorities; responsibilities; non-goals; sources; tools; permissions; approvals; the deliverable; the acceptance rubric; escalation; handover; and pause/retirement rules.

Create a one-page role card

The role card helps the worker orient. It does not replace the complete job description or enforce technical access.

Define decision tables

For recurring judgment, provide an anchored table:

Use deterministic controls for exact thresholds and prohibited actions when possible. A table helps interpretation; it should not become the authorization system.

§ 06Create a Source Register

The source register is the core of the pack.

Define source-entry rules

For each source, answer:

1. What question may it answer?
2. Which fields or decisions does it govern?
3. Who owns its correctness?
4. How is the current version identified?
5. When is it stale?
6. Which roles may retrieve it?
7. Which content must be filtered or redacted?
8. What happens when retrieval fails?
9. What happens when another source disagrees?
10. What may be retained from it?

Prefer references for large and changing systems

Do not copy the entire CRM, ticket archive, or policy library into the pack. Store the system and query; allowed objects and fields; the retrieval purpose; the current owner; freshness behavior; and task-time validation.

This keeps the source current and reduces oversharing.

Mark untrusted content

Incoming messages, web pages, attachments, and delegated artifacts may be necessary evidence. They may also contain malicious or irrelevant instructions.

Microsoft’s agentic-memory safety guidance recommends gating persistent writes on intent and provenance, enforcing isolation, treating retrieval as a risk decision, and logging the memory lifecycle. Apply the same discipline before untrusted material enters active context.

Untrusted content must not override the role; expand permission; approve an action; change source precedence; write itself into durable memory; disclose data from another context; or suppress escalation.

§ 07Add Schemas, Examples, and Boundary Cases

Schemas make missing context visible.

For a research brief: the task ID; reporting period; monitored set; source and observed time; the prior record; the detected change; materiality; uncertainty; the calculation; unresolved conflicts; proposed follow-up; the reviewer; the state; and the next wake.

Include three example types

Examples are demonstrations, not universal truth. State which parts may be copied: structure; tone; evidence form; decision pattern; or boundary behavior.

Do not copy dated facts, identifiers, recipients, approvals, or exceptions into a new task.

Build a boundary library

Include a missing required field; a source outside scope; stale policy; conflicting systems; an unsupported factual claim; sensitive data; prompt injection; a prohibited action; an expired approval; a system outage; a duplicate task; a high-volume request; and a role-change request.

The boundary library should link to evaluation cases. A rule without a test can drift unnoticed.

Use existing documents carefully

OpenAI’s practical guide to building agents recommends using existing SOPs, support scripts, and policy documents to create clear routines, while defining explicit actions and edge cases.

Existing documents are raw material. Before adding one: confirm the owner; remove obsolete content; separate policy from explanation; resolve conflicting steps; identify missing exceptions; add a version and effective date; define retrieval scope; and test representative cases.

§ 08Preserve Task State and Open Work

The pack should define how context changes across work without becoming an uncontrolled diary.

Use explicit states: Received, In progress, Waiting on evidence, Awaiting approval, Completed, Accepted. Also define Blocked, Rejected, Duplicate, Expired, Canceled, and Incident.

The AI employee task-board guide covers queue and state design in detail. The context pack should reference the current state schema and the one task record being worked.

Create an open-work record

Separate durable state from narrative

“I was working on the report” is weak state.

Prefer: task research-024; Awaiting Approval; draft brief-v3; official source observed 2026-07-27; pricing unit conflict unresolved; decision requested from Research Lead; approval absent; no external action taken; next wake on decision or 2026-07-29 09:00.

The AI employee handover guide covers transfer and acceptance. The context pack defines which fields survive the shift.

Do not preserve hidden reasoning

Preserve evidence, decisions, assumptions, uncertainty, actions, and next state. Do not require private chain-of-thought.

A reviewer needs a concise rationale tied to sources and rules: the selected source; the applied criterion; the conclusion; confidence or uncertainty; the alternative considered when relevant; and the escalation.

§ 09Make Unknowns, Conflicts, and Freshness Visible

Create an unknowns register.

Unknowns are part of the context. Hiding them encourages invention.

Define freshness by decision

Freshness is not one global number.

Define the stale-source path

When a source is stale:

1. Do not silently use it as current.
2. Attempt the approved refresh.
3. Preserve the prior source and timestamp.
4. Mark the affected field unavailable or uncertain.
5. Escalate if the outcome or action depends on it.
6. Continue only unrelated work inside scope.

Plan retention and deletion

The AI memory privacy and retention guide covers the full governance checklist. In the context pack, record the purpose; data category; approved location; role and tenant boundary; minimum retention; maximum retention; the correction owner; the deletion method; legal/records holds; and propagation or derivative copies.

Do not retain a source merely because storage is available.

§ 10Test the Pack Before Live Use

Use the context pack with representative cases before the worker receives live authority.

Run seven context tests

Test pack subtraction

Remove one required component. The worker should identify what is missing; avoid unsupported completion; request the correct source; leave work in a safe state; and preserve a useful escalation packet.

This tests whether the system knows its context limits.

Test oversupply

Add irrelevant, stale, conflicting, and untrusted material. The worker should continue to select the correct source hierarchy.

Large-context capability is not the same as correct context selection.

Test retrieval failure

Simulate permission denied; a moved source; an empty result; a partial result; a timeout; a stale cache; the wrong tenant/project; malformed content; and an unavailable owner.

The worker should not convert a retrieval problem into a confident answer.

Score pack performance

Track correct-source selection; source completeness; provenance completeness; stale-source detection; conflict escalation; unsupported claims; overscoped retrieval; prohibited memory writes; cross-context leakage; reviewer correction; and task-state accuracy.

The pack passes when it supports the accepted outcome and boundary behavior across representative cases. It does not pass because every file was indexed.

§ 11Maintain the Pack as a Product

Assign a review cadence based on the role’s consequence and source change rate.

Use a change record

Record the component; prior and new version; the reason; the owner; the approver; affected roles/tasks; data and permission impact; evaluation cases rerun; the result; and the rollback.

Measure context health

Useful metrics include sources with a current owner; sources within their freshness rule; retrievals with provenance; conflicts resolved through the defined path; corrections completed; prohibited writes blocked; deletion requests completed; pack-caused failures; average context/retrieval cost; and time to repair a bad source.

Do not optimize retrieval volume. Optimize accepted outcomes and safe boundary behavior.

Review the smallest useful set

Remove duplicate policies; superseded examples; unused fields; irrelevant history; expired approvals; abandoned open-work notes; and information outside the role’s purpose.

The context pack should become clearer as the role matures.

§ 12Use the Context Pack in CellCog

CellCog’s public memory system guide describes persistent role and organization context through its memory system and Context Trees. Its AI Employees page describes roles, goals, KPIs, inboxes, task boards, schedules, wake conditions, permissions, approvals, shifts, and handovers.

Map the pack into those concepts:

Verify which role or organization can see each context item; how context is added, retrieved, corrected, and removed; whether source and version remain visible; how untrusted inputs are separated from governing instructions; how open tasks and approvals survive shifts; how context affects tool use; how a suspect item is quarantined; and how the role is paused or retired.

Do not copy all business information into a shared tree by default. Start with the narrow role pack, then add context only when representative cases demonstrate a need and the owner approves the boundary.