03 / Operation
The OPERATION session
Get more from an agent with a precise brief, durable sources and a small review loop. More tokens or more Soots do not automatically improve the work.
01 · Replace “do it for me” with a testable brief
| Before | After |
|---|---|
| Write some great product posts | Three 120–180 word drafts from brand-guide URI/ID/revision; no publication |
| Fix the bad data | Read document ID/revision, identify discrepancies and propose a diff; no write yet |
| Deploy it properly | Plan source/image/state/secret refs, resources/cost and rollback; wait for review before apply |
Objective: [one measurable outcome].
Context: [audience, deadline, current facts].
Sources: [Data Pool URI/ID/current revision, or actual file/Skill filepath + reviewed Git commit/hash/version; precedence if sources conflict].
Allowed: [specific reads/effects]. Prohibited: [out-of-scope effects].
Output: [format + citations + uncertainties].
Acceptance: [checks and required evidence].
Ask/stop when: [sources, scopes, budget or outcome are unclear].Use the same conversation for the same objective to retain decisions and receipts. It stays bound to its selected Soot/runtime and conversation mode. An automatic chat can handle work in group A, then B, then A without starting over; group-native history, artifacts and memory remain scoped, while root aggregate memory stays chat-local. A new objective or coordinating Soot can warrant a new conversation. Existing pinned chats and app/client pins remain fixed; legacy ungrouped chats retain their old scope. Nest sidebar folders are cosmetic organization, not authorization.
For larger work, automatic scoped delegation lets one selected Soot use host-authorized group destinations through native AgentCore spawn_subagent. Nest, the current SDK chat session, widget and CLI automatically use group_id: auto when the host advertises groups.auto.v1 and the Soot has automatic_groups: true. There is no required group picker or editable teammate roster; ordinary answers need no delegation. A chat containing group results requires access to all contributing groups; revocation conservatively hides the mixed chat.
02 · The four Nest areas
Full labels are Overview / Conversations / Soots / Data Pool. Some builds shorten them to Home / Chat / Soot / Data; responsibilities stay the same.
| Area | Use it for | Boundary |
|---|---|---|
| Overview | Run states, queue/execution time, tokens, providers/models and tools | Passive monitoring; does not initiate work |
| Conversations | New-chat assignment, submit/continue, results and Stop | Selecting a management source does not move existing chats |
| Soots | Profile, mission, Pack, validate/save/activate, revision-pinned Test | Saved is not active; pending/mismatch blocks Test |
| Data Pool | Pools/documents/grants/activity in the contextual sidebar | Scoped to selected management runtime, without model calls |
| Settings | Configuration, providers and connections | Not data management or monitoring |
Before editing, inspect the intended runtime, endpoint and authenticated scope. Contextual sidebars follow the management runtime, not matching display names. Browser operator keys stay in page memory only; refresh needs reauthentication. Native Nest uses its private connection store. Public product frontends must not embed trusted backend/runtime keys. Disconnect does not stop server work.
03 · Persist sources, not giant repeated prompts
Repeated giant prompts become stale and hard to audit. Put reviewed SOPs in Skills; keep brand-guide in a durable source. Cite Data Pool URI/ID/current revision, or actual file/Skill filepath plus reviewed Git commit/hash/version, each run. A Skill explains when and how to work, not permission to acquire more tools. Instructions inside source content remain data, not authority.
After three repetitions, ask whether the SOP is stable. If so, write a Skill with good/bad examples, review it and explicitly select its capability. Add privileges only for a genuinely new need; separate read from write/publication. Successful drafts do not authorize publication.
04 · Improve with three fixed briefs
Keep one reviewed brand-guide version and these three briefs fixed. Use the same acceptance criteria: accurate facts, correct voice, citations, no invented claims, no writes or publication.
| Brief | Useful output to compare |
|---|---|
| Draft three 120–180 word introductory posts | Usable drafts, facts and voice consistent with the guide |
| Rewrite a 100-word support reply from the guide | Correct support window; no promises absent from the source |
| Flag unsupported claims in a supplied draft | Each claim tied to source evidence or clearly marked unsupported |
Run each as a fresh Test/new conversation under the same active configuration. Record useful output, number and nature of human corrections, queue/execution and review time, known tokens/cost, and any missing usage coverage. Unknown cost stays unknown. Do not invent scores or a response to fill the comparison.
Change ONE variable—mission wording, one Skill step, model, or effort—then save/activate where needed and repeat all three briefs on the same source and acceptance. If the source changes, establish a new baseline instead of attributing the difference to the model. Choose the smallest configuration that meets the job.
The host supplies model policy, turns, tokens, timeouts, tool limits and budget. Agree a small test budget; do not assume default ceilings. Make a Skill when a stable procedure repeats under the same responsibility: include when to use it, steps and good/bad examples. Add another Soot when there is a distinct ongoing responsibility or different permissions—for example, a reviewer separate from a draft writer—not merely to get three drafts faster.
Delegate only independent, useful subtasks within explicit limits and host permissions. Two writers editing the same document are not independent. The parent must collect child results; a job receipt alone is not completion. One Soot is enough for this exercise.
05 · Review evidence, not promises
Compare citations with source revisions, tool effects with receipts and output with acceptance. Inspect actual provider/model, errors/fallbacks and timings. Queue and execution are different. Known USD is an estimate for priced observations; null/partial/unpriced remains unknown, not zero. Closed UTC-hour totals may exclude a fresh run even when its detail is visible.
Removing a previous model from the host candidate chain can prevent an old conversation from continuing. New conversations use the new active policy; do not erase durable state to force a retry.
06 · Stop and uncertain outcomes
Stop persists before cancellation and fences new effects/publication, but does not undo completed actions. Losing a connection or leaving watch does not Stop the run. Keep original request/conversation/run IDs and receipts after an uncertain submission; inspect/watch that run, not a fresh POST.
soot watch --conversation <conversation-id> --run <run-uuidv7>Replace placeholders with IDs actually returned by the runtime. Watch observes through the saved scoped connection; it neither submits nor reads the database. Ctrl-C/timeout exits observation only. An uncertain external effect needs operator inspection of the original receipt and destination before a new intention; retry is not rollback. Resource fences use the actual resource identity across groups: never replay an uncertain effect through another group.
07 · A daily operating ritual
- Start: intended runtime, active revision and current source?
- Brief: one outcome, scope, acceptance and stop criteria.
- Review: citations, effects, denied scopes and usage coverage.
- Improve one thing: source, Skill/SOP or a bounded model/effort experiment.
- Close: distinguish completed/blocked/unknown; back up state using the host runbook if required.
08 · Today's work, a sample brief
Today: prepare three introductory drafts for fictional Pebble Studio.
Read the TEST brand-guide urn:example:brand-guide, ID brand-guide,
and use the current revision returned by the service.
Audience: first-time readers. Deadline: today's review session.
Use calm, plain, helpful language. Label the 24-hour support window TEST DATA.
Return three 120–180 word drafts with citations and unsupported claims.
Do not change the guide, publish or promise real Soot support terms.
I will choose one draft and record edits and review time before the next Test.This is an input to try, not a claim that a model already ran it. For real work, replace the test source with your approved guide and acceptance criteria.
Content reviewed: 2026-10-09