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.

  1. 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.
  2. Ground. Bring forward the records relevant to this request: recent work, current decisions, matching lessons, preferences, instructions, active plans, and reusable workflows.
  3. 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.
  4. 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.
  5. 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.
  6. 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:

Code
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:

  1. Confirm that the checkout is bound to the intended application project.
  2. Retrieve the current retry decision, a lesson about a missing provider 429 fixture, the previous session's clock-skew failure, and the active auth task.
  3. 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.
  4. 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.
  5. Make only the permitted source and test changes. Stop before deployment because that boundary came from you.
  6. Run the focused unit tests and the required browser flow. Report a mismatch between code and an old decision instead of hiding it.
  7. 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 onceWhat it changes later
Project instructionEstablishes a standing rule such as “never edit a shipped migration” for clients that load the file
Preference or constraintQuietly shapes relevant work without becoming a procedure
DecisionAnswers why the project chose one path and what it replaced
LessonInterrupts matching work with a specific prevention before the mistake repeats
RunbookGives an operator prerequisites, ordered steps, checks, rollback, and a stopping point
SkillApplies a tested workflow when the task and trigger match
Plan and linked tasksGives a fresh session executable next work, acceptance criteria, and progress
SnapshotPreserves the real stopping point when a session or context window ends
HandoffTransfers 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.

Next