Context: from one chat to a whole org

This page explains how to move information up from a single conversation all the way to a signed pack that lands in every teammate's session. If you're new to context packs, read Memory & compaction first — that's the simpler system for facts that stay on your machine.

Every turn the model sees a stack of context. Some of it lives only for the next reply. Some persists across your sessions. Some is shared across your whole team or organization. This page is the one to read if you want to understand the full ladder — from "what the model remembered five minutes ago" up to "the policy our entire company injects into every agent" — and how to move information up that ladder deliberately.

The elevation ladder

Five rungs, each broader in scope and more durable than the last:

Rung	Lives	Lifetime	Visible to	Where it's authored
1. Working memory	The current session's recent messages	Until session ends	Just this session	Implicit — it's whatever you've typed
2. Compacted history	The session's summarized older turns	Until session ends	Just this session	Auto-written by Kenaz; user-editable
3. Long-term memory	Pinned Chunks on your local store	Forever (or until you delete)	Sessions matching the chunk's scope	Right-click in chat → Remember this
4. Personal context pack	A YAML+Markdown pack on your machine	Forever; portable across machines	Every session that pack scopes to	Hand-authored or promoted from memory
5. Team / org context pack	A signed pack distributed via the bundle system	Forever; everyone on the team gets it	Every session at every teammate that the pack scopes to	Authored by a team member, signed, published

Rungs 1 and 2 together are what most people mean by "the conversation." Rung 3 is the Memory view (Memory & compaction). Rungs 4 and 5 are context packs — the rest of this page.

Why two systems (memory + packs)?

They're shaped for different jobs.

• Memory is a retrieval system. You pin a fact ("our staging DB is at staging.db.example.com"). It gets embedded. The model pulls it back into context only when a future turn looks semantically related. Good for facts you might need; bad for things that should always be true.
• Context packs are an injection system. The pack defines content that goes into the system prompt of every matching session — no retrieval, no maybe. Good for "every session in this org should know our coding style and never use AWS regions outside us-east-2"; bad for facts that don't need to be present every single turn.

A healthy team workflow uses both: memory for the long tail of project trivia an individual contributor accumulates, packs for the constant truths that everyone needs every time.

Context packs — the format

A pack is a directory containing:

my-pack/
  pack.yaml             # metadata, layer designation, signature ref
  entries/
    guidance/
      coding-style.md   # injected as a system-prompt section
    glossary/
      terms.md
    explanation/
      architecture.md
  signatures/
    pack.sig            # detached signature envelope (for signed packs)

pack.yaml:

name: acme-engineering
version: 2026.05.04+rev3
layer: team           # personal | team | org
description: Engineering-wide conventions, glossary, and architectural guardrails.

# Optional: restrict to specific workflows or agent profiles.
# Empty = applies to every session.
access:
  required_roles: []         # checked against Fleet identity when signed in
  restricted_to_org: ""      # org slug, or empty for any
  restricted_to_team: ""     # team slug, or empty for any

Each entry is a Markdown file with YAML front-matter that names it and declares its kind and scope:

---
name: coding-style
kind: guidance          # glossary | explanation | skill | guidance
scope:
  workflows: ["code-gen", "review"]  # empty = any workflow
  agents: []                         # empty = any agent
---
Write Go in idiomatic style. Prefer table-driven tests. ...

Whatever you write in the body becomes part of the system prompt for matching sessions. The entry name is the key the merge engine uses for override decisions — entries with the same name across layers are deduplicated, with the higher-precedence layer winning.

The merge engine

When a session starts, Kenaz resolves all packs that match the session's scope and merges them in layer order:

org packs   (broadest, weakest — precedence 1)
  ↓ merged
team packs                (precedence 2)
  ↓ merged
personal packs  (narrowest, strongest — precedence 3)
  ↓
final injected context  ← system prompt

Higher precedence wins. That's how a personal entry ("call me by my first name") can shadow an org-wide tone guideline, as long as the two entries carry the same name field. Two entries with different names coexist — no conflict.

If two packs at the same layer both define an entry with the same name, Kenaz fails closed: the session shows a yellow banner "context conflict — resolve in Settings → Contexts" and the conflicting packs are skipped until the conflict is fixed. This is intentional — silent conflicts are how shared-context systems lie to people.

Distributing a pack to a team

Three flavors, in order of how official your team is about it:

A. Git (simplest)

Pack lives in a repo. Teammates clone it and point Kenaz at the directory:

Settings → Contexts → Sources → Add directory → ~/code/acme-context.

Kenaz watches the directory; pushes to the repo land in everyone's session injection on the next chat turn (with a small "context updated" toast).

Suitable for: a small team that already has good Git hygiene; no signing, no granular scoping by role beyond what's in the pack.yaml.

B. The bundle system (recommended for teams ≥ 5)

Kenaz packs are first-class Kenaz bundles — content-addressed archives signed by the publishing team. Bundles are how Kenaz already distributes provider profiles, slash commands, and custom MCP recipes; context packs reuse the same plumbing.

Author flow:

1. Organize your pack as a directory — a pack.yaml manifest plus the entry files under entries/<kind>/.
2. Mark it as a context bundle and list the maintainers' signing keys.
3. Sign it with your team's Ed25519 signing key, kept in the secret store on the publisher's machine.
4. Publish it to your team's bundle source — a registry endpoint you run, or the hosted Kameas Bundle Hub if you've opted in.

Subscriber flow:

1. Settings → Contexts → Sources → Add bundle subscription → paste the registry URL.
2. The first time a subscription is added, Kenaz prompts to trust the publisher's signing key. Approve it once.
3. New versions auto-pull (with a configurable update cadence) and get verified against the trusted key before they're applied. Failed verification → the session uses the previously-cached version, with a banner.

