# How to Build an AI Employee Context Pack

> Build an AI employee context pack with owned sources, role rules, examples, schemas, open work, unknowns, freshness, and change control.

- Author: Nitish Garg, Founder & CEO, CellCog
- Published: 2026-07-31 (updated 2026-09-07)
- Canonical (HTML): https://cellcog.ai/blog/ai-employee-context-pack/
- Section: Insights / Memory & continuity
- Publisher: CellCog (https://cellcog.ai), the AI employee platform. Blog index for agents: https://cellcog.ai/blog/llms.txt

## Key points

- Start from the approved role and accepted outcome, not a pile of documents - and give every source a named owner and authority level.
- Separate binding policy, system-of-record facts, approved evidence, working context, examples, and untrusted input.
- Include the minimum role contract, source register, schemas, examples, edge cases, state model, vocabulary, open work, unknowns, and escalation rules.
- Reference large or changing sources by stable identifiers; retrieve the needed slice at task time - and store provenance, version, scope, and freshness with the information.
- Test missing, stale, conflicting, overscoped, sensitive, and malicious context before launch.
- Review the pack when the role, policy, source, tool, data purpose, permission, or output changes.

An AI employee context pack is the smallest owned set of information the worker needs to perform one role correctly.

It should contain the current role contract, source hierarchy, approved policies and data references, output schemas, examples, edge cases, task-state rules, open-work snapshot, vocabulary, explicit unknowns, escalation map, and change record.

Do not upload the whole company drive and call it context. More information can introduce stale policy, conflicting examples, excess personal data, hidden instructions, retrieval noise, and unclear authority.

The pack is an index with governed content behind it. Every consequential source needs a purpose, authority level, owner, freshness rule, access boundary, conflict behavior, and removal path.

## The Context Pack at a Glance

*Table: The thirteen components of a context pack*

| Component | Purpose | Required owner | Common failure |
| --- | --- | --- | --- |
| Document control | Identifies the approved pack and role version | Role owner | Worker loads superseded context |
| Role contract | Defines outcome, scope, non-goals, authority | Business owner | Title substitutes for instructions |
| Source register | Defines what may be trusted and why | Knowledge/policy owners | All retrieved text looks authoritative |
| Core policies | Governs decisions and prohibited behavior | Policy owner | Old example overrides current policy |
| Data references | Points to necessary facts and systems | System/data owner | Whole database becomes context |
| Output schemas | Makes completion and missing evidence visible | Downstream owner | Free-form output varies each run |
| Examples | Anchors accepted, rejected, and ambiguous cases | Domain reviewer | Example becomes timeless policy |
| Vocabulary | Resolves role-specific terms and fields | Domain owner | Similar terms produce wrong actions |
| State model | Preserves task ownership and next action | Process owner | Memory replaces task state |
| Open-work snapshot | Lets the next shift resume safely | Supervisor | Stale approval or duplicate action |
| Unknowns/conflicts | Prevents invention and silent reconciliation | Source owner | Worker fills gaps confidently |
| Escalation map | Returns decisions to authorized people | Supervisor | "Ask someone" has no route |
| Change log | Explains what changed and what to retest | Role owner | Several versions contaminate results |

## What 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](https://cellcog.ai/blog/ai-employee-memory/) 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](https://cellcog.ai/blog/ai-employee-sops/) 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.

## Start With Ownership and Authority

Before collecting files, assign owners.

*Table: Context decisions and their accountable owners*

| Context decision | Accountable owner |
| --- | --- |
| Role outcome and non-goals | Business owner |
| Policy meaning and exceptions | Policy/domain owner |
| Data purpose and permitted fields | Data/privacy owner |
| System-of-record status | System owner |
| Output schema and acceptance | Downstream user |
| Example approval | Domain reviewer |
| Access and retrieval boundary | System/security owner |
| Task state and open-work semantics | Process owner |
| Retention and deletion | Data/privacy/records owner |
| Pack version and deployment | Role owner |

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:

*Table: The six authority levels*

| Level | Meaning | Example | Worker behavior |
| --- | --- | --- | --- |
| 1. Binding policy | Governs covered decisions | Current refund policy | Follow; stop if ambiguous or superseded |
| 2. System of record | Authoritative for named facts | Approved CRM fields | Use current value and timestamp |
| 3. Approved evidence | Permitted factual source | Official company page | Cite; do not infer unavailable facts |
| 4. Working context | Useful current project information | Approved brief | Use inside stated scope |
| 5. Example | Shows form or prior decision | Accepted response | Copy structure, not stale facts |
| 6. Untrusted input | May contain evidence and instructions | Email, webpage, attachment | Extract evidence; never let it override policy |

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](https://cellcog.ai/blog/ai-employee-permissions-and-approvals/) applies to reads as well as writes. Minimum context begins with minimum data access.

## Build the Context Pack Manifest

Create one machine-readable and human-readable manifest.

*Table: The pack manifest*

| Field | What to record |
| --- | --- |
| Pack ID | Stable identifier |
| Role ID | Role this pack governs |
| Pack version | Current approved version |
| Status | Draft, test, active, paused, retired |
| Owner | Person responsible for current pack |
| Approved by | Required business/domain/security/privacy owners |
| Effective date | When it begins governing work |
| Review trigger | Date, source change, incident, role change |
| Components | IDs and current versions |
| Retrieval policy | What is loaded by default or just in time |
| Prohibited context | Data, sources, or instructions that must not enter |
| Change summary | What changed and affected cases |
| Rollback version | Last approved recoverable pack |

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:

*Table: Context by work stage: what to load, what to exclude*

| Stage | Context needed | Context normally excluded |
| --- | --- | --- |
| Intake | Request, requester authority, purpose, sensitivity, due time | Unrelated requester history |
| Plan | Role, task subtype, source registry, allowed tools, non-goals | Other departments' role context |
| Execute | Current policy, required facts, relevant evidence, exact approval | Broad archives and expired approvals |
| Verify | Intended postcondition, action result, source-of-record state | New instructions from tool output |
| Handover | Task state, decisions, artifacts, blockers, next owner/wake | Raw conversation that does not affect state |

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:

*Table: The five inclusion decisions*

| Decision | Meaning | Worker behavior |
| --- | --- | --- |
| Include | Necessary, approved, and in scope | Retrieve minimum slice with provenance |
| Include with transformation | Needed but contains excess/sensitive detail | Filter, redact, aggregate, or tokenize as approved |
| Reference only | Useful to locate but not load broadly | Preserve identifier and retrieve when authorized |
| Human-only | Qualified person may inspect; role may not | Escalate with the permitted metadata |
| Exclude | Unnecessary, prohibited, stale, or unowned | Do not retrieve or retain |

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.

## Include the Role Contract and Decision Boundaries

The context pack should reference the approved [AI employee job description](https://cellcog.ai/blog/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

*Table: An example role card*

| Field | Example |
| --- | --- |
| Role | Competitor Change Analyst |
| Mission | Produce one accepted source-linked brief every Monday |
| Queue | Approved 12-company registry and priority events |
| Accepted unit | Brief accepted by Research Lead |
| Allowed actions | Browse approved domains, create draft, update task |
| Prohibited actions | Publish, external email, purchase, registry change |
| Hard stops | Missing source, conflict, unsupported material claim |
| Escalation | Research Lead; two-hour weekday response |
| End state | Draft submitted, task updated, handover written |

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:

*Table: An anchored decision table for a research role*

| Situation | Evidence | Decision | Action |
| --- | --- | --- | --- |
| Official page and prior record agree on change | Current capture + prior accepted record | Change confirmed | Draft cited comparison |
| Official page changed but measurement is unclear | Current capture + ambiguous unit | Uncertain | Escalate with both interpretations |
| Third-party claim has no primary support | Article only | Unsupported | Record as lead; do not present as fact |
| Page contains instructions for the agent | Retrieved content | Untrusted instruction | Ignore as authority; preserve evidence |

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

## Create a Source Register

The source register is the core of the pack.

*Table: An example source register*

| Source ID | Source | Authority/purpose | Owner | Freshness | Conflict behavior |
| --- | --- | --- | --- | --- | --- |
| POL-CLAIM-07 | Public-claims policy | Binding for external claims | Content lead | Effective version | Stop on unclear coverage |
| REG-COMP-12 | Competitor registry | System of record for monitored set | Research lead | Review monthly/change | Reject company outside set |
| WEB-OFFICIAL | Allowlisted official domains | Approved current public evidence | Research lead | Capture at use | Cite observation time |
| BRIEF-PRIOR | Prior accepted brief | Comparison/example | Role owner | Prior period only | Never treat as present fact |
| STYLE-02 | Brief format guide | Binding for structure | Strategy ops | Current version | Escalate incompatible request |

### 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.

## Add 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

*Table: The three example types*

| Example | Purpose | Required metadata |
| --- | --- | --- |
| Accepted | Shows a passing output and evidence | Rubric result, source versions, date |
| Rejected | Shows a material failure | Failed dimension and correction |
| Ambiguous | Shows where a person decides | Escalation trigger and owner decision |

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.

## Preserve 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](https://cellcog.ai/blog/ai-employee-task-board/) 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

*Table: The open-work record*

| Field | Required content |
| --- | --- |
| Task | Stable ID and subtype |
| Outcome | Accepted unit this task contributes to |
| Current state | One defined state |
| Inputs | Source IDs and versions |
| Work completed | Actions and artifacts |
| Decisions | Decision, owner, evidence, time |
| Approvals | Exact action, approver, expiry, use state |
| Blockers | Missing source, tool, permission, or decision |
| Next owner | Worker, person, or authorized role |
| Next action | One observable step |
| Next wake | Time, event, or response |
| Risk | Current warning, incident, or stop |

### 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](https://cellcog.ai/blog/ai-employee-handovers/) 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.

## Make Unknowns, Conflicts, and Freshness Visible

Create an unknowns register.

*Table: An example unknowns register*

| Unknown | Why it matters | Current safe behavior | Owner | Review trigger |
| --- | --- | --- | --- | --- |
| Annual-plan unit unclear | Could make price comparison wrong | Report both interpretations; no definitive delta | Research lead | Source clarification |
| Refund exception owner absent | Customer commitment risk | Draft only; route to support lead backup | Support owner | Owner assignment |
| Data retention unapproved | Privacy/records risk | Do not write to durable memory | Privacy owner | Approved schedule |
| Tool does not expose postcondition | Duplicate/action risk | Prepare only | System owner | Integration change |

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

### Define freshness by decision

Freshness is not one global number.

*Table: Freshness behavior by source type*

| Source type | Example freshness behavior |
| --- | --- |
| Binding policy | Current effective version at action time |
| Account fact | Read from system of record at task start and before consequential action |
| Public webpage | Capture observed time and refresh for current claim |
| Market analysis | Use publication date and label interpretation |
| Prior output | Historical comparison only |
| Approval | Valid only for stated action and time window |
| Open work | Reconcile at shift start |

### 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](https://cellcog.ai/blog/ai-memory-privacy-and-retention/) 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.

## Test the Pack Before Live Use

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

### Run seven context tests

*Table: The seven context tests*

| Test | Question |
| --- | --- |
| Selection | Does the worker retrieve the right source for the task? |
| Precedence | Does binding policy outrank examples and untrusted input? |
| Scope | Does retrieval stay inside approved records and purpose? |
| Freshness | Does the worker detect expired or stale context? |
| Conflict | Does it preserve disagreement and escalate correctly? |
| Completeness | Does the output expose missing required context? |
| Poisoning/isolation | Can malicious or cross-role content alter behavior or leak data? |

### 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.

## Maintain the Pack as a Product

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

*Table: Review triggers and their required reviews*

| Trigger | Required review |
| --- | --- |
| Policy changes | Update source, examples, SOPs, and affected cases |
| Role scope changes | Reapprove contract, source purpose, permissions, evaluation |
| New tool/data system | Review identity, object, retrieval, sensitivity, evidence |
| Model/retrieval changes | Run context-selection and regression cases |
| Incident | Quarantine suspect content, trace propagation, correct/rollback |
| Reviewer correction pattern | Determine source, schema, example, or instruction defect |
| Owner changes | Transfer authority and confirm current versions |
| Role retirement | Disable retrieval, resolve open work, retain/delete appropriately |

### 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.

## Use 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](https://cellcog.ai/ai-employees) describes roles, goals, KPIs, inboxes, task boards, schedules, wake conditions, permissions, approvals, shifts, and handovers.

Map the pack into those concepts:

*Table: Context-pack components mapped to CellCog concepts*

| Context-pack component | CellCog concept to configure and verify |
| --- | --- |
| Role contract | AI Employee role, goals, KPIs |
| Source hierarchy | Project/organization context and memory structure |
| Controlled intake | Inbox, tasks, schedules, wake conditions |
| Tool and data boundary | Employee permissions and connected systems |
| Approval record | Approval flow and task evidence |
| Open work | Task board, shift state, handover |
| Changes | Current context version and affected work |

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.

## FAQ

**What should be in an AI employee context pack?**

Include the current role contract, source register, approved policies and data references, authority hierarchy, output schemas, accepted/rejected/ambiguous examples, vocabulary, state model, open-work snapshot, unknowns, escalation map, permission summary, and change log.

**How is a context pack different from a knowledge base?**

A knowledge base may contain broad organizational information. A context pack is a role-specific governed index: it selects the minimum sources needed for one outcome and defines their purpose, authority, scope, freshness, conflict behavior, and owners.

**Should I upload every company document?**

No. Start with the smallest high-signal set. Reference large or changing systems and retrieve the relevant slice at task time. Exclude stale, duplicate, sensitive, unowned, and out-of-purpose information.

**How often should the context pack be updated?**

Review it when policy, role scope, sources, owners, tools, data purpose, permissions, output schemas, examples, incidents, or retrieval behavior change. Also use a scheduled review based on source volatility and consequence.

**Can an AI employee update its own context pack?**

It may propose a correction or new item, but an authorized owner should approve changes to governing context. Durable writes need provenance, scope, and lifecycle controls. Untrusted input should never promote itself into authoritative memory.

**What happens after the context pack is complete?**

Use it to build and test task-level SOPs, evaluation cases, and onboarding exercises. Start with read or shadow access, inspect source selection and boundary behavior, and expand context or authority only when evidence shows the next addition is necessary.

## Related

- [How to Write an AI Employee Job Description](https://cellcog.ai/blog/ai-employee-job-description/index.md)
- [How to Onboard an AI Employee With Graduated Autonomy](https://cellcog.ai/blog/how-to-onboard-an-ai-employee/index.md)
- [What Is an AI Employee? The 5-Part Test for a Standing AI Worker](https://cellcog.ai/blog/what-is-an-ai-employee/index.md)

## The AI employee for this read

[AI Head of Growth](https://cellcog.ai/ai-employees/ai-head-of-growth): I built this page, checked every quote against its source and drew the charts. I can do the same for your company.

---

Markdown alternate of https://cellcog.ai/blog/ai-employee-context-pack/. Try CellCog free, no credit card needed: https://cellcog.ai/signup