Follow one task from brief to handoff
Consider a release review for build B-17. Unit tests passed 42 of 42, the staging deployment succeeded, the required keyboard check has not run, and production is not authorized. A weak request—“review this and ship if it looks good”—blurs evidence, decision, and authority.
A useful brief asks for a release decision and a remaining-gates list. It names the CI record, staging record, and release policy in priority order. It permits inspection, blocks production, and says that missing required evidence means HOLD. The completion check is simple: every gate is labeled passed, failed, or unrun, and staging remains distinct from production.
Write the six decisions that govern the work
| Brief field | Question it answers | B-17 example |
|---|---|---|
| Outcome | What inspectable artifact or decision must exist? | Release decision plus remaining gates |
| Source of truth | Which evidence wins, and what happens when it is missing? | CI, staging record, then release policy; missing required evidence means HOLD |
| Deliverables | What separate outputs are expected? | One Markdown decision note; no deployment |
| Boundaries | Which actions are permitted or separately gated? | Read the records; production needs explicit approval |
| Budget and stop rules | When should the agent stop trying and return a useful partial result? | Use supplied files only; stop on a source conflict |
| Quality bar | Which failures matter enough to test? | Gate status complete; staging and production separate |
These fields make the task reviewable without turning the prompt into a policy manual. Stable organizational rules belong in project instructions or a Skill; the brief should carry the facts and decisions unique to this job.
Ask for a receipt before expensive work
A short brief receipt should restate the understood outcome, deliverables, source boundary, permissions, budget, stop conditions, and unresolved questions. It catches the costly misunderstandings early: a draft mistaken for a publication task, an old README treated as authoritative, or a staging check used as production proof.
Questions are helpful when an answer would change the deliverable, authority, or an irreversible action. Smaller gaps can be handled with a clearly stated assumption. This gives Astra room to proceed while keeping material uncertainty visible.
Put checkpoints where the risk changes
Most tasks need only three checkpoints. After discovery, report what was found and which sources are missing. Before a consequential action, show the exact target, effect, rollback, and approval. Before completion, list outputs, checks actually run, failed or skipped checks, and open decisions.
Applications remain responsible for their tools. An asynchronous function call still needs a stored call_id, external job state, and a later result. A WebSocket steering acknowledgement means the change is queued; a pending steer may require the application to return a function result or approval through a new continuation. The steering guide covers that lifecycle.
Change the brief without discarding good work
When a requirement changes, state the delta: what completed work remains valid, which future action should stop, the replacement requirement, the next safe step, and any cleanup or cancellation that still needs an owner. A steering event cannot retract text already shown or cancel a tool that has started, so tool and approval state must be reconciled separately.
For example, if the B-17 decision note should go to legal review instead of production, preserve the evidence and note, stop deployment, change the destination, save a local review draft next, and report whether any production action had already begun.
Use long context selectively
Astra's 1,050,000-token context can keep a large evidence set together, but relevance still matters. OpenAI's current pricing uses a higher long-context schedule once a prompt exceeds 272,000 input tokens, applied to the full request. Retrieval, a source register, or compaction may produce a cleaner and cheaper working set than sending an undifferentiated archive.
Prompt caching can help when many requests share a stable prefix. For GPT-5.6 and later, current documentation uses prompt_cache_options.ttl with 30m. Judge the result from cached-input, cache-write, latency, and accepted-output records for the real workload.
End with an evidence-based handoff
The closing note should name what was delivered, what was verified, what remains unverified, which decisions or approvals are still needed, and where the evidence lives. In the retained B-17 test of the earlier prompt version, Astra returned HOLD, preserved the unrun keyboard gate, and avoided a production claim. That one response-only case supports the boundary design, not a general reliability estimate.
The companion End-to-End Work Brief turns this method into copyable text. Its current v1.1 adds budget and stop rules and is structure-checked; the retained model run used v1.0.
