Advanced
How the agent partnership works
A deeper look at how you set intent, your assistant takes initiative, and ContextStream supplies scoped evidence, guardrails, and continuity.
ContextStream is built around a three-part working relationship: you set the goal and the boundaries, your assistant decides how to pursue it, and ContextStream supplies the project context that makes those decisions informed.
You should not have to narrate the retrieval choreography every time: “search the code now,” “read last week's session,” “check our lessons,” “find the runbook,” “look at the open plan.” State the outcome and the constraints. A properly configured assistant can choose the relevant evidence and continue through permitted work without waiting for you to name every lookup.
“fix the sign-outs after sleep, preserve the public auth API, and stop before deployment”
A scoped investigation that can retrieve current code, auth decisions, matching lessons, prior attempts, and verification requirements before proposing or making permitted changes.
“continue the billing migration and finish the next safe step”
The saved plan, open task, last stopping point, failed check, and current project evidence—not a request for you to replay yesterday.
“prepare the signing-key rotation for review”
The decision, runbook, dependency evidence, ordered plan, risks, and stop conditions assembled around one outcome.
What autonomy means here
Autonomy means initiative inside an authorized task, not an assistant with unlimited authority.
Once you give it a goal, a connected assistant can decide that it needs to:
- confirm the active workspace and project;
- retrieve relevant decisions, lessons, preferences, runbooks, plans, and past sessions;
- choose code, repository, media, question, or dependency evidence based on what it is trying to learn;
- apply a matched workflow;
- work through an approved plan and keep its task state current;
- verify the result and preserve a useful stopping point or handoff.
ContextStream does not wake an assistant up, invent a goal, grant filesystem or deployment permission, send an external message, or turn a reminder into an executed job. The client you use controls what actions the assistant can take. ContextStream gives that assistant scoped context and durable working state so it can use the authority you already gave it more intelligently.
The three-part contract
You
You contribute the outcome, business intent, non-negotiable constraints, and authority for consequential actions. You should not have to silently decide every search, lookup, or intermediate step for the assistant.
Your assistant
Your assistant contributes interpretation, investigation, sequencing, permitted execution, verification, and a clear account of uncertainty. It should not invent new product goals, fill gaps with made-up facts, or assume permission it was not given.
ContextStream
ContextStream contributes project scope, indexed evidence, relevant history, standing guidance, active work, and durable continuity. It does not decide whether an irreversible or externally visible action is acceptable.
The user is still in charge. The difference is where your attention goes. You spend it on intent, tradeoffs, and review—not on reminding a fresh chat which repository it is in or which migration rule it learned last Tuesday.
The working loop
A well-grounded turn follows the same loop even when the visible task changes.
- Orient. Resolve the person, workspace, project, account boundary, and folder. If two projects are plausible, stop and ask instead of filing knowledge in the wrong one.
- Ground. Bring forward the records relevant to this request: recent work, current decisions, matching lessons, preferences, instructions, active plans, and reusable workflows.
- Investigate. Choose the evidence that answers the actual question. Source answers where. Decisions answer why. A runbook answers how to operate. A plan answers what remains. Media and repository history supply evidence that is not in the checkout.
- Act. Make only the changes the current client and permission policy allow. Use a reviewed plan for long or risky work, and keep each task's finish line visible.
- Verify. Run the checks the project requires. Compare the result with the acceptance criteria, current source, and any stop conditions. A confident explanation is not verification.
- Persist. Save only what should survive: a confirmed decision, a specific lesson, updated task state, a corrected runbook, a snapshot, or a handoff. Do not turn every passing sentence into permanent memory.
Managed setup writes this operating pattern into the supported assistant's instruction file. On clients with lifecycle hooks, ContextStream can also surface relevant warnings and unread prior work at the point where the assistant is about to act. On clients without those hooks, the generated instructions teach the assistant to run the same loop itself.
One outcome instead of fifteen instructions
Suppose people are signed out after a laptop wakes. You say:
Fix sign-outs after sleep. Preserve the public auth API, follow the current
retry policy, and stop before deployment. Show me the evidence and verification.A useful assistant–ContextStream partnership can do the following without you dictating each retrieval:
- Confirm that the checkout is bound to the intended application project.
- Retrieve the current retry decision, a lesson about a missing provider
429fixture, the previous session's clock-skew failure, and the active auth task. - Search for the refresh coordinator, the exact provider error, every legacy client use, and the affected callers. If a support screenshot or architecture recording is part of the evidence, search those too.
- Read the auth-change runbook and its stop conditions. Build or update a plan whose steps name the required tests and preserve the public API.
- Make only the permitted source and test changes. Stop before deployment because that boundary came from you.
- Run the focused unit tests and the required browser flow. Report a mismatch between code and an old decision instead of hiding it.
- Update completed tasks. If the investigation proves a new architectural choice, ask for confirmation before recording it as the current decision. If work stops, save the exact failing check and next safe step.
The assistant still reasons and can still be wrong. ContextStream improves the evidence, continuity, and guardrails available to that reasoning. The diff, citations, test output, plan state, and stop conditions remain inspectable.
Build the operating context once
Different records teach the partnership different things. Use the narrowest shape that matches what you want to happen later.
| Capture once | What it changes later |
|---|---|
| Project instruction | Establishes a standing rule such as “never edit a shipped migration” for clients that load the file |
| Preference or constraint | Quietly shapes relevant work without becoming a procedure |
| Decision | Answers why the project chose one path and what it replaced |
| Lesson | Interrupts matching work with a specific prevention before the mistake repeats |
| Runbook | Gives an operator prerequisites, ordered steps, checks, rollback, and a stopping point |
| Skill | Applies a tested workflow when the task and trigger match |
| Plan and linked tasks | Gives a fresh session executable next work, acceptance criteria, and progress |
| Snapshot | Preserves the real stopping point when a session or context window ends |
| Handoff | Transfers bounded responsibility, open questions, evidence, and a finish line |
This is how the system improves without requiring a larger prompt. You teach a rule, decision, or workflow when it becomes real. ContextStream keeps it in the right project shape. The assistant can retrieve or apply it when later work matches.
Increase autonomy in stages
Do not jump from an empty project to “handle everything.” Give the partnership enough operating context for the amount of independence you expect.
Grounded answer
The assistant can find and join evidence for a project question. Start with an indexed project and confirmed scope.
Bounded investigation
The assistant can choose what to search, inspect relevant history, and report a cause or evidence gap. Give it a clear question, plus the decisions and lessons that should shape the investigation.
Reviewed execution
The assistant can carry out an approved multi-step change and verify it. Put a plan, acceptance criteria, appropriate permissions, and explicit stop conditions in place first.
Repeatable workflow
The assistant can apply the same preflight or procedure when matching work appears. Base that initiative on a tested skill linked to current runbooks and constraints.
Transfer and resume
The assistant can continue across sessions, assistants, or machines. Keep tasks, snapshots, handoffs, and the shared context intentionally scoped and current.
More context is not always better. A narrow current runbook is safer than five contradictory documents. A specific lesson is more useful than “be careful.” An acceptance criterion is more useful than a long plan with no finish line.
Safe initiative includes stopping
An assistant working well on its own should know when not to continue.
It should stop or ask when:
- the workspace or project is ambiguous;
- current code conflicts with the recorded decision or runbook;
- a required fact, capability, credential, or test environment is missing;
- the next action is destructive, irreversible, externally visible, or outside its permission policy;
- a runbook's escalation or rollback condition is met;
- the requested outcome requires a product or security judgment the user has not made.
That is not a failure of autonomy. It is the difference between bounded initiative and guessing with side effects.
Why this is not one giant prompt
A giant prompt goes stale, consumes the context window whether relevant or not, and gives every instruction the same weight. ContextStream keeps source, history, operating procedures, active work, and warnings as separate records. The assistant can retrieve the subset relevant to the current task, inspect freshness, and follow links back to the authority.
It also survives the assistant. You can change editors, open a clean session, move to another machine, or hand the work to another authorized agent without making one provider's chat history the only copy of what the project knows.
If it doesn't work
The assistant waits for retrieval instructions every time. Its managed instruction file is missing, stale, or not loaded by the client. Regenerate it, restart the editor, and ask the assistant which project it resolved.
It takes initiative in the wrong project. Repair the folder binding and confirm account mode, workspace, and project before any durable write. More autonomy cannot repair ambiguous scope.
It applies an old rule. Supersede the decision, retire the skill, or update the runbook that is no longer current. Durable context must be maintained.
It acts beyond the boundary you expected. Tighten the client's permission policy and make the stop condition explicit in the task, plan, runbook, or skill. ContextStream context does not replace execution permissions.
It keeps asking questions the project already answered. Check that the answer exists in the right shape and project. A passing chat comment may never have become a decision, lesson, document, or captured exchange.