@elizaos/agent 2.0.0-alpha.439 → 2.0.0-alpha.440

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@elizaos/agent",
3
- "version": "2.0.0-alpha.439",
3
+ "version": "2.0.0-alpha.440",
4
4
  "description": "Standalone elizaOS-based agent and backend server package.",
5
5
  "type": "module",
6
6
  "license": "MIT",
@@ -467,7 +467,7 @@
467
467
  "@elizaos/app-steward": "^0.0.0",
468
468
  "@elizaos/app-task-coordinator": "^0.0.0",
469
469
  "@elizaos/app-training": "^0.0.1",
470
- "@elizaos/core": "^2.0.0-alpha.439",
470
+ "@elizaos/core": "^2.0.0-alpha.440",
471
471
  "@elizaos/plugin-agent-orchestrator": "^0.6.2-alpha.0",
472
472
  "@elizaos/plugin-browser-bridge": "^0.1.0",
473
473
  "@elizaos/plugin-local-embedding": "^2.0.0-alpha.12",
@@ -476,8 +476,8 @@
476
476
  "@elizaos/plugin-solana": "^2.0.0-alpha.6",
477
477
  "@elizaos/plugin-sql": "^2.0.0-alpha.19",
478
478
  "@elizaos/plugin-wechat": "^0.1.0",
479
- "@elizaos/shared": "^2.0.0-alpha.439",
480
- "@elizaos/skills": "^2.0.0-alpha.439",
479
+ "@elizaos/shared": "^2.0.0-alpha.440",
480
+ "@elizaos/skills": "^2.0.0-alpha.440",
481
481
  "@hapi/boom": "^10.0.1",
482
482
  "@noble/curves": "^2.0.1",
483
483
  "@solana/web3.js": "^1.98.4",