Bundles get you signing, content-addressed integrity (every snapshot has a hash; tampering is detectable), and a real audit trail of which version of the pack was active when a given turn happened.

C. Org-wide rollout

For full-organization packs (layer: org), the bundle approach is the same — but you'll typically also want:

• Mandatory subscription — managed via a small allowlist file at the org level that Kenaz reads at first launch. Once on the allowlist, the org pack can't be unsubscribed by individual users (only marked "acknowledged" so the session banner stops nagging).
• Versioned with a deprecation window — when you publish an org pack v2, v1 stays available for a configurable grace period so teams aren't broken by a single bad rollout.
• Audited globally — every change to the org pack writes an org_pack.published event to the audit log of every machine that picks it up. Useful evidence for compliance.

Suitable for: a security team that needs to land a "never run shell commands that touch prod-* buckets" rule across every engineer; a legal team distributing a privilege-marker pack so no agent generates content that should be attorney-client privileged.

Scoping (workflow / agent)

Individual entries declare which sessions they apply to via their front-matter scope block. All listed dimensions are AND'd; within a dimension, values are OR'd.

Field	What it matches
workflows	The active workflow class. Common values: chat, code-gen, review, agentic. Set per-session in the chat header.
agents	The named agent profile, if you've set one. Lets you scope entries to e.g. a customer-support agent without affecting a coding-assistant agent.

Empty arrays mean "any value matches." Omitting the scope block entirely means the entry applies to every session.

Practical examples:

• An entry scoped to workflows: ["code-gen", "review"] so it only ships during coding sessions, not open-ended chat.
• An entry scoped to agents: ["customer-support"] so it lights up for that agent profile and stays out of general sessions.

Promoting up the ladder

The whole point of having a ladder is being able to climb it deliberately.

Compacted history → long-term memory

In the Memory view, hover any line of a [Summary] card → Pin to memory. Pick a scope (session / project / global). The line becomes a Chunk and survives the session.

Long-term memory → personal context pack

When you notice you're pinning the same kind of fact over and over, that's a sign it should be present every turn (always injected) rather than retrieved on match. Move those chunks out of memory and into a personal context pack: create a pack directory with layer: personal in pack.yaml, copy the facts in as guidance entries, and add the directory in Settings → Contexts → Sources → Add directory.

Personal pack → team pack

Change layer: personal to layer: team in pack.yaml, then distribute the pack via Git or the bundle system (see below). Personal entries are always local; once you change the layer, publish to the team's shared source.

Team pack → org pack

Change layer: team to layer: org. Org packs are reserved for genuinely organization-wide truths (compliance rules, security posture, brand voice) where local override is mostly undesirable. Requires org-publish permission on the bundle registry.

Snapshots, replay, and "what was the model told?"

Every session takes a content-addressed context snapshot at start: a hash of the merged pack content, plus the version IDs of every pack that contributed. The snapshot ID is recorded in the audit log alongside the session, and lands on every prompt sent to the provider.

This means:

• You can answer "what context did the model see when it produced this response?" months later by looking at the audit log entry, finding the snapshot ID, and reconstructing that exact context from it.
• You can compare two snapshots — useful when a session that worked yesterday goes weird today.
• A breaking pack rollout is reversible: pin everyone to the previous snapshot ID until the new pack is fixed.

For compliance-heavy contexts (legal review, regulated industries), the snapshot is the load-bearing artifact — it proves what the model knew, signed by the publishing team's key, with an audit log entry timestamped by your local machine. Pair it with the audit log export and you have a tamper-evident record of every model decision and its surrounding context.

Privacy

What leaves your machine, by tier:

Layer / Rung	Goes to provider on every turn?	Synced anywhere?
Working memory (session messages)	Yes — that's the conversation	No
Compacted history	Yes — as part of the assembled prompt	No
Long-term memory chunks (when retrieved)	Yes — when a chunk's similarity threshold is met for the turn	No
Personal context pack	Yes — injected into the system prompt	No
Team / org context pack	Yes — injected into the system prompt	Yes — pulled from the bundle registry on update; identical across every subscriber

Packs themselves are visible to anyone subscribed. Don't put secrets in packs (API_KEY=…, customer data, etc.). The secret store is the right place for those; packs are for shared guidance.

Practical recipes

• A team coding-style pack — layer: team, no scope restriction (applies everywhere), entries cover naming conventions, error-handling patterns, framework preferences. Personal entries still override because personal has higher precedence than team.
• A compliance "do not" pack — layer: org, no scope restriction, entries list forbidden actions. Personal and team entries can add to this but cannot suppress an org-layer entry with the same name.
• A per-project architecture brief — layer: team, entry scope.workflows: ["code-gen"], body explains the architecture decisions a new contributor needs to know. Edit the pack and re-distribute when the architecture changes.
• A personal "voice" pack — layer: personal, entry scope.workflows: ["chat"], body sets your preferred tone and what topics you don't want unsolicited advice on. Stays on your machine; never shared.
• A regulated-industry signed pack — layer: org, signed by the compliance team, includes a signatures/pack.sig so every install verifies the pack's provenance before applying it.

Comparison cheat sheet

You want…	Use…
The model to remember a fact you might need later	Long-term memory (pin a chunk)
The model to always know something every turn	A context pack (auto-injected)
Just yourself to have it	Personal pack (layer: personal)
Your team to have it	Team pack (layer: team) via bundle
Everyone in the org to have it	Org pack (layer: org) via bundle, required: true
To roll back a bad change	Snapshot pinning
To prove what the model was told	Snapshot ID + audit log
To override a lower-layer entry	Higher-layer pack with the same entry name