Truth Before Intelligence

A long prompt can explain a task, but it cannot maintain a business, product, or life. Durable context has owners, locations, timestamps, permissions, and a way to be corrected. It survives the current conversation and can be inspected by the next worker.

The practical question is not how much context the model can hold. It is which facts the task requires, where those facts come from, and how the system knows they are still true.

Different truths change at different speeds. Identity and operating principles are durable. Project state changes daily. Runtime status can change in seconds. A useful truth layer separates those categories so a timeless principle does not get buried in a log, and a live outage is not treated like permanent doctrine.

That means distinguishing knowledge and memory from task state, runtime connections, and proof. The source may be a document, database row, repository, external service, or live health check. What matters is that the system knows which kind of truth it is reading.

Every consequential fact should answer two questions: where did this come from, and when was it last verified? Provenance lets a worker distinguish a primary source from a summary. Freshness prevents yesterday’s deployment status or organization chart from masquerading as current truth.

When a fact is cheap to recheck and likely to drift, recheck it. When verification is expensive, label the age and uncertainty. Honest uncertainty is a feature because it gives the user a real decision instead of false confidence.

Saving everything produces a landfill, not memory. The system needs rules for promotion, correction, and expiry. A transient detail can stay in a task. A repeated preference may become durable memory. A superseded decision should remain traceable but stop routing current work.

Good memory reduces repeated explanation while preserving the user’s ability to inspect and change what the system believes.

The most dangerous agent failure is often not a wild hallucination. It is a reasonable answer built from an old fact: the wrong branch, a renamed service, a former job title, an expired token, or a plan that was replaced last week.

Add source, verification time, and truth class to the task packet. When the decision depends on live state, make the live check part of the work rather than an optional afterthought.

More context is not automatically better context. Every model has a finite attention budget, and every irrelevant log, duplicate document, or stale decision competes with the instructions and evidence that matter. Context engineering is therefore a selection problem: assemble the smallest set of information that lets this worker make the next decision correctly.

The assembly pipeline should begin from the task, not from everything the system knows. Resolve the entities in the request. Retrieve candidate facts from the appropriate truth classes. Rank them by relevance, authority, and freshness. Remove duplicates and superseded records. Compress long material without erasing provenance. Finally, reserve space for tool observations and the worker’s output rather than filling the window before execution begins.

A good packet may include a durable operating rule, three current project facts, a handful of relevant files, the most recent failed receipt, and the acceptance criteria. It may deliberately exclude months of chat history. The measure is not how impressive the context bundle looks; it is whether the worker can identify the source, understand the current state, and act within the task boundary.

Knowledge, memory, task state, runtime state, and receipts answer different questions. Knowledge explains how something works. Memory records durable user preferences or prior decisions. Task state says what is expected now. Runtime state says what is connected or healthy at this moment. Receipts prove what actually occurred. Blending these planes creates subtle errors: a design document gets treated as deployed behavior, or a successful health check becomes proof that a feature meets its acceptance criteria.

Give each plane its own write policy and invalidation rule. A worker can propose durable memory, but the user or an explicit policy should approve promotion. Task events can update task state, but they should not rewrite doctrine. Runtime facts should expire quickly or be probed live. Receipts should be append-only evidence, even if a later receipt supersedes the conclusion.

The separation is operational, not philosophical. When a result is wrong, you can ask whether the system retrieved bad reference material, remembered an obsolete preference, misunderstood current task state, trusted stale runtime data, or accepted insufficient proof. Each diagnosis leads to a different repair.

A source URL is not enough. Consequential records need an assertion, truth class, scope, owner, effective time, observation time, confidence, provenance, and invalidation rule. For repository truth, include the checkout and revision. For external service truth, include the account and probe. For a decision, include the alternatives considered and what supersedes it.

Confidence should describe the evidence, not the model’s feeling. ‘Observed from the production endpoint five minutes ago’ is stronger than ‘mentioned in a planning note last month.’ A derived fact should retain links to its inputs. A summary should state whether it is lossless structured extraction or interpretive compression.

This metadata lets the control layer answer more responsibly. It can prefer the canonical repository map over a stray path in chat, request a fresh probe when runtime evidence is expired, and disclose when a useful memory is historical rather than current. Intelligence becomes safer because the system can reason about the quality of its own inputs.