Design interaction behavior
Interaction behavior defines how the assistant moves from one turn to the next. It determines when the assistant asks, answers, or declines.
When interaction behavior is explicit, responses stay predictable across chat, in-flow, and single-shot surfaces.
Interaction contract
Define one contract for each task pattern. The contract should cover trigger, response path, and stop conditions.
| Situation | Expected behavior |
|---|---|
| Input is complete and in scope | Execute the task pattern and return the contracted output format. |
| Input is missing required data | State what is missing and ask for the minimum detail needed. |
| Request is ambiguous | Name the ambiguity and ask one clarifying question. |
| Request is out of scope | State the boundary and offer one supported next step. |
| Capability is unavailable | State the limitation directly and provide the best available path forward. |
Use one instruction per line where possible. This keeps the contract readable and testable.
Clarification strategy
Clarification behavior should reduce friction, not create loops.
- Ask one clarifying question at a time.
- Ask only for information required to complete the next step.
- If multiple fields are missing, request the minimum set that unblocks execution.
- If clarification is not available on the surface, state what is missing in the output.
Avoid broad clarification prompts like “Can you provide more context?” when you can ask for one specific field.
Turn progression
Design turn progression so each response either advances the task or closes it cleanly.
- Start by confirming the action you are taking.
- Show progress updates only when the task is long-running or multi-step.
- Use direct, task-relevant completion language.
- End with one clear next step when additional action is required.
Do not add decorative openings or closers that do not move the task forward.
Role-mode interaction posture
Interaction wording should match the role mode you selected.
| Role mode | Interaction posture |
|---|---|
| Digital Worker | Conversational and collaborative. Gentle nudges. First-person status only when clarifying active work state. |
| Assistive | Minimal social overhead. Terse progress updates. Utility-forward language with little conversational framing. |
Keep both modes explicitly digital. Avoid roleplay and anthropomorphic framing.
Repair behavior
Design explicit repair moves so trust does not collapse after a failure.
- If uncertain, state uncertainty and label assumptions.
- If a response is wrong, acknowledge it briefly, correct it, and continue.
- If a boundary prevents completion, state the boundary and give one concrete next step.
Review pass
Before shipping interaction behavior, confirm:
- Each turn path covers trigger, response, and stop conditions.
- Clarification behavior asks one concrete question when needed.
- Out-of-scope and unavailable-capability behavior is explicit.
- Turn progression language advances the task or closes it cleanly.
- Interaction posture matches the selected role mode.
Source documents
- https://github.com/x3-design/language-system/blob/main/plugins/content-foundations/knowledge/content-engineering/prompt-style.md
- https://github.com/x3-design/language-system/blob/main/plugins/content-foundations/knowledge/content-engineering/system-prompt-structure.md
- https://github.com/x3-design/language-system/blob/main/plugins/content-foundations/knowledge/content-engineering/personality-principles.md
- https://github.com/x3-design/language-system/blob/main/plugins/content-foundations/knowledge/content-engineering/personality-template-assistive.md
- https://github.com/x3-design/language-system/blob/main/plugins/content-foundations/knowledge/content-engineering/personality-template-digital-worker.md
This page adapts interaction guidance from these source documents for Fluent content-engineering workflows.