@@ -131,7 +131,7 @@ export declare const coreActionsSpec: {
131
131
  readonly descriptionCompressed: "Reply with generated msg. Default when responding with no other action. Use first as ack, last as final response.";
132
132
  }, {
133
133
  readonly name: "IGNORE";
134
- readonly description: "Call this action if ignoring the user. If the user is aggressive, creepy or is finished with the conversation, use this action. Or, if both you and the user have already said goodbye, use this action instead of saying bye again. Use IGNORE any time the conversation has naturally ended. Do not use IGNORE if the user has engaged directly, or if something went wrong and you need to tell them. Only ignore if the user should be ignored.";
134
+ readonly description: "Call this action if ignoring the user. If the user is aggressive, creepy or is finished with the conversation, use this action. In group conversations, use IGNORE when the latest message is addressed to someone else and not to the agent. Or, if both you and the user have already said goodbye, use this action instead of saying bye again. Use IGNORE any time the conversation has naturally ended. Do not use IGNORE if the user has engaged directly, or if something went wrong and you need to tell them. Only ignore if the user should be ignored.";
135
135
  readonly similes: readonly ["STOP_TALKING", "STOP_CHATTING", "STOP_CONVERSATION"];
136
136
  readonly parameters: readonly [];
137
137
  readonly examples: readonly [readonly [{
@@ -205,7 +205,7 @@ export declare const coreActionsSpec: {
205
205
  readonly actions: readonly ["IGNORE"];
206
206
  };
207
207
  }]];
208
- readonly descriptionCompressed: "Ignore user. Use when aggressive, creepy, conversation ended, or both sides said goodbye. Don't use if user engaged directly or needs error info.";
208
+ readonly descriptionCompressed: "Ignore user. Use when aggressive, creepy, conversation ended, addressed to someone else in a group, or both sides said goodbye. Don't use if user engaged directly or needs error info.";
209
209
  }, {
210
210
  readonly name: "NONE";
211
211
  readonly description: "Respond but perform no additional action. This is the default if the agent is speaking and not doing anything additional.";
@@ -966,7 +966,7 @@ export declare const allActionsSpec: {
966
966
  readonly descriptionCompressed: "Reply with generated msg. Default when responding with no other action. Use first as ack, last as final response.";
967
967
  }, {
968
968
  readonly name: "IGNORE";
969
- readonly description: "Call this action if ignoring the user. If the user is aggressive, creepy or is finished with the conversation, use this action. Or, if both you and the user have already said goodbye, use this action instead of saying bye again. Use IGNORE any time the conversation has naturally ended. Do not use IGNORE if the user has engaged directly, or if something went wrong and you need to tell them. Only ignore if the user should be ignored.";
969
+ readonly description: "Call this action if ignoring the user. If the user is aggressive, creepy or is finished with the conversation, use this action. In group conversations, use IGNORE when the latest message is addressed to someone else and not to the agent. Or, if both you and the user have already said goodbye, use this action instead of saying bye again. Use IGNORE any time the conversation has naturally ended. Do not use IGNORE if the user has engaged directly, or if something went wrong and you need to tell them. Only ignore if the user should be ignored.";
970
970
  readonly similes: readonly ["STOP_TALKING", "STOP_CHATTING", "STOP_CONVERSATION"];
971
971
  readonly parameters: readonly [];
972
972
  readonly examples: readonly [readonly [{
@@ -1040,7 +1040,7 @@ export declare const allActionsSpec: {
1040
1040
  readonly actions: readonly ["IGNORE"];
1041
1041
  };
1042
1042
  }]];
1043
- readonly descriptionCompressed: "Ignore user. Use when aggressive, creepy, conversation ended, or both sides said goodbye. Don't use if user engaged directly or needs error info.";
1043
+ readonly descriptionCompressed: "Ignore user. Use when aggressive, creepy, conversation ended, addressed to someone else in a group, or both sides said goodbye. Don't use if user engaged directly or needs error info.";
1044
1044
  }, {
1045
1045
  readonly name: "NONE";
1046
1046
  readonly description: "Respond but perform no additional action. This is the default if the agent is speaking and not doing anything additional.";
@@ -82,7 +82,7 @@ export const coreActionsSpec = {
82
82
  },
83
83
  {
84
84
  name: "IGNORE",
85
- description: "Call this action if ignoring the user. If the user is aggressive, creepy or is finished with the conversation, use this action. Or, if both you and the user have already said goodbye, use this action instead of saying bye again. Use IGNORE any time the conversation has naturally ended. Do not use IGNORE if the user has engaged directly, or if something went wrong and you need to tell them. Only ignore if the user should be ignored.",
85
+ description: "Call this action if ignoring the user. If the user is aggressive, creepy or is finished with the conversation, use this action. In group conversations, use IGNORE when the latest message is addressed to someone else and not to the agent. Or, if both you and the user have already said goodbye, use this action instead of saying bye again. Use IGNORE any time the conversation has naturally ended. Do not use IGNORE if the user has engaged directly, or if something went wrong and you need to tell them. Only ignore if the user should be ignored.",
86
86
  similes: ["STOP_TALKING", "STOP_CHATTING", "STOP_CONVERSATION"],
87
87
  parameters: [],
88
88
  examples: [
@@ -180,7 +180,7 @@ export const coreActionsSpec = {
180
180
  },
181
181
  ],
182
182
  ],
183
- descriptionCompressed: "Ignore user. Use when aggressive, creepy, conversation ended, or both sides said goodbye. Don't use if user engaged directly or needs error info.",
183
+ descriptionCompressed: "Ignore user. Use when aggressive, creepy, conversation ended, addressed to someone else in a group, or both sides said goodbye. Don't use if user engaged directly or needs error info.",
184
184
  },
185
185
  {
186
186
  name: "NONE",
@@ -1299,7 +1299,7 @@ export const allActionsSpec = {
1299
1299
  },
1300
1300
  {
1301
1301
  name: "IGNORE",
1302
- description: "Call this action if ignoring the user. If the user is aggressive, creepy or is finished with the conversation, use this action. Or, if both you and the user have already said goodbye, use this action instead of saying bye again. Use IGNORE any time the conversation has naturally ended. Do not use IGNORE if the user has engaged directly, or if something went wrong and you need to tell them. Only ignore if the user should be ignored.",
1302
+ description: "Call this action if ignoring the user. If the user is aggressive, creepy or is finished with the conversation, use this action. In group conversations, use IGNORE when the latest message is addressed to someone else and not to the agent. Or, if both you and the user have already said goodbye, use this action instead of saying bye again. Use IGNORE any time the conversation has naturally ended. Do not use IGNORE if the user has engaged directly, or if something went wrong and you need to tell them. Only ignore if the user should be ignored.",
1303
1303
  similes: ["STOP_TALKING", "STOP_CHATTING", "STOP_CONVERSATION"],
1304
1304
  parameters: [],
1305
1305
  examples: [
@@ -1397,7 +1397,7 @@ export const allActionsSpec = {
1397
1397
  },
1398
1398
  ],
1399
1399
  ],
1400
- descriptionCompressed: "Ignore user. Use when aggressive, creepy, conversation ended, or both sides said goodbye. Don't use if user engaged directly or needs error info.",
1400
+ descriptionCompressed: "Ignore user. Use when aggressive, creepy, conversation ended, addressed to someone else in a group, or both sides said goodbye. Don't use if user engaged directly or needs error info.",
1401
1401
  },
1402
1402
  {
1403
1403
  name: "NONE",
@@ -35,8 +35,8 @@ export declare const longTermExtractionTemplate = "# Task: Extract Long-Term Mem
35
35
  export declare const LONG_TERM_EXTRACTION_TEMPLATE = "# Task: Extract Long-Term Memory (Strict Criteria)\n\nYou are analyzing a conversation to extract ONLY the most critical, persistent information about the user using cognitive science memory categories.\n\n# Recent Messages\n{{recentMessages}}\n\n# Current Long-Term Memories\n{{existingMemories}}\n\n# Memory Categories (Based on Cognitive Science)\n\n## 1. EPISODIC Memory\nPersonal experiences and specific events with temporal/spatial context.\n**Examples:**\n- \"User completed migration project from MongoDB to PostgreSQL in Q2 2024\"\n- \"User encountered authentication bug in production on March 15th\"\n- \"User had a negative experience with Docker networking in previous job\"\n\n**Requirements:**\n- Must include WHO did WHAT, WHEN/WHERE\n- Must be a specific, concrete event (not a pattern)\n- Must have significant impact or relevance to future work\n\n## 2. SEMANTIC Memory\nGeneral facts, concepts, knowledge, and established truths about the user.\n**Examples:**\n- \"User is a senior backend engineer with 8 years experience\"\n- \"User specializes in distributed systems and microservices architecture\"\n- \"User's primary programming language is TypeScript\"\n- \"User works at Acme Corp as technical lead\"\n\n**Requirements:**\n- Must be factual, timeless information\n- Must be explicitly stated or demonstrated conclusively\n- No speculation or inference from single instances\n- Core identity, expertise, or knowledge only\n\n## 3. PROCEDURAL Memory\nSkills, workflows, methodologies, and how-to knowledge.\n**Examples:**\n- \"User follows strict TDD workflow: write tests first, then implementation\"\n- \"User prefers git rebase over merge to maintain linear history\"\n- \"User's debugging process: check logs \u2192 reproduce locally \u2192 binary search\"\n- \"User always writes JSDoc comments before implementing functions\"\n\n**Requirements:**\n- Must describe HOW user does something\n- Must be a repeated, consistent pattern (seen 3+ times or explicitly stated as standard practice)\n- Must be a workflow, methodology, or skill application\n- Not one-off preferences\n\n# ULTRA-STRICT EXTRACTION CRITERIA\n\n## DO EXTRACT (Only These):\n\n**EPISODIC:**\n- Significant completed projects or milestones\n- Important bugs, incidents, or problems encountered\n- Major decisions made with lasting impact\n- Formative experiences that shape future work\n\n**SEMANTIC:**\n- Professional identity (role, title, company)\n- Core expertise and specializations (stated explicitly or demonstrated conclusively)\n- Primary languages, frameworks, or tools (not exploratory use)\n- Established facts about their work context\n\n**PROCEDURAL:**\n- Consistent workflows demonstrated 3+ times or explicitly stated\n- Standard practices user always follows\n- Methodology preferences with clear rationale\n- Debugging, testing, or development processes\n\n## NEVER EXTRACT:\n\n- **One-time requests or tasks** (e.g., \"can you generate an image\", \"help me debug this\")\n- **Casual conversations** without lasting significance\n- **Exploratory questions** (e.g., \"how does X work?\")\n- **Temporary context** (current bug, today's task)\n- **Preferences from single occurrence** (e.g., user asked for code once)\n- **Social pleasantries** (thank you, greetings)\n- **Testing or experimentation** (trying out a feature)\n- **Common patterns everyone has** (likes clear explanations)\n- **Situational information** (working on feature X today)\n- **Opinions without persistence** (single complaint, isolated praise)\n- **General knowledge** (not specific to user)\n\n# Quality Gates (ALL Must Pass)\n\n1. **Significance Test**: Will this matter in 3+ months?\n2. **Specificity Test**: Is this concrete and actionable?\n3. **Evidence Test**: Is there strong evidence (3+ instances OR explicit self-identification)?\n4. **Uniqueness Test**: Is this specific to THIS user (not generic)?\n5. **Confidence Test**: Confidence must be >= 0.85 (be VERY conservative)\n6. **Non-Redundancy Test**: Does this add NEW information not in existing memories?\n\n# Confidence Scoring (Be Conservative)\n\n- **0.95-1.0**: User explicitly stated as core identity/practice AND demonstrated multiple times\n- **0.85-0.94**: User explicitly stated OR consistently demonstrated 5+ times\n- **0.75-0.84**: Strong pattern (3-4 instances) with supporting context\n- **Below 0.75**: DO NOT EXTRACT (insufficient evidence)\n\n# Critical Instructions\n\n1. **Default to NOT extracting** - When in doubt, skip it\n2. **Require overwhelming evidence** - One or two mentions is NOT enough\n3. **Focus on what's PERSISTENT** - Not what's temporary or situational\n4. **Verify against existing memories** - Don't duplicate or contradict\n5. **Maximum 2-3 extractions per run** - Quality over quantity\n\n**If there are no qualifying facts (which is common), return no memories entries.**\n\n# Response Format\n\nmemories[0]:\n category: semantic\n content: User is a senior TypeScript developer with 8 years of backend experience\n confidence: 0.95\nmemories[1]:\n category: procedural\n content: User follows TDD workflow: writes tests before implementation, runs tests after each change\n confidence: 0.88\nmemories[2]:\n category: episodic\n content: User led database migration from MongoDB to PostgreSQL for payment system in Q2 2024\n confidence: 0.92";
36
36
  export declare const messageClassifierTemplate = "Analyze this user request and classify it for planning purposes:\n\n\"{{text}}\"\n\nClassify the request across these dimensions:\n\n1. COMPLEXITY LEVEL:\n- simple: Direct actions that don't require planning\n- medium: Multi-step tasks requiring coordination\n- complex: Strategic initiatives with multiple stakeholders\n- enterprise: Large-scale transformations with full complexity\n\n2. PLANNING TYPE:\n- direct_action: Single action, no planning needed\n- sequential_planning: Multiple steps in sequence\n- strategic_planning: Complex coordination with stakeholders\n\n3. REQUIRED CAPABILITIES:\n- List specific capabilities needed (analysis, communication, project_management, etc.)\n\n4. STAKEHOLDERS:\n- List types of people/groups involved\n\n5. CONSTRAINTS:\n- List limitations or requirements mentioned\n\n6. DEPENDENCIES:\n- List dependencies between tasks or external factors\n\nRespond in this exact format:\nCOMPLEXITY: [simple|medium|complex|enterprise]\nPLANNING: [direct_action|sequential_planning|strategic_planning]\nCAPABILITIES: [comma-separated list]\nSTAKEHOLDERS: [comma-separated list]\nCONSTRAINTS: [comma-separated list]\nDEPENDENCIES: [comma-separated list]\nCONFIDENCE: [0.0-1.0]";
37
37
  export declare const MESSAGE_CLASSIFIER_TEMPLATE = "Analyze this user request and classify it for planning purposes:\n\n\"{{text}}\"\n\nClassify the request across these dimensions:\n\n1. COMPLEXITY LEVEL:\n- simple: Direct actions that don't require planning\n- medium: Multi-step tasks requiring coordination\n- complex: Strategic initiatives with multiple stakeholders\n- enterprise: Large-scale transformations with full complexity\n\n2. PLANNING TYPE:\n- direct_action: Single action, no planning needed\n- sequential_planning: Multiple steps in sequence\n- strategic_planning: Complex coordination with stakeholders\n\n3. REQUIRED CAPABILITIES:\n- List specific capabilities needed (analysis, communication, project_management, etc.)\n\n4. STAKEHOLDERS:\n- List types of people/groups involved\n\n5. CONSTRAINTS:\n- List limitations or requirements mentioned\n\n6. DEPENDENCIES:\n- List dependencies between tasks or external factors\n\nRespond in this exact format:\nCOMPLEXITY: [simple|medium|complex|enterprise]\nPLANNING: [direct_action|sequential_planning|strategic_planning]\nCAPABILITIES: [comma-separated list]\nSTAKEHOLDERS: [comma-separated list]\nCONSTRAINTS: [comma-separated list]\nDEPENDENCIES: [comma-separated list]\nCONFIDENCE: [0.0-1.0]";
38
- export declare const messageHandlerTemplate = "task: Generate dialog and actions for {{agentName}}.\n\ncontext:\n{{providers}}\n\nrules[21]:\n- think briefly, then respond\n- always include a <thought> field, even for direct replies\n- actions execute in listed order\n- if replying without another grounded state/action query, REPLY goes first\n- REPLY means a direct chat reply in the current conversation only; it is not an email reply, inbox workflow, or external-channel send\n- set simple=true only when the planner's text should be sent directly as the final reply without running REPLY again\n- if actions are REPLY-only and you want the REPLY action to generate the final user-facing message, set simple=false\n- use IGNORE or STOP only by themselves\n- include providers only when needed\n- use only action and provider names that appear in the listed runtime surface; never invent new action names, provider names, benchmark ids, or paraphrased tool labels\n- when the user asks about uploaded files, documents, prior uploads, or knowledge-base contents, call the relevant providers before replying instead of asking the user to resend the material\n- when the user refers to \"the uploaded file\", \"the document I uploaded\", or a prior upload without naming it, treat that as a provider lookup request first; only ask which file after grounded document/knowledge lookup still leaves multiple plausible answers\n- use provider_hints from context when present instead of restating the same rules\n- if an action needs inputs, include them inside that action's <params> block\n- if a required param is unknown, ask for clarification in text\n- for live status questions or remaining-work queries, do not answer from recent conversation alone; call the relevant action/provider to refresh state, and do not pair it with a speculative REPLY that guesses the result\n- when an action will fetch the state and produce the final grounded answer, do not add REPLY just to say \"checking\", \"let me look\", or similar filler; use the action alone and leave text empty\n- when the user asks you to create, store, remember, schedule, remind, upload, follow up, route, escalate, or set a standing policy, choose the matching action instead of handling it in prose only\n- when the request names an external integration (Gmail, Discord, Slack, Telegram, GitHub, Google Sheets, Google Calendar, Google Drive, Notion, etc.) AND describes data movement between services or scheduled invocation of an external API, prefer CREATE_N8N_WORKFLOW; reserve CREATE_TRIGGER_TASK for self-driven scheduled prompts to the agent itself with no external API calls\n- for standing or future-condition requests like \"if/when X, do Y\", still choose the action that records, queues, or routes that behavior on the first turn\n- if a matching action can own the task and ask the missing follow-up itself, still select that action and put the clarification in text; do not reply in prose alone\n- when the user defines a durable preference, recurring block, escalation policy, upload policy, approval-gated workflow, or multi-device reminder rule, select the owning action even if some implementation details are still missing\n\t- do not wait for portal names, deck attachments, updated-id uploads, exact flight times, reservation ids, fee-risk item names, priority labels, event IDs, exact travel preferences, or the definition of \"important\" before selecting the owning action; let the action gather those details\n\t- future portal uploads, updated-id interventions, and cancellation-fee warning policies are operational workflows, not prose acknowledgements; choose LIFEOPS_COMPUTER_USE or PUBLISH_DEVICE_INTENT first and let those actions ask the missing follow-up\n\t- for LifeOps create requests with a clear defaultable habit or natural window, such as drinking water, stretch breaks during the day, weekday-after-lunch Invisalign checks, or brushing when waking up and before bed, call LIFE instead of asking for exact clock times unless the user explicitly asks for precise scheduling\n- only choose actions that directly satisfy the user's request or an explicit live-state question; do not opportunistically triage inboxes, summarize calendars, propose meetings, or call adjacent tools just because provider context makes them available\n- when the user is venting, reflecting, stating an opinion, or asking for generic advice about a domain, stay in REPLY or NONE unless they explicitly ask you to inspect state, change state, send something, schedule something, or perform a real operation\n\ncontrol_actions:\n- STOP means the task is done and the agent should end the run without executing more actions\n- STOP is a terminal control action even if it is not listed in available actions\n\nfields[5]{name,meaning}:\n- thought | short plan\n- actions | ordered <action> entries inside <actions>\n- providers | array of provider names, or empty\n- text | next message for {{agentName}}\n- simple | true only when text itself should be sent directly as the final reply; false when actions should run, including REPLY-driven finalization\n\nformatting:\n- wrap multi-line code in fenced code blocks\n- use inline backticks for short code identifiers\n\noutput:\nXML only. Return exactly one <response>...</response> document. No prose before or after it. No <think>.\n\nExample:\n<response>\n <thought>Reply briefly. No extra providers needed.</thought>\n <actions>\n <action>\n <name>REPLY</name>\n </action>\n </actions>\n <providers></providers>\n <text>Your message here</text>\n <simple>true</simple>\n</response>";
39
- export declare const MESSAGE_HANDLER_TEMPLATE = "task: Generate dialog and actions for {{agentName}}.\n\ncontext:\n{{providers}}\n\nrules[21]:\n- think briefly, then respond\n- always include a <thought> field, even for direct replies\n- actions execute in listed order\n- if replying without another grounded state/action query, REPLY goes first\n- REPLY means a direct chat reply in the current conversation only; it is not an email reply, inbox workflow, or external-channel send\n- set simple=true only when the planner's text should be sent directly as the final reply without running REPLY again\n- if actions are REPLY-only and you want the REPLY action to generate the final user-facing message, set simple=false\n- use IGNORE or STOP only by themselves\n- include providers only when needed\n- use only action and provider names that appear in the listed runtime surface; never invent new action names, provider names, benchmark ids, or paraphrased tool labels\n- when the user asks about uploaded files, documents, prior uploads, or knowledge-base contents, call the relevant providers before replying instead of asking the user to resend the material\n- when the user refers to \"the uploaded file\", \"the document I uploaded\", or a prior upload without naming it, treat that as a provider lookup request first; only ask which file after grounded document/knowledge lookup still leaves multiple plausible answers\n- use provider_hints from context when present instead of restating the same rules\n- if an action needs inputs, include them inside that action's <params> block\n- if a required param is unknown, ask for clarification in text\n- for live status questions or remaining-work queries, do not answer from recent conversation alone; call the relevant action/provider to refresh state, and do not pair it with a speculative REPLY that guesses the result\n- when an action will fetch the state and produce the final grounded answer, do not add REPLY just to say \"checking\", \"let me look\", or similar filler; use the action alone and leave text empty\n- when the user asks you to create, store, remember, schedule, remind, upload, follow up, route, escalate, or set a standing policy, choose the matching action instead of handling it in prose only\n- when the request names an external integration (Gmail, Discord, Slack, Telegram, GitHub, Google Sheets, Google Calendar, Google Drive, Notion, etc.) AND describes data movement between services or scheduled invocation of an external API, prefer CREATE_N8N_WORKFLOW; reserve CREATE_TRIGGER_TASK for self-driven scheduled prompts to the agent itself with no external API calls\n- for standing or future-condition requests like \"if/when X, do Y\", still choose the action that records, queues, or routes that behavior on the first turn\n- if a matching action can own the task and ask the missing follow-up itself, still select that action and put the clarification in text; do not reply in prose alone\n- when the user defines a durable preference, recurring block, escalation policy, upload policy, approval-gated workflow, or multi-device reminder rule, select the owning action even if some implementation details are still missing\n\t- do not wait for portal names, deck attachments, updated-id uploads, exact flight times, reservation ids, fee-risk item names, priority labels, event IDs, exact travel preferences, or the definition of \"important\" before selecting the owning action; let the action gather those details\n\t- future portal uploads, updated-id interventions, and cancellation-fee warning policies are operational workflows, not prose acknowledgements; choose LIFEOPS_COMPUTER_USE or PUBLISH_DEVICE_INTENT first and let those actions ask the missing follow-up\n\t- for LifeOps create requests with a clear defaultable habit or natural window, such as drinking water, stretch breaks during the day, weekday-after-lunch Invisalign checks, or brushing when waking up and before bed, call LIFE instead of asking for exact clock times unless the user explicitly asks for precise scheduling\n- only choose actions that directly satisfy the user's request or an explicit live-state question; do not opportunistically triage inboxes, summarize calendars, propose meetings, or call adjacent tools just because provider context makes them available\n- when the user is venting, reflecting, stating an opinion, or asking for generic advice about a domain, stay in REPLY or NONE unless they explicitly ask you to inspect state, change state, send something, schedule something, or perform a real operation\n\ncontrol_actions:\n- STOP means the task is done and the agent should end the run without executing more actions\n- STOP is a terminal control action even if it is not listed in available actions\n\nfields[5]{name,meaning}:\n- thought | short plan\n- actions | ordered <action> entries inside <actions>\n- providers | array of provider names, or empty\n- text | next message for {{agentName}}\n- simple | true only when text itself should be sent directly as the final reply; false when actions should run, including REPLY-driven finalization\n\nformatting:\n- wrap multi-line code in fenced code blocks\n- use inline backticks for short code identifiers\n\noutput:\nXML only. Return exactly one <response>...</response> document. No prose before or after it. No <think>.\n\nExample:\n<response>\n <thought>Reply briefly. No extra providers needed.</thought>\n <actions>\n <action>\n <name>REPLY</name>\n </action>\n </actions>\n <providers></providers>\n <text>Your message here</text>\n <simple>true</simple>\n</response>";
38
+ export declare const messageHandlerTemplate = "task: Generate dialog and actions for {{agentName}}.\n\ncontext:\n{{providers}}\n\nrules[22]:\n- think briefly, then respond\n- always include a <thought> field, even for direct replies\n- actions execute in listed order\n- if replying without another grounded state/action query, REPLY goes first\n- REPLY means a direct chat reply in the current conversation only; it is not an email reply, inbox workflow, or external-channel send\n- set simple=true only when the planner's text should be sent directly as the final reply without running REPLY again\n- if actions are REPLY-only and you want the REPLY action to generate the final user-facing message, set simple=false\n- use IGNORE or STOP only by themselves\n- in group conversations, choose IGNORE if the latest message is addressed to someone else and not to {{agentName}}\n- include providers only when needed\n- use only action and provider names that appear in the listed runtime surface; never invent new action names, provider names, benchmark ids, or paraphrased tool labels\n- when the user asks about uploaded files, documents, prior uploads, or knowledge-base contents, call the relevant providers before replying instead of asking the user to resend the material\n- when the user refers to \"the uploaded file\", \"the document I uploaded\", or a prior upload without naming it, treat that as a provider lookup request first; only ask which file after grounded document/knowledge lookup still leaves multiple plausible answers\n- use provider_hints from context when present instead of restating the same rules\n- if an action needs inputs, include them inside that action's <params> block\n- if a required param is unknown, ask for clarification in text\n- for live status questions or remaining-work queries, do not answer from recent conversation alone; call the relevant action/provider to refresh state, and do not pair it with a speculative REPLY that guesses the result\n- when an action will fetch the state and produce the final grounded answer, do not add REPLY just to say \"checking\", \"let me look\", or similar filler; use the action alone and leave text empty\n- when the user asks you to create, store, remember, schedule, remind, upload, follow up, route, escalate, or set a standing policy, choose the matching action instead of handling it in prose only\n- when the request names an external integration (Gmail, Discord, Slack, Telegram, GitHub, Google Sheets, Google Calendar, Google Drive, Notion, etc.) AND describes data movement between services or scheduled invocation of an external API, prefer CREATE_N8N_WORKFLOW; reserve CREATE_TRIGGER_TASK for self-driven scheduled prompts to the agent itself with no external API calls\n- for standing or future-condition requests like \"if/when X, do Y\", still choose the action that records, queues, or routes that behavior on the first turn\n- if a matching action can own the task and ask the missing follow-up itself, still select that action and put the clarification in text; do not reply in prose alone\n- when the user defines a durable preference, recurring block, escalation policy, upload policy, approval-gated workflow, or multi-device reminder rule, select the owning action even if some implementation details are still missing\n\t- do not wait for portal names, deck attachments, updated-id uploads, exact flight times, reservation ids, fee-risk item names, priority labels, event IDs, exact travel preferences, or the definition of \"important\" before selecting the owning action; let the action gather those details\n\t- future portal uploads, updated-id interventions, and cancellation-fee warning policies are operational workflows, not prose acknowledgements; choose LIFEOPS_COMPUTER_USE or PUBLISH_DEVICE_INTENT first and let those actions ask the missing follow-up\n\t- for LifeOps create requests with a clear defaultable habit or natural window, such as drinking water, stretch breaks during the day, weekday-after-lunch Invisalign checks, or brushing when waking up and before bed, call LIFE instead of asking for exact clock times unless the user explicitly asks for precise scheduling\n- only choose actions that directly satisfy the user's request or an explicit live-state question; do not opportunistically triage inboxes, summarize calendars, propose meetings, or call adjacent tools just because provider context makes them available\n- when the user is venting, reflecting, stating an opinion, or asking for generic advice about a domain, stay in REPLY or NONE unless they explicitly ask you to inspect state, change state, send something, schedule something, or perform a real operation\n\ncontrol_actions:\n- STOP means the task is done and the agent should end the run without executing more actions\n- STOP is a terminal control action even if it is not listed in available actions\n\nfields[5]{name,meaning}:\n- thought | short plan\n- actions | ordered <action> entries inside <actions>\n- providers | array of provider names, or empty\n- text | next message for {{agentName}}\n- simple | true only when text itself should be sent directly as the final reply; false when actions should run, including REPLY-driven finalization\n\nformatting:\n- wrap multi-line code in fenced code blocks\n- use inline backticks for short code identifiers\n\noutput:\nXML only. Return exactly one <response>...</response> document. No prose before or after it. No <think>.\n\nExample:\n<response>\n <thought>Reply briefly. No extra providers needed.</thought>\n <actions>\n <action>\n <name>REPLY</name>\n </action>\n </actions>\n <providers></providers>\n <text>Your message here</text>\n <simple>true</simple>\n</response>";
39
+ export declare const MESSAGE_HANDLER_TEMPLATE = "task: Generate dialog and actions for {{agentName}}.\n\ncontext:\n{{providers}}\n\nrules[22]:\n- think briefly, then respond\n- always include a <thought> field, even for direct replies\n- actions execute in listed order\n- if replying without another grounded state/action query, REPLY goes first\n- REPLY means a direct chat reply in the current conversation only; it is not an email reply, inbox workflow, or external-channel send\n- set simple=true only when the planner's text should be sent directly as the final reply without running REPLY again\n- if actions are REPLY-only and you want the REPLY action to generate the final user-facing message, set simple=false\n- use IGNORE or STOP only by themselves\n- in group conversations, choose IGNORE if the latest message is addressed to someone else and not to {{agentName}}\n- include providers only when needed\n- use only action and provider names that appear in the listed runtime surface; never invent new action names, provider names, benchmark ids, or paraphrased tool labels\n- when the user asks about uploaded files, documents, prior uploads, or knowledge-base contents, call the relevant providers before replying instead of asking the user to resend the material\n- when the user refers to \"the uploaded file\", \"the document I uploaded\", or a prior upload without naming it, treat that as a provider lookup request first; only ask which file after grounded document/knowledge lookup still leaves multiple plausible answers\n- use provider_hints from context when present instead of restating the same rules\n- if an action needs inputs, include them inside that action's <params> block\n- if a required param is unknown, ask for clarification in text\n- for live status questions or remaining-work queries, do not answer from recent conversation alone; call the relevant action/provider to refresh state, and do not pair it with a speculative REPLY that guesses the result\n- when an action will fetch the state and produce the final grounded answer, do not add REPLY just to say \"checking\", \"let me look\", or similar filler; use the action alone and leave text empty\n- when the user asks you to create, store, remember, schedule, remind, upload, follow up, route, escalate, or set a standing policy, choose the matching action instead of handling it in prose only\n- when the request names an external integration (Gmail, Discord, Slack, Telegram, GitHub, Google Sheets, Google Calendar, Google Drive, Notion, etc.) AND describes data movement between services or scheduled invocation of an external API, prefer CREATE_N8N_WORKFLOW; reserve CREATE_TRIGGER_TASK for self-driven scheduled prompts to the agent itself with no external API calls\n- for standing or future-condition requests like \"if/when X, do Y\", still choose the action that records, queues, or routes that behavior on the first turn\n- if a matching action can own the task and ask the missing follow-up itself, still select that action and put the clarification in text; do not reply in prose alone\n- when the user defines a durable preference, recurring block, escalation policy, upload policy, approval-gated workflow, or multi-device reminder rule, select the owning action even if some implementation details are still missing\n\t- do not wait for portal names, deck attachments, updated-id uploads, exact flight times, reservation ids, fee-risk item names, priority labels, event IDs, exact travel preferences, or the definition of \"important\" before selecting the owning action; let the action gather those details\n\t- future portal uploads, updated-id interventions, and cancellation-fee warning policies are operational workflows, not prose acknowledgements; choose LIFEOPS_COMPUTER_USE or PUBLISH_DEVICE_INTENT first and let those actions ask the missing follow-up\n\t- for LifeOps create requests with a clear defaultable habit or natural window, such as drinking water, stretch breaks during the day, weekday-after-lunch Invisalign checks, or brushing when waking up and before bed, call LIFE instead of asking for exact clock times unless the user explicitly asks for precise scheduling\n- only choose actions that directly satisfy the user's request or an explicit live-state question; do not opportunistically triage inboxes, summarize calendars, propose meetings, or call adjacent tools just because provider context makes them available\n- when the user is venting, reflecting, stating an opinion, or asking for generic advice about a domain, stay in REPLY or NONE unless they explicitly ask you to inspect state, change state, send something, schedule something, or perform a real operation\n\ncontrol_actions:\n- STOP means the task is done and the agent should end the run without executing more actions\n- STOP is a terminal control action even if it is not listed in available actions\n\nfields[5]{name,meaning}:\n- thought | short plan\n- actions | ordered <action> entries inside <actions>\n- providers | array of provider names, or empty\n- text | next message for {{agentName}}\n- simple | true only when text itself should be sent directly as the final reply; false when actions should run, including REPLY-driven finalization\n\nformatting:\n- wrap multi-line code in fenced code blocks\n- use inline backticks for short code identifiers\n\noutput:\nXML only. Return exactly one <response>...</response> document. No prose before or after it. No <think>.\n\nExample:\n<response>\n <thought>Reply briefly. No extra providers needed.</thought>\n <actions>\n <action>\n <name>REPLY</name>\n </action>\n </actions>\n <providers></providers>\n <text>Your message here</text>\n <simple>true</simple>\n</response>";
40
40
  export declare const multiStepDecisionTemplate = "Determine the next step the assistant should take in this conversation to help the user reach their goal.\n\n{{recentMessages}}\n\n# Multi-Step Workflow\n\nIn each step, decide:\n\n1. **Which providers (if any)** should be called to gather necessary data.\n2. **Which action (if any)** should be executed after providers return.\n3. Decide whether the task is complete. If so, set `isFinish: true`. Do not select the `REPLY` action; replies are handled separately after task completion.\n\nYou can select **multiple providers** and at most **one action** per step.\n\nUse only action and provider names that appear in the listed runtime surface. Never invent new action names, provider names, benchmark ids, or paraphrased tool labels.\n\nIf the task is fully resolved and no further steps are needed, mark the step as `isFinish: true`.\n\n---\n\n{{actionsWithDescriptions}}\n\n{{providersWithDescriptions}}\n\nThese are the actions or data provider calls that have already been used in this run. Use this to avoid redundancy and guide your next move.\n\n{{actionResults}}\n\nkeys:\n\"thought\" Clearly explain your reasoning for the selected providers and/or action, and how this step contributes to resolving the user's request.\n\"action\" Name of the action to execute after providers return (can be empty if no action is needed).\n\"providers\" List of provider names to call in this step (can be empty if none are needed).\n\"isFinish\" Set to true only if the task is fully complete.\n\n\u26A0\uFE0F IMPORTANT: Do **not** mark the task as `isFinish: true` immediately after calling an action. Wait for the action to complete before deciding the task is finished.\n\noutput:\nthought: Your thought here\naction: ACTION\nproviders[2]: PROVIDER1,PROVIDER2\nisFinish: false";
41
41
  export declare const MULTI_STEP_DECISION_TEMPLATE = "Determine the next step the assistant should take in this conversation to help the user reach their goal.\n\n{{recentMessages}}\n\n# Multi-Step Workflow\n\nIn each step, decide:\n\n1. **Which providers (if any)** should be called to gather necessary data.\n2. **Which action (if any)** should be executed after providers return.\n3. Decide whether the task is complete. If so, set `isFinish: true`. Do not select the `REPLY` action; replies are handled separately after task completion.\n\nYou can select **multiple providers** and at most **one action** per step.\n\nUse only action and provider names that appear in the listed runtime surface. Never invent new action names, provider names, benchmark ids, or paraphrased tool labels.\n\nIf the task is fully resolved and no further steps are needed, mark the step as `isFinish: true`.\n\n---\n\n{{actionsWithDescriptions}}\n\n{{providersWithDescriptions}}\n\nThese are the actions or data provider calls that have already been used in this run. Use this to avoid redundancy and guide your next move.\n\n{{actionResults}}\n\nkeys:\n\"thought\" Clearly explain your reasoning for the selected providers and/or action, and how this step contributes to resolving the user's request.\n\"action\" Name of the action to execute after providers return (can be empty if no action is needed).\n\"providers\" List of provider names to call in this step (can be empty if none are needed).\n\"isFinish\" Set to true only if the task is fully complete.\n\n\u26A0\uFE0F IMPORTANT: Do **not** mark the task as `isFinish: true` immediately after calling an action. Wait for the action to complete before deciding the task is finished.\n\noutput:\nthought: Your thought here\naction: ACTION\nproviders[2]: PROVIDER1,PROVIDER2\nisFinish: false";
42
42
  export declare const multiStepSummaryTemplate = "Summarize what the assistant has done so far and provide a final response to the user based on the completed steps.\n\n# Context Information\n{{bio}}\n\n---\n\n{{system}}\n\n---\n\n{{messageDirections}}\n\n# Conversation Summary\nBelow is the user's original request and conversation so far:\n{{recentMessages}}\n\n# Execution Trace\nHere are the actions taken by the assistant to fulfill the request:\n{{actionResults}}\n\n# Assistant's Last Reasoning Step\n{{recentMessage}}\n\n# Instructions\n\n - Review the execution trace and last reasoning step carefully\n\n - Your final output MUST be TOON in this format:\noutput:\nthought: Your thought here\ntext: Your final message to the user";
@@ -65,10 +65,10 @@ export declare const shouldFollowRoomTemplate = "task: Decide whether {{agentNam
65
65
  export declare const SHOULD_FOLLOW_ROOM_TEMPLATE = "task: Decide whether {{agentName}} should follow this room.\n\ncontext:\n{{providers}}\n\ncurrent_message:\n{{message}}\n\ninstructions[3]:\n- return true only when the user is clearly asking {{agentName}} to follow, join, listen to, or stay engaged in this room\n- return false when the request is ambiguous or unrelated\n- prefer false when uncertain\n\noutput:\nTOON only. Return exactly one TOON document. No prose before or after it. No <think>.\n\nExample:\ndecision: true";
66
66
  export declare const shouldMuteRoomTemplate = "task: Decide whether {{agentName}} should mute this room.\n\ncontext:\n{{providers}}\n\ncurrent_message:\n{{message}}\n\ninstructions[3]:\n- return true only when the user is clearly asking {{agentName}} to mute, silence, or ignore this room\n- return false when the request is ambiguous or unrelated\n- prefer false when uncertain\n\noutput:\nTOON only. Return exactly one TOON document. No prose before or after it. No <think>.\n\nExample:\ndecision: true";
67
67
  export declare const SHOULD_MUTE_ROOM_TEMPLATE = "task: Decide whether {{agentName}} should mute this room.\n\ncontext:\n{{providers}}\n\ncurrent_message:\n{{message}}\n\ninstructions[3]:\n- return true only when the user is clearly asking {{agentName}} to mute, silence, or ignore this room\n- return false when the request is ambiguous or unrelated\n- prefer false when uncertain\n\noutput:\nTOON only. Return exactly one TOON document. No prose before or after it. No <think>.\n\nExample:\ndecision: true";
68
- export declare const shouldRespondTemplate = "task: Decide whether {{agentName}} should respond, ignore, or stop.\n\ncontext:\n{{providers}}\n\nrules[6]:\n- direct mention of {{agentName}} -> RESPOND\n- different assistant name or talking to someone else -> IGNORE unless {{agentName}} is also directly addressed\n- prior participation by {{agentName}} in the thread is not enough by itself; the newest message must still clearly expect {{agentName}} -> otherwise IGNORE\n- request to stop or be quiet directed at {{agentName}} -> STOP\n- if multiple people are mentioned and {{agentName}} is one of the addressees -> RESPOND\n- if unsure whether the speaker is talking to {{agentName}}, prefer IGNORE over hallucinating relevance\n\navailable_contexts:\n{{availableContexts}}\n\ncontext_routing:\n- primaryContext: choose one context from available_contexts, or \"general\" if none apply\n- secondaryContexts: optional comma-separated list of additional relevant contexts\n- evidenceTurnIds: optional comma-separated list of message IDs supporting the decision\n\ndecision_note:\n- respond only when the latest message is talking TO {{agentName}}\n- talking TO {{agentName}} means name mention, reply chain, or a clear follow-up that still expects {{agentName}} to answer\n- mentions of other people do not cancel a direct address to {{agentName}}\n- casual conversation between other users is not enough\n- if another assistant already answered and nobody re-addressed {{agentName}}, IGNORE\n- if {{agentName}} already replied recently and nobody re-addressed {{agentName}}, IGNORE\n- talking ABOUT {{agentName}} or continuing a room conversation around them is not enough\n\noutput:\nTOON only. Return exactly one TOON document. No prose before or after it. No <think>.\n\nExample:\nname: {{agentName}}\nreasoning: Direct mention and clear follow-up.\naction: RESPOND\nprimaryContext: general\nsecondaryContexts:\nevidenceTurnIds:";
69
- export declare const SHOULD_RESPOND_TEMPLATE = "task: Decide whether {{agentName}} should respond, ignore, or stop.\n\ncontext:\n{{providers}}\n\nrules[6]:\n- direct mention of {{agentName}} -> RESPOND\n- different assistant name or talking to someone else -> IGNORE unless {{agentName}} is also directly addressed\n- prior participation by {{agentName}} in the thread is not enough by itself; the newest message must still clearly expect {{agentName}} -> otherwise IGNORE\n- request to stop or be quiet directed at {{agentName}} -> STOP\n- if multiple people are mentioned and {{agentName}} is one of the addressees -> RESPOND\n- if unsure whether the speaker is talking to {{agentName}}, prefer IGNORE over hallucinating relevance\n\navailable_contexts:\n{{availableContexts}}\n\ncontext_routing:\n- primaryContext: choose one context from available_contexts, or \"general\" if none apply\n- secondaryContexts: optional comma-separated list of additional relevant contexts\n- evidenceTurnIds: optional comma-separated list of message IDs supporting the decision\n\ndecision_note:\n- respond only when the latest message is talking TO {{agentName}}\n- talking TO {{agentName}} means name mention, reply chain, or a clear follow-up that still expects {{agentName}} to answer\n- mentions of other people do not cancel a direct address to {{agentName}}\n- casual conversation between other users is not enough\n- if another assistant already answered and nobody re-addressed {{agentName}}, IGNORE\n- if {{agentName}} already replied recently and nobody re-addressed {{agentName}}, IGNORE\n- talking ABOUT {{agentName}} or continuing a room conversation around them is not enough\n\noutput:\nTOON only. Return exactly one TOON document. No prose before or after it. No <think>.\n\nExample:\nname: {{agentName}}\nreasoning: Direct mention and clear follow-up.\naction: RESPOND\nprimaryContext: general\nsecondaryContexts:\nevidenceTurnIds:";
70
- export declare const shouldRespondWithContextTemplate = "task: Decide whether {{agentName}} should respond and which domain context applies.\n\ncontext:\n{{providers}}\n\navailable_contexts:\n{{availableContexts}}\n\nrules[6]:\n- direct mention of {{agentName}} -> RESPOND\n- different assistant name or talking to someone else -> IGNORE unless {{agentName}} is also directly addressed\n- prior participation by {{agentName}} in the thread is not enough by itself; the newest message must still clearly expect {{agentName}} -> otherwise IGNORE\n- request to stop or be quiet directed at {{agentName}} -> STOP\n- if multiple people are mentioned and {{agentName}} is one of the addressees -> RESPOND\n- if unsure whether the speaker is talking to {{agentName}}, prefer IGNORE over hallucinating relevance\n\ncontext_routing:\n- primaryContext: the single best-matching domain from available_contexts\n- secondaryContexts: zero or more additional domains that are relevant\n- action intent does not only come from the last message; consider the full recent conversation\n- if no specific domain applies, use \"general\"\n\ndecision_note:\n- respond only when the latest message is talking TO {{agentName}}\n- talking TO {{agentName}} means name mention, reply chain, or a clear follow-up that still expects {{agentName}} to answer\n- mentions of other people do not cancel a direct address to {{agentName}}\n- casual conversation between other users is not enough\n- if another assistant already answered and nobody re-addressed {{agentName}}, IGNORE\n- if {{agentName}} already replied recently and nobody re-addressed {{agentName}}, IGNORE\n- talking ABOUT {{agentName}} or continuing a room conversation around them is not enough\n- context routing always applies, even for IGNORE/STOP decisions\n\noutput:\nTOON only. Return exactly one TOON document. No prose before or after it. No <think>.\n\nExample:\nname: {{agentName}}\nreasoning: Direct mention asking about token balance.\naction: RESPOND\nprimaryContext: wallet\nsecondaryContexts: []";
71
- export declare const SHOULD_RESPOND_WITH_CONTEXT_TEMPLATE = "task: Decide whether {{agentName}} should respond and which domain context applies.\n\ncontext:\n{{providers}}\n\navailable_contexts:\n{{availableContexts}}\n\nrules[6]:\n- direct mention of {{agentName}} -> RESPOND\n- different assistant name or talking to someone else -> IGNORE unless {{agentName}} is also directly addressed\n- prior participation by {{agentName}} in the thread is not enough by itself; the newest message must still clearly expect {{agentName}} -> otherwise IGNORE\n- request to stop or be quiet directed at {{agentName}} -> STOP\n- if multiple people are mentioned and {{agentName}} is one of the addressees -> RESPOND\n- if unsure whether the speaker is talking to {{agentName}}, prefer IGNORE over hallucinating relevance\n\ncontext_routing:\n- primaryContext: the single best-matching domain from available_contexts\n- secondaryContexts: zero or more additional domains that are relevant\n- action intent does not only come from the last message; consider the full recent conversation\n- if no specific domain applies, use \"general\"\n\ndecision_note:\n- respond only when the latest message is talking TO {{agentName}}\n- talking TO {{agentName}} means name mention, reply chain, or a clear follow-up that still expects {{agentName}} to answer\n- mentions of other people do not cancel a direct address to {{agentName}}\n- casual conversation between other users is not enough\n- if another assistant already answered and nobody re-addressed {{agentName}}, IGNORE\n- if {{agentName}} already replied recently and nobody re-addressed {{agentName}}, IGNORE\n- talking ABOUT {{agentName}} or continuing a room conversation around them is not enough\n- context routing always applies, even for IGNORE/STOP decisions\n\noutput:\nTOON only. Return exactly one TOON document. No prose before or after it. No <think>.\n\nExample:\nname: {{agentName}}\nreasoning: Direct mention asking about token balance.\naction: RESPOND\nprimaryContext: wallet\nsecondaryContexts: []";
68
+ export declare const shouldRespondTemplate = "task: Decide whether {{agentName}} should respond, ignore, or stop.\n\ncontext:\n{{providers}}\n\nrules[7]:\n- direct mention of {{agentName}} -> RESPOND\n- different assistant name or talking to someone else -> IGNORE unless {{agentName}} is also directly addressed\n- prior participation by {{agentName}} in the thread is not enough by itself; the newest message must still clearly expect {{agentName}} -> otherwise IGNORE\n- request to stop or be quiet directed at {{agentName}} -> STOP\n- if multiple people are mentioned and {{agentName}} is one of the addressees -> RESPOND\n- in group conversations, if the latest message is addressed to someone else and not to {{agentName}}, IGNORE\n- if unsure whether the speaker is talking to {{agentName}}, prefer IGNORE over hallucinating relevance\n\navailable_contexts:\n{{availableContexts}}\n\ncontext_routing:\n- primaryContext: choose one context from available_contexts, or \"general\" if none apply\n- secondaryContexts: optional comma-separated list of additional relevant contexts\n- evidenceTurnIds: optional comma-separated list of message IDs supporting the decision\n\ndecision_note:\n- respond only when the latest message is talking TO {{agentName}}\n- talking TO {{agentName}} means name mention, reply chain, or a clear follow-up that still expects {{agentName}} to answer\n- mentions of other people do not cancel a direct address to {{agentName}}\n- casual conversation between other users is not enough\n- if another assistant already answered and nobody re-addressed {{agentName}}, IGNORE\n- if {{agentName}} already replied recently and nobody re-addressed {{agentName}}, IGNORE\n- talking ABOUT {{agentName}} or continuing a room conversation around them is not enough\n\noutput:\nTOON only. Return exactly one TOON document. No prose before or after it. No <think>.\n\nExample:\nname: {{agentName}}\nreasoning: Direct mention and clear follow-up.\naction: RESPOND\nprimaryContext: general\nsecondaryContexts:\nevidenceTurnIds:";
69
+ export declare const SHOULD_RESPOND_TEMPLATE = "task: Decide whether {{agentName}} should respond, ignore, or stop.\n\ncontext:\n{{providers}}\n\nrules[7]:\n- direct mention of {{agentName}} -> RESPOND\n- different assistant name or talking to someone else -> IGNORE unless {{agentName}} is also directly addressed\n- prior participation by {{agentName}} in the thread is not enough by itself; the newest message must still clearly expect {{agentName}} -> otherwise IGNORE\n- request to stop or be quiet directed at {{agentName}} -> STOP\n- if multiple people are mentioned and {{agentName}} is one of the addressees -> RESPOND\n- in group conversations, if the latest message is addressed to someone else and not to {{agentName}}, IGNORE\n- if unsure whether the speaker is talking to {{agentName}}, prefer IGNORE over hallucinating relevance\n\navailable_contexts:\n{{availableContexts}}\n\ncontext_routing:\n- primaryContext: choose one context from available_contexts, or \"general\" if none apply\n- secondaryContexts: optional comma-separated list of additional relevant contexts\n- evidenceTurnIds: optional comma-separated list of message IDs supporting the decision\n\ndecision_note:\n- respond only when the latest message is talking TO {{agentName}}\n- talking TO {{agentName}} means name mention, reply chain, or a clear follow-up that still expects {{agentName}} to answer\n- mentions of other people do not cancel a direct address to {{agentName}}\n- casual conversation between other users is not enough\n- if another assistant already answered and nobody re-addressed {{agentName}}, IGNORE\n- if {{agentName}} already replied recently and nobody re-addressed {{agentName}}, IGNORE\n- talking ABOUT {{agentName}} or continuing a room conversation around them is not enough\n\noutput:\nTOON only. Return exactly one TOON document. No prose before or after it. No <think>.\n\nExample:\nname: {{agentName}}\nreasoning: Direct mention and clear follow-up.\naction: RESPOND\nprimaryContext: general\nsecondaryContexts:\nevidenceTurnIds:";
70
+ export declare const shouldRespondWithContextTemplate = "task: Decide whether {{agentName}} should respond and which domain context applies.\n\ncontext:\n{{providers}}\n\navailable_contexts:\n{{availableContexts}}\n\nrules[7]:\n- direct mention of {{agentName}} -> RESPOND\n- different assistant name or talking to someone else -> IGNORE unless {{agentName}} is also directly addressed\n- prior participation by {{agentName}} in the thread is not enough by itself; the newest message must still clearly expect {{agentName}} -> otherwise IGNORE\n- request to stop or be quiet directed at {{agentName}} -> STOP\n- if multiple people are mentioned and {{agentName}} is one of the addressees -> RESPOND\n- in group conversations, if the latest message is addressed to someone else and not to {{agentName}}, IGNORE\n- if unsure whether the speaker is talking to {{agentName}}, prefer IGNORE over hallucinating relevance\n\ncontext_routing:\n- primaryContext: the single best-matching domain from available_contexts\n- secondaryContexts: zero or more additional domains that are relevant\n- action intent does not only come from the last message; consider the full recent conversation\n- if no specific domain applies, use \"general\"\n\ndecision_note:\n- respond only when the latest message is talking TO {{agentName}}\n- talking TO {{agentName}} means name mention, reply chain, or a clear follow-up that still expects {{agentName}} to answer\n- mentions of other people do not cancel a direct address to {{agentName}}\n- casual conversation between other users is not enough\n- if another assistant already answered and nobody re-addressed {{agentName}}, IGNORE\n- if {{agentName}} already replied recently and nobody re-addressed {{agentName}}, IGNORE\n- talking ABOUT {{agentName}} or continuing a room conversation around them is not enough\n- context routing always applies, even for IGNORE/STOP decisions\n\noutput:\nTOON only. Return exactly one TOON document. No prose before or after it. No <think>.\n\nExample:\nname: {{agentName}}\nreasoning: Direct mention asking about token balance.\naction: RESPOND\nprimaryContext: wallet\nsecondaryContexts: []";
71
+ export declare const SHOULD_RESPOND_WITH_CONTEXT_TEMPLATE = "task: Decide whether {{agentName}} should respond and which domain context applies.\n\ncontext:\n{{providers}}\n\navailable_contexts:\n{{availableContexts}}\n\nrules[7]:\n- direct mention of {{agentName}} -> RESPOND\n- different assistant name or talking to someone else -> IGNORE unless {{agentName}} is also directly addressed\n- prior participation by {{agentName}} in the thread is not enough by itself; the newest message must still clearly expect {{agentName}} -> otherwise IGNORE\n- request to stop or be quiet directed at {{agentName}} -> STOP\n- if multiple people are mentioned and {{agentName}} is one of the addressees -> RESPOND\n- in group conversations, if the latest message is addressed to someone else and not to {{agentName}}, IGNORE\n- if unsure whether the speaker is talking to {{agentName}}, prefer IGNORE over hallucinating relevance\n\ncontext_routing:\n- primaryContext: the single best-matching domain from available_contexts\n- secondaryContexts: zero or more additional domains that are relevant\n- action intent does not only come from the last message; consider the full recent conversation\n- if no specific domain applies, use \"general\"\n\ndecision_note:\n- respond only when the latest message is talking TO {{agentName}}\n- talking TO {{agentName}} means name mention, reply chain, or a clear follow-up that still expects {{agentName}} to answer\n- mentions of other people do not cancel a direct address to {{agentName}}\n- casual conversation between other users is not enough\n- if another assistant already answered and nobody re-addressed {{agentName}}, IGNORE\n- if {{agentName}} already replied recently and nobody re-addressed {{agentName}}, IGNORE\n- talking ABOUT {{agentName}} or continuing a room conversation around them is not enough\n- context routing always applies, even for IGNORE/STOP decisions\n\noutput:\nTOON only. Return exactly one TOON document. No prose before or after it. No <think>.\n\nExample:\nname: {{agentName}}\nreasoning: Direct mention asking about token balance.\naction: RESPOND\nprimaryContext: wallet\nsecondaryContexts: []";
72
72
  export declare const shouldUnfollowRoomTemplate = "task: Decide whether {{agentName}} should unfollow this room.\n\ncontext:\n{{providers}}\n\ncurrent_message:\n{{message}}\n\ninstructions[3]:\n- return true only when the user is clearly asking {{agentName}} to stop following or leave this room\n- return false when the request is ambiguous or unrelated\n- prefer false when uncertain\n\noutput:\nTOON only. Return exactly one TOON document. No prose before or after it. No <think>.\n\nExample:\ndecision: true";
73
73
  export declare const SHOULD_UNFOLLOW_ROOM_TEMPLATE = "task: Decide whether {{agentName}} should unfollow this room.\n\ncontext:\n{{providers}}\n\ncurrent_message:\n{{message}}\n\ninstructions[3]:\n- return true only when the user is clearly asking {{agentName}} to stop following or leave this room\n- return false when the request is ambiguous or unrelated\n- prefer false when uncertain\n\noutput:\nTOON only. Return exactly one TOON document. No prose before or after it. No <think>.\n\nExample:\ndecision: true";
74
74
  export declare const shouldUnmuteRoomTemplate = "task: Decide whether {{agentName}} should unmute this room.\n\ncontext:\n{{providers}}\n\ncurrent_message:\n{{message}}\n\ninstructions[3]:\n- return true only when the user is clearly asking {{agentName}} to unmute or resume listening to this room\n- return false when the request is ambiguous or unrelated\n- prefer false when uncertain\n\noutput:\nTOON only. Return exactly one TOON document. No prose before or after it. No <think>.\n\nExample:\ndecision: true";
@@ -1 +1 @@
1
- {"version":3,"file":"prompts.d.ts","sourceRoot":"","sources":["../../../../../typescript/src/prompts.ts"],"names":[],"mappings":"AAAA;;;;;;;;GAQG;AAEH,eAAO,MAAM,kBAAkB,4vBA4BY,CAAC;AAE5C,eAAO,MAAM,oBAAoB,4vBAAqB,CAAC;AAEvD,eAAO,MAAM,kCAAkC,4vBAcsB,CAAC;AAEtE,eAAO,MAAM,qCAAqC,4vBACf,CAAC;AAEpC,eAAO,MAAM,+BAA+B,qsBAYoB,CAAC;AAEjE,eAAO,MAAM,kCAAkC,qsBACf,CAAC;AAEjC,eAAO,MAAM,4BAA4B,yxBAgBgB,CAAC;AAE1D,eAAO,MAAM,+BAA+B,yxBAA+B,CAAC;AAE5E,eAAO,MAAM,yBAAyB,+tBAasC,CAAC;AAE7E,eAAO,MAAM,4BAA4B,+tBAA4B,CAAC;AAEtE,eAAO,MAAM,oBAAoB,6cAemC,CAAC;AAErE,eAAO,MAAM,sBAAsB,6cAAuB,CAAC;AAE3D,eAAO,MAAM,8BAA8B,szBAmB2D,CAAC;AAEvG,eAAO,MAAM,iCAAiC,szBAAiC,CAAC;AAEhF,eAAO,MAAM,4BAA4B,4iBAea,CAAC;AAEvD,eAAO,MAAM,+BAA+B,4iBAA+B,CAAC;AAE5E,eAAO,MAAM,sBAAsB,g0BAgBiI,CAAC;AAErK,eAAO,MAAM,wBAAwB,g0BAAyB,CAAC;AAE/D,eAAO,MAAM,wBAAwB,6lCAiBmG,CAAC;AAEzI,eAAO,MAAM,0BAA0B,6lCAA2B,CAAC;AAEnE,eAAO,MAAM,uBAAuB,weAegC,CAAC;AAErE,eAAO,MAAM,yBAAyB,weAA0B,CAAC;AAEjE,eAAO,MAAM,4BAA4B,q1BA2BV,CAAC;AAEhC,eAAO,MAAM,8BAA8B,q1BAA+B,CAAC;AAE3E,eAAO,MAAM,0BAA0B,8uKA+HpB,CAAC;AAEpB,eAAO,MAAM,6BAA6B,8uKAA6B,CAAC;AAExE,eAAO,MAAM,yBAAyB,6rCAoChB,CAAC;AAEvB,eAAO,MAAM,2BAA2B,6rCAA4B,CAAC;AAErE,eAAO,MAAM,sBAAsB,o9KA+DvB,CAAC;AAEb,eAAO,MAAM,wBAAwB,o9KAAyB,CAAC;AAE/D,eAAO,MAAM,yBAAyB,svDAwCtB,CAAC;AAEjB,eAAO,MAAM,4BAA4B,svDAA4B,CAAC;AAEtE,eAAO,MAAM,wBAAwB,srBA+BA,CAAC;AAEtC,eAAO,MAAM,2BAA2B,srBAA2B,CAAC;AAEpE,eAAO,MAAM,wBAAwB,srBAmBmG,CAAC;AAEzI,eAAO,MAAM,0BAA0B,srBAA2B,CAAC;AAEnE,eAAO,MAAM,0BAA0B,qmDAoC1B,CAAC;AAEd,eAAO,MAAM,6BAA6B,qmDAA6B,CAAC;AAExE,eAAO,MAAM,oBAAoB,qwEAkCuG,CAAC;AAEzI,eAAO,MAAM,sBAAsB,qwEAAuB,CAAC;AAE3D,eAAO,MAAM,2BAA2B,m1EAiDgG,CAAC;AAEzI,eAAO,MAAM,6BAA6B,m1EAA8B,CAAC;AAEzE,eAAO,MAAM,sBAAsB,8sMA+GgI,CAAC;AAEpK,eAAO,MAAM,wBAAwB,8sMAAyB,CAAC;AAE/D,eAAO,MAAM,kBAAkB,upBAqBqC,CAAC;AAErE,eAAO,MAAM,mBAAmB,upBAAqB,CAAC;AAEtD,eAAO,MAAM,qBAAqB,ueAmBnB,CAAC;AAEhB,eAAO,MAAM,uBAAuB,ueAAwB,CAAC;AAE7D,eAAO,MAAM,aAAa,8uCAqB8G,CAAC;AAEzI,eAAO,MAAM,cAAc,8uCAAgB,CAAC;AAE5C,eAAO,MAAM,wBAAwB,+uBA2BS,CAAC;AAE/C,eAAO,MAAM,2BAA2B,+uBAA2B,CAAC;AAEpE,eAAO,MAAM,sBAAsB,0oBAsBtB,CAAC;AAEd,eAAO,MAAM,wBAAwB,0oBAAyB,CAAC;AAE/D,eAAO,MAAM,wBAAwB,meAiBtB,CAAC;AAEhB,eAAO,MAAM,2BAA2B,meAA2B,CAAC;AAEpE,eAAO,MAAM,sBAAsB,8cAiBpB,CAAC;AAEhB,eAAO,MAAM,yBAAyB,8cAAyB,CAAC;AAEhE,eAAO,MAAM,qBAAqB,o2DAuCjB,CAAC;AAElB,eAAO,MAAM,uBAAuB,o2DAAwB,CAAC;AAE7D,eAAO,MAAM,gCAAgC,08DAwCvB,CAAC;AAEvB,eAAO,MAAM,oCAAoC,08DAChB,CAAC;AAElC,eAAO,MAAM,0BAA0B,idAiBxB,CAAC;AAEhB,eAAO,MAAM,6BAA6B,idAA6B,CAAC;AAExE,eAAO,MAAM,wBAAwB,qdAiBtB,CAAC;AAEhB,eAAO,MAAM,2BAA2B,qdAA2B,CAAC;AAEpE,eAAO,MAAM,aAAa,m0CAwBoG,CAAC;AAE/H,eAAO,MAAM,cAAc,m0CAAgB,CAAC;AAE5C,eAAO,MAAM,qBAAqB,0xBA0BC,CAAC;AAEpC,eAAO,MAAM,uBAAuB,0xBAAwB,CAAC;AAE7D,eAAO,MAAM,oBAAoB,ogBAiBmC,CAAC;AAErE,eAAO,MAAM,sBAAsB,ogBAAuB,CAAC;AAE3D,eAAO,MAAM,kBAAkB,6vBA4Bf,CAAC;AAEjB,eAAO,MAAM,oBAAoB,6vBAAqB,CAAC;AAEvD,eAAO,MAAM,sBAAsB,+bAgBiC,CAAC;AAErE,eAAO,MAAM,wBAAwB,+bAAyB,CAAC;AAE/D,eAAO,MAAM,2BAA2B,o7BA6BT,CAAC;AAEhC,eAAO,MAAM,6BAA6B,o7BAA8B,CAAC;AAEzE,eAAO,MAAM,aAAa,qCAAqC,CAAC;AAEhE,eAAO,MAAM,cAAc,qCAAgB,CAAC"}
1
+ {"version":3,"file":"prompts.d.ts","sourceRoot":"","sources":["../../../../../typescript/src/prompts.ts"],"names":[],"mappings":"AAAA;;;;;;;;GAQG;AAEH,eAAO,MAAM,kBAAkB,4vBA4BY,CAAC;AAE5C,eAAO,MAAM,oBAAoB,4vBAAqB,CAAC;AAEvD,eAAO,MAAM,kCAAkC,4vBAcsB,CAAC;AAEtE,eAAO,MAAM,qCAAqC,4vBACf,CAAC;AAEpC,eAAO,MAAM,+BAA+B,qsBAYoB,CAAC;AAEjE,eAAO,MAAM,kCAAkC,qsBACf,CAAC;AAEjC,eAAO,MAAM,4BAA4B,yxBAgBgB,CAAC;AAE1D,eAAO,MAAM,+BAA+B,yxBAA+B,CAAC;AAE5E,eAAO,MAAM,yBAAyB,+tBAasC,CAAC;AAE7E,eAAO,MAAM,4BAA4B,+tBAA4B,CAAC;AAEtE,eAAO,MAAM,oBAAoB,6cAemC,CAAC;AAErE,eAAO,MAAM,sBAAsB,6cAAuB,CAAC;AAE3D,eAAO,MAAM,8BAA8B,szBAmB2D,CAAC;AAEvG,eAAO,MAAM,iCAAiC,szBAAiC,CAAC;AAEhF,eAAO,MAAM,4BAA4B,4iBAea,CAAC;AAEvD,eAAO,MAAM,+BAA+B,4iBAA+B,CAAC;AAE5E,eAAO,MAAM,sBAAsB,g0BAgBiI,CAAC;AAErK,eAAO,MAAM,wBAAwB,g0BAAyB,CAAC;AAE/D,eAAO,MAAM,wBAAwB,6lCAiBmG,CAAC;AAEzI,eAAO,MAAM,0BAA0B,6lCAA2B,CAAC;AAEnE,eAAO,MAAM,uBAAuB,weAegC,CAAC;AAErE,eAAO,MAAM,yBAAyB,weAA0B,CAAC;AAEjE,eAAO,MAAM,4BAA4B,q1BA2BV,CAAC;AAEhC,eAAO,MAAM,8BAA8B,q1BAA+B,CAAC;AAE3E,eAAO,MAAM,0BAA0B,8uKA+HpB,CAAC;AAEpB,eAAO,MAAM,6BAA6B,8uKAA6B,CAAC;AAExE,eAAO,MAAM,yBAAyB,6rCAoChB,CAAC;AAEvB,eAAO,MAAM,2BAA2B,6rCAA4B,CAAC;AAErE,eAAO,MAAM,sBAAsB,ykLAgEvB,CAAC;AAEb,eAAO,MAAM,wBAAwB,ykLAAyB,CAAC;AAE/D,eAAO,MAAM,yBAAyB,svDAwCtB,CAAC;AAEjB,eAAO,MAAM,4BAA4B,svDAA4B,CAAC;AAEtE,eAAO,MAAM,wBAAwB,srBA+BA,CAAC;AAEtC,eAAO,MAAM,2BAA2B,srBAA2B,CAAC;AAEpE,eAAO,MAAM,wBAAwB,srBAmBmG,CAAC;AAEzI,eAAO,MAAM,0BAA0B,srBAA2B,CAAC;AAEnE,eAAO,MAAM,0BAA0B,qmDAoC1B,CAAC;AAEd,eAAO,MAAM,6BAA6B,qmDAA6B,CAAC;AAExE,eAAO,MAAM,oBAAoB,qwEAkCuG,CAAC;AAEzI,eAAO,MAAM,sBAAsB,qwEAAuB,CAAC;AAE3D,eAAO,MAAM,2BAA2B,m1EAiDgG,CAAC;AAEzI,eAAO,MAAM,6BAA6B,m1EAA8B,CAAC;AAEzE,eAAO,MAAM,sBAAsB,8sMA+GgI,CAAC;AAEpK,eAAO,MAAM,wBAAwB,8sMAAyB,CAAC;AAE/D,eAAO,MAAM,kBAAkB,upBAqBqC,CAAC;AAErE,eAAO,MAAM,mBAAmB,upBAAqB,CAAC;AAEtD,eAAO,MAAM,qBAAqB,ueAmBnB,CAAC;AAEhB,eAAO,MAAM,uBAAuB,ueAAwB,CAAC;AAE7D,eAAO,MAAM,aAAa,8uCAqB8G,CAAC;AAEzI,eAAO,MAAM,cAAc,8uCAAgB,CAAC;AAE5C,eAAO,MAAM,wBAAwB,+uBA2BS,CAAC;AAE/C,eAAO,MAAM,2BAA2B,+uBAA2B,CAAC;AAEpE,eAAO,MAAM,sBAAsB,0oBAsBtB,CAAC;AAEd,eAAO,MAAM,wBAAwB,0oBAAyB,CAAC;AAE/D,eAAO,MAAM,wBAAwB,meAiBtB,CAAC;AAEhB,eAAO,MAAM,2BAA2B,meAA2B,CAAC;AAEpE,eAAO,MAAM,sBAAsB,8cAiBpB,CAAC;AAEhB,eAAO,MAAM,yBAAyB,8cAAyB,CAAC;AAEhE,eAAO,MAAM,qBAAqB,m9DAwCjB,CAAC;AAElB,eAAO,MAAM,uBAAuB,m9DAAwB,CAAC;AAE7D,eAAO,MAAM,gCAAgC,yjEAyCvB,CAAC;AAEvB,eAAO,MAAM,oCAAoC,yjEAChB,CAAC;AAElC,eAAO,MAAM,0BAA0B,idAiBxB,CAAC;AAEhB,eAAO,MAAM,6BAA6B,idAA6B,CAAC;AAExE,eAAO,MAAM,wBAAwB,qdAiBtB,CAAC;AAEhB,eAAO,MAAM,2BAA2B,qdAA2B,CAAC;AAEpE,eAAO,MAAM,aAAa,m0CAwBoG,CAAC;AAE/H,eAAO,MAAM,cAAc,m0CAAgB,CAAC;AAE5C,eAAO,MAAM,qBAAqB,0xBA0BC,CAAC;AAEpC,eAAO,MAAM,uBAAuB,0xBAAwB,CAAC;AAE7D,eAAO,MAAM,oBAAoB,ogBAiBmC,CAAC;AAErE,eAAO,MAAM,sBAAsB,ogBAAuB,CAAC;AAE3D,eAAO,MAAM,kBAAkB,6vBA4Bf,CAAC;AAEjB,eAAO,MAAM,oBAAoB,6vBAAqB,CAAC;AAEvD,eAAO,MAAM,sBAAsB,+bAgBiC,CAAC;AAErE,eAAO,MAAM,wBAAwB,+bAAyB,CAAC;AAE/D,eAAO,MAAM,2BAA2B,o7BA6BT,CAAC;AAEhC,eAAO,MAAM,6BAA6B,o7BAA8B,CAAC;AAEzE,eAAO,MAAM,aAAa,qCAAqC,CAAC;AAEhE,eAAO,MAAM,cAAc,qCAAgB,CAAC"}
@@ -410,7 +410,7 @@ export const messageHandlerTemplate = `task: Generate dialog and actions for {{a
410
410
  context:
411
411
  {{providers}}
412
412
 
413
- rules[21]:
413
+ rules[22]:
414
414
  - think briefly, then respond
415
415
  - always include a <thought> field, even for direct replies
416
416
  - actions execute in listed order
@@ -419,6 +419,7 @@ rules[21]:
419
419
  - set simple=true only when the planner's text should be sent directly as the final reply without running REPLY again
420
420
  - if actions are REPLY-only and you want the REPLY action to generate the final user-facing message, set simple=false
421
421
  - use IGNORE or STOP only by themselves
422
+ - in group conversations, choose IGNORE if the latest message is addressed to someone else and not to {{agentName}}
422
423
  - include providers only when needed
423
424
  - use only action and provider names that appear in the listed runtime surface; never invent new action names, provider names, benchmark ids, or paraphrased tool labels
424
425
  - when the user asks about uploaded files, documents, prior uploads, or knowledge-base contents, call the relevant providers before replying instead of asking the user to resend the material
@@ -967,12 +968,13 @@ export const shouldRespondTemplate = `task: Decide whether {{agentName}} should
967
968
  context:
968
969
  {{providers}}
969
970
 
970
- rules[6]:
971
+ rules[7]:
971
972
  - direct mention of {{agentName}} -> RESPOND
972
973
  - different assistant name or talking to someone else -> IGNORE unless {{agentName}} is also directly addressed
973
974
  - prior participation by {{agentName}} in the thread is not enough by itself; the newest message must still clearly expect {{agentName}} -> otherwise IGNORE
974
975
  - request to stop or be quiet directed at {{agentName}} -> STOP
975
976
  - if multiple people are mentioned and {{agentName}} is one of the addressees -> RESPOND
977
+ - in group conversations, if the latest message is addressed to someone else and not to {{agentName}}, IGNORE
976
978
  - if unsure whether the speaker is talking to {{agentName}}, prefer IGNORE over hallucinating relevance
977
979
 
978
980
  available_contexts:
@@ -1011,12 +1013,13 @@ context:
1011
1013
  available_contexts:
1012
1014
  {{availableContexts}}
1013
1015
 
1014
- rules[6]:
1016
+ rules[7]:
1015
1017
  - direct mention of {{agentName}} -> RESPOND
1016
1018
  - different assistant name or talking to someone else -> IGNORE unless {{agentName}} is also directly addressed
1017
1019
  - prior participation by {{agentName}} in the thread is not enough by itself; the newest message must still clearly expect {{agentName}} -> otherwise IGNORE
1018
1020
  - request to stop or be quiet directed at {{agentName}} -> STOP
1019
1021
  - if multiple people are mentioned and {{agentName}} is one of the addressees -> RESPOND
1022
+ - in group conversations, if the latest message is addressed to someone else and not to {{agentName}}, IGNORE
1020
1023
  - if unsure whether the speaker is talking to {{agentName}}, prefer IGNORE over hallucinating relevance
1021
1024
 
1022
1025
  context_routing: