@axiom-lattice/core 2.1.70 → 2.1.72

package/dist/index.mjs

@@ -2793,7 +2793,7 @@ var manageBindingSchema = z3.object({
   channelInstallationId: z3.string().optional().describe("Channel installation ID (auto-detected if omitted and only one exists for this channel)"),
   senderId: z3.string().optional().describe("Sender identifier (email address, Lark openId, Slack userId)"),
   agentId: z3.string().optional().describe("Target agent ID to route messages to"),
-  threadMode: z3.enum(["fixed", "per_conversation"]).optional().describe("Thread mode: fixed or per_conversation"),
+  threadMode: z3.enum(["fixed", "per_conversation"]).optional().default("per_conversation").describe("Thread mode: per_conversation (recommended) or fixed"),
   senderDisplayName: z3.string().optional().describe("Human-readable name for the sender")
 });
 registerToolLattice(
@@ -2803,8 +2803,8 @@ registerToolLattice(
     description: `Manage sender-to-agent bindings for external channels (email, Lark, Slack).
 
 - list_installations: List available channel installations. Filter by channel type (optional). Use this first to discover available channelInstallationIds.
-- create: Bind a sender to an agent. Required: channel, senderId, agentId. channelInstallationId is optional \u2014 auto-detected if only one installation exists for this channel.
-- update: Update an existing binding. Required: channel, senderId. Optional: agentId, threadMode, senderDisplayName.
+- create: Bind a sender to an agent. Required: channel, senderId, agentId. Optional: threadMode (default: per_conversation). channelInstallationId is optional \u2014 auto-detected if only one installation exists for this channel.
+- update: Update an existing binding. Required: channel, senderId. Optional: agentId, threadMode (default: per_conversation), senderDisplayName.
 - delete: Remove a binding. Required: channel, senderId.
 - list: List all bindings. Optional: channel, agentId, channelInstallationId.
 
@@ -18804,7 +18804,7 @@ If the user's intent is unclear after creation, ask: "Edit this agent or create
 
 ## Your Tools
 
-You have eight tools for agent management:
+You have nine tools for agent management:
 - **list_agents** \u2014 See all existing agents for this workspace
 - **list_tools** \u2014 See all available tools that can be assigned to agents
 - **get_agent** \u2014 View the full configuration of a specific agent
@@ -18813,6 +18813,7 @@ You have eight tools for agent management:
 - **update_processing_agent** \u2014 Modify a PROCESSING agent's topology edges, name, prompt, or sub-agents
 - **update_agent** \u2014 Modify an existing REACT or DEEP_AGENT agent's configuration
 - **delete_agent** \u2014 Remove an agent permanently
+- **manage_binding** \u2014 Bind a sender (email, Lark, Slack user) to an agent so external messages are routed to it
 
 You also have an **Agent Reviewer** sub-agent that handles testing and configuration review. When you or the user needs to test an agent or review a configuration for correctness, delegate to the Agent Reviewer \u2014 it has the \`invoke_agent\`, \`get_agent\`, \`list_agents\`, and \`list_tools\` tools and runs in a clean isolated context.
 
@@ -18893,6 +18894,8 @@ Use this when the task follows a standard BPO (Business Process Orchestration) p
 
 **Step 1: Process analysis.** Ask: What is the end-to-end process? Map the stages.
 
+**Business rule \u2014 Draft-then-confirm pattern:** When a workflow creates business objects that require human approval (e.g., draft orders in SAP B1, purchase requisitions, expense reports), the design MUST include a confirmation step AFTER the creation step. The create step must complete successfully before the confirm step runs. The flow is always: **Create draft \u2192 User confirms \u2192 Finalize**. Reason: systems like SAP B1 only expose drafts to users after they are created \u2014 the user cannot see or approve something that doesn't exist yet. The confirm step MUST use the \`ask_user_to_clarify\` middleware.
+
 **Step 2: Topology design.** Design the agent topology and use \`show_widget\` to render an interactive diagram showing the flow: Orchestrator \u2192 Stage 1 \u2192 Stage 2 \u2192 ... \u2192 Output. Each edge should be labeled with its business purpose.
 
 **Step 3: Design each sub-agent** as a **deep_agent** type (one at a time). For each:
@@ -18999,6 +19002,18 @@ First edge's \`from\` uses orchestrator name as placeholder (auto-resolved). Sub
 
 You may ask: "Want me to test the orchestrator end-to-end?" If yes, delegate to the **Agent Reviewer** sub-agent.
 
+### Phase 5: Bind channel (ask)
+
+After the workflow is created, ask the user if they want to bind an email address (or Lark/Slack sender) to drive the workflow. This allows external users to trigger the workflow by sending messages to the channel.
+
+**Step 1: Check installations.** Call \`manage_binding\` with \`action: "list_installations"\` to see available channel installations.
+
+**Step 2: Ask user.** Present the available channels and ask: "Would you like to bind an email address to drive this workflow? If so, what email address should trigger it?"
+
+**Step 3: Bind.** Call \`manage_binding\` with \`action: "create"\`, providing \`channel\`, \`senderId\` (the email), and \`agentId\` (the orchestrator's ID).
+
+**IMPORTANT:** Only create a binding after the user explicitly provides the email address. Do NOT guess or fabricate sender information.
+
 ---
 
 ## Workflow C: Dynamic Agent (DEEP_AGENT type)
@@ -19237,6 +19252,22 @@ Provides: \`read_topo_progress\` \u2014 enforces multi-agent workflow topology.
 | Approval-gated operations | ask_user_to_clarify, widget |
 | Interactive Q&A | ask_user_to_clarify, date, widget |
 
+### manage_binding Reference
+
+Use \`manage_binding\` to bind external senders (email, Lark, Slack) to agents. A binding routes inbound messages from the sender to the specified agent.
+
+| action | description | required params |
+|--------|-------------|----------------|
+| list_installations | List available channel installations | channel (optional) |
+| create | Bind a sender to an agent | channel, senderId, agentId |
+| update | Update an existing binding | channel, senderId |
+| delete | Remove a binding | channel, senderId |
+| list | List all bindings | channel, agentId (optional) |
+
+- **senderId**: For email channel, this is the email address. For Lark, it's the openId. For Slack, it's the userId.
+- **threadMode**: Always use \`"per_conversation"\` (new thread per conversation). Do NOT use \`"fixed"\`.
+- **channelInstallationId**: Auto-detected if only one installation exists for the channel. Use \`list_installations\` first if unsure.
+
 ### update_processing_agent
 
 Updates a PROCESSING agent's topology edges, name, prompt, or sub-agents. Unlike update_agent, this properly handles placeholder resolution for edge \`from\` values and manages the topology middleware correctly.