Context without oversharing

There is a real tension in agent work: more context usually produces better decisions, but more context also creates a larger surface for accidental disclosure, stale facts, and irrelevant detail. The answer is not to starve the agent or dump an entire working history into every prompt. It is to give each audience the minimum sufficient context for its job.

That means separating two questions that are often mixed together: what does the agent need to complete the work? and what can safely appear in the final artifact? The first can be narrow and private. The second must be deliberately public.

§1Choose the audience first

Context is not universally safe or unsafe. It is safe for a specific audience and purpose. A temporary task packet, a project rule file, and a public article have different readers, different lifetimes, and different disclosure limits.

A useful default is to treat every generated page, screenshot, report, preview, and copied prompt as potentially shareable. That changes the editing question from “is this secret?” to “does the reader need this?”

§2Sort context into four classes

Classification makes the decision mechanical. Each fact belongs to one of four classes:

The important distinction is between project-internal and secret. Internal context can often be transformed into a useful public method. A secret cannot. “We verify every consumer of a changed asset” preserves the lesson; the internal asset name and deployment history add nothing for a public reader.

§3Use minimum sufficient context

The strongest prompt is not the longest one. It is the smallest packet that lets the agent make the right decision without guessing. For most implementation work, that packet has five parts:

1. Outcome: the observable state that should be true when the work is done.
2. Scope: the files, routes, or surfaces the task may touch.
3. Constraints: the facts and behaviours that must not change.
4. Evidence: the checks that can prove the outcome.
5. Stops: the conditions that require a report instead of improvisation.

None of those require a client name, a private hostname, a personal contact, or a copied conversation. The agent needs the shape of the decision, not the identity of everyone involved.

§4Keep the logic; remove the identity

When useful knowledge comes from private work, transform it before publishing. Strip away the nouns that identify the project and preserve the verbs that explain the method.

turn a private working note into a public pattern

WORKING NOTE
Change <internal surface>, then verify <named consumers> and
the protected production response.

PUBLIC PATTERN
When a shared asset changes, inventory every consumer, rebuild,
verify the rendered output, and compare the deployed response.

The second version is not vague. It retains the sequence, the blast-radius rule, and the evidence requirement. It simply removes facts that do not help the public reader apply the method.

↑ contents

§5Write a public-safe task packet

A reusable task packet can be detailed without becoming identifying. It gives the agent authority and evidence while keeping private facts behind placeholders or source-of-truth references.

copy-usable public-safe packet

AUDIENCE
This output is public.

OUTCOME
Describe the observable result without naming a private project.

SCOPE
List only the allowed public files or generic surface types.

SOURCE OF TRUTH
Use the approved source supplied for this run. Do not restate
protected values in the output.

EXCLUSIONS
No names, contact details, credentials, local paths, private URLs,
private metrics, copied conversations, or unreleased plans.

EVIDENCE
Build, link check, responsive browser pass, and deployed preview.

STOP IF
The result requires an excluded fact or the source of truth conflicts.

The source can still contain the detail required for the task. The packet makes clear that the output must not reproduce it.

§6Separate the context layers

One giant context file eventually becomes contradictory and impossible to share safely. Use layers with clear ownership:

• Public rules: design language, generic build commands, accessibility standards, and public editorial principles.
• Private facts: protected values and internal operational truth, loaded only when the task requires them.
• Task packet: the temporary outcome, scope, evidence, and stop conditions for one run.
• Public artifact: the final page, report, or example after the disclosure pass.

Each fact should have one owner. Public rules should not duplicate changing private facts, and public artifacts should not become accidental storage for temporary operational context.

§7Run the disclosure gate

Before a public build or preview, scan both the source and the rendered result. Automated checks catch obvious patterns; a human review catches meaning.

The last question matters. A clean paragraph can sit beside revealing structured data, social metadata, filenames, or generated navigation. Review the whole artifact, not only the prose.

§8Avoid the two failure modes

Oversharing copies the whole working context into the output and hopes the reader ignores it. Over-redaction removes so much meaning that the lesson becomes “be careful” with no usable method.

The middle path is precise: publish the decision structure, the repeatable sequence, the constraints, and the evidence. Remove the identity, access details, protected values, and private history.