Opening messages are ambient templates selected by situation
Task details, handoffs and conversation instructions were assembled in code even though ambient skills were editable templates. Organizations could customize some guidance but could not replace the context or wording surrounding it. Opening messages now combine the rendered role instruction with the rendered ambient skills. Six global built-in copies provide the existing opening content, one for each task, human conversation or agent conversation, starting or resuming.
opening.kind names exactly one of these situations. A skill can guard its entire body with
{{#if (eq opening.kind "task-start")}} and contribute nothing elsewhere. An empty or whitespace-only
result is omitted before its heading or attachment hint is assembled. The choice uses the runtime's
actual session result, including fallback to a new session, rather than guessing from a stored ID.
Considered Options
- Template every incoming event: deferred. Version one covers openings; notifications injected during an active run keep their existing format, data windows and delivery cursors.
- New skill applicability metadata: deferred. A top-level guard gives authors one situation to understand, using the existing skill editor, revisions and strict validation. The documented discriminator leaves room for a future editor without requiring another dispatch mechanism now.
- Preformatted context blocks: rejected. They would retain fixed wording within values that an organization could only include or exclude. The added context exposes structured facts instead.
Consequences
- The template contract is additive. Basic
task,conversation, organization and role fields stay available;openingadds the situation, preceding stop reason and subject-specific facts. Save-time samples cover all six situations with empty and populated facts. Optional fields still need guards. - Role instructions and ambient skills render for resumed openings too. Existing custom skills are
preserved and may therefore repeat their guidance; authors can restrict them with
opening.kind. The six copies can be edited, disabled or removed independently through normal skill management. - Task facts retain their unseen window; human messages retain the recent-message cap. Agent messages keep their existing batch limits and cursor behavior. Agent conversations expose only selected local origin metadata and selected peer identifiers, never a connection row, credential or human transcript. Neither human nor task authority is inherited from that origin; both root contexts stay null there.
- Only explicit authorized sends transfer text to another role or human conversation. Delivery, authorization, scheduling and escalation remain enforced by the server, regardless of template text.
- The new defaults also guard the presence of
openingvialookup. If the server binary is rolled back, these persisted copies contribute nothing and the previous hard-coded opening resumes. This does not undo edits or remove copies from the database. Custom templates using the new fields must also guard their presence if they need to run on an older server. Existing session history stays as previously delivered; a restart does not retract instructions already seen.
This supersedes the opening-format exceptions in ADRs 0008 and 0009. Triggered skills remain raw files in the role's shared home, and mid-run notifications remain fixed in version one.