Context is assembled for work, not remembered in secret
An agent needs context to do useful work. That does not mean it should have an unlimited, invisible memory of every prior conversation. ScrumDo assembles context from the application records a person is already authorized to use: the card, accepted specification, selected customer stories, team interpretation, approved repository information, connector evidence, governance profile, and prior proof that still applies.
What belongs in a context snapshot
| Context layer | Typical contents | Boundary |
|---|---|---|
| Work record | Card, tasks, blockers, comments, accepted spec, and plan | Target card and authorized related work |
| Human meaning | Customer stories, signifiers, product-owner interpretation, and team judgment | Only the evidence visibility permits |
| Execution context | Repository ref, selected files, environment facts, and allowed skills | Pinned target and approved scope |
| Connector context | GitHub, Sentry, Slack, or other approved tool results | Allow-listed connector, resource, operation, and credential scope |
| Reusable context | An accepted convention, decision, or verified fact saved for later work | Named owner, provenance, review state, scope, and expiry |
| Governance context | Approvals, proof profile, limits, and exceptions | Version pinned to the run |
Provenance prevents convenient fiction
Every reusable fact needs an answer to five questions: where did it come from, who accepted it, where may it be used, when must it be reviewed, and how can it be revoked? Without those answers, a remembered statement can outlive the decision that made it true. A team renames an API, a customer policy changes, or an exception expires, yet the agent continues acting on yesterday as if it were permanent.
- Source links distinguish observed evidence from interpretation and policy.
- Scope prevents room context from silently becoming portfolio or organization context.
- Expiry forces volatile facts back through review.
- Revocation stops future use without deleting the historical explanation of prior runs.
- Run snapshots preserve what the agent actually received, even if the live source changes later.
Context minimization is a product feature
More context is not always better. Large, contradictory context can reduce relevance, expose data unnecessarily, increase provider cost, and make review harder. The system should favor the smallest sufficient context set, show omissions that may matter, and let a person add an approved source when the agent is blocked. Retrieval should follow the user and agent permissions already in force, then apply additional governance limits rather than bypassing them.
Provider retention is a separate question
Application-managed context controls what ScrumDo sends for the run. The AI provider may have its own data-use, retention, regional, and contractual settings. An Enterprise review must examine both layers. A precise statement is therefore: ScrumDo assembles and records the authorized context it sends; the customer remains responsible for choosing and configuring a provider appropriate to its obligations.
Key terms
- Context snapshot
- The versioned set of authorized material assembled for one agent run.
- Provenance
- The source, author, time, review state, and transformations that explain where a context item came from.
- Reusable context
- A deliberately saved fact, decision, or convention with a defined owner, scope, approval state, and expiry.
Sources and standards context
- NIST AI Risk Management Framework CoreNIST describes governance as a continuous, cross-cutting function and calls for documented human oversight, roles, testing, and accountability across the AI lifecycle.