Context and ontology

Context is the set of facts available to one run. Ontology is the shared model that gives those facts meaning. They are related, but they are not interchangeable.

Context is assembled for a job

An agent should not receive every record in a workspace. A run receives the information its identity and scope allow, filtered by the request it is trying to answer. That keeps the response grounded, reduces noise and cost, and provides a meaningful boundary for access control.

Context can include resolved entities, related records, stored artifacts, source freshness, prior state, policies, and the outputs of earlier workflow steps. The trace should show which material was actually used.

Ontology is the business model

An ontology names the things your business uses and the relationships between them. It makes “customer,” “renewal,” “invoice,” or “critical incident” a versioned definition rather than a phrase every prompt interprets differently.

CopyAccount
  ├── has many → Invoices
  ├── is governed by → Contract
  ├── has many → Support cases
  └── is owned by → Team member

When a developer asks for accounts with a renewal risk, the ontology lets the system follow meaningful relationships instead of guessing at table names or joining arbitrary documents.

Why retrieval alone is insufficient

Retrieval can find text that mentions an account. It does not by itself establish whether two records describe the same account, which relationship is authoritative, whether the data is fresh, or which user may read it. Those are modelling, provenance, and permission problems.

Use retrieval as one way to obtain context. Use the ontology to make the context coherent and usable across systems.

Next: Agents.