@elevasis/sdk 1.41.0 → 1.42.0

package/dist/cli.cjs

@@ -45834,7 +45834,7 @@ function wrapAction(commandName, fn) {
 // package.json
 var package_default = {
   name: "@elevasis/sdk",
-  version: "1.41.0",
+  version: "1.42.0",
   description: "SDK for building Elevasis organization resources",
   type: "module",
   bin: {

package/dist/index.d.ts

@@ -502,6 +502,15 @@ interface ModelConfig {
     modelOptions?: ModelSpecificOptions;
 }
 
+/**
+ * What happened to `strict` on a request, recorded per call rather than inferred.
+ *
+ * `applied` and `notAttempted` are the two states that a refusal-only field cannot tell apart —
+ * both leave `strictRefusalReasons` empty. Recording the verdict positively is what makes "was
+ * this agent's output actually enforced?" answerable from an `ai_calls` row.
+ */
+type StrictStatus = 'applied' | 'refused' | 'compileRejected' | 'notAttempted';
+
 declare const ResourceGovernanceStatusSchema: z.ZodEnum<{
     active: "active";
     deprecated: "deprecated";
@@ -1029,6 +1038,7 @@ interface WorkflowDefinition {
  * Generic LLM Types
  * Universal interfaces for LLM interaction across all resource types
  */
+
 /**
  * Standard chat message format
  * Compatible with OpenAI, Anthropic, and other providers
@@ -1062,15 +1072,30 @@ interface LLMGenerateResponse<T = unknown> {
         totalTokens: number;
     };
     cost?: number;
+    /**
+     * What actually happened to `strict` on the request that produced this response. Every server
+     * adapter sets it on every call, so the value is a statement rather than an inference:
+     *
+     * - `applied` — the request carried `strict: true` and the grammar was in effect
+     * - `refused` — `toStrictSchema` could not express the schema, so the request went out unstrict
+     * - `compileRejected` — the schema passed `toStrictSchema` but the provider's grammar compiler
+     *   rejected it at request time, and the call was retried unstrict
+     * - `notAttempted` — this adapter does not send strict at all (OpenAI, Google, OpenRouter)
+     *
+     * This exists because `strictRefusalReasons` alone cannot answer the question. Its absence means
+     * "strict held" OR "nothing ever tried", and a prod run that recorded zero refusals while
+     * returning an array-typed field as a string is exactly the case where the difference matters.
+     *
+     * Internal-only, like `usage` — `UniversalLLMAdapter` lifts it onto the `ai_calls` row and
+     * strips it before the response reaches callers.
+     */
+    strictStatus?: StrictStatus;
     /**
      * Why this call went out WITHOUT `strict`, on an adapter that tried to send it with one.
      *
-     * Present only on a refusal, so absence means either "strict was in effect" or "this adapter
-     * does not attempt strict at all" — the two are distinguished by which adapter answered, not by
-     * this field. `toStrictSchema` already computes these reasons and, until now, nothing consumed
-     * them at the call site: an unstrict call was indistinguishable from a strict one anywhere
-     * outside a dev-only flow log. That invisibility is what let every tenant run unstrict against a
-     * strict-capable API for as long as it took someone to recognise a pre-strict error signature.
+     * The detail behind a `refused` / `compileRejected` `strictStatus` — the short, stable reason
+     * strings `toStrictSchema` computes. Read `strictStatus` to answer "was it enforced"; read this
+     * to answer "why not".
      *
      * Internal-only, like `usage` — `UniversalLLMAdapter` lifts it onto the `ai_calls` row and
      * strips it before the response reaches callers.
@@ -11248,15 +11273,24 @@ interface BaseAICall {
      */
     unvalidatedOutput?: string;
     /**
-     * Why this call went out without `strict` structured output, on an adapter that tried to send it
-     * with one. Present ONLY on a refusal — its absence on a row from a strict-capable adapter means
-     * strict was in effect.
+     * What happened to `strict` structured output on this call — `applied`, `refused`,
+     * `compileRejected`, or `notAttempted`. Every server adapter sets it, so this is the field that
+     * answers "is this agent's output actually being enforced?" without reading source.
      *
-     * This is the row that answers "is this agent's output actually being enforced?" without reading
-     * source. Counting rows that carry it, per resource, is the refusal count: a redeployed agent on
-     * a current bundle should read zero. It exists because the previous answer was a dev-only flow
-     * log, which meant production had no answer — and every sync-managed tenant ran unstrict against
-     * a strict-capable API until a 14-turn session surfaced a pre-strict error signature.
+     * It replaces an inference that turned out to be unsound. `strictRefusalReasons` alone records
+     * only refusals, so an empty row meant "strict held" OR "this adapter never tries" — and a prod
+     * run recorded zero refusals while a call returned an array-typed field as a string, which a
+     * grammar makes impossible. The absence proved nothing, because the deployed API had no way to
+     * write the field at all.
+     *
+     * Absent on rows written before this field existed; that absence is itself diagnostic (the API
+     * predates the change). Existing readers that only look at the fields above are unaffected.
+     */
+    strictStatus?: StrictStatus;
+    /**
+     * Why this call went out without `strict`, when a strict-capable adapter refused the schema. The
+     * detail behind `strictStatus: 'refused' | 'compileRejected'` — read `strictStatus` for whether
+     * it was enforced, this for why not.
      *
      * Existing readers that only look at the fields above are unaffected.
      */
@@ -11316,6 +11350,8 @@ interface LLMUsageData {
     outputValidationError?: string;
     /** Raw model output that failed validation — JSON-stringified, truncated, truncation marked inline */
     unvalidatedOutput?: string;
+    /** What happened to `strict` on this call — set by every server adapter, refusal or not */
+    strictStatus?: StrictStatus;
     /** Why the call went out unstrict, when a strict-capable adapter refused the schema */
     strictRefusalReasons?: string[];
 }

package/dist/node/index.d.ts

@@ -372,6 +372,15 @@ interface ModelConfig {
     modelOptions?: ModelSpecificOptions;
 }
 
+/**
+ * What happened to `strict` on a request, recorded per call rather than inferred.
+ *
+ * `applied` and `notAttempted` are the two states that a refusal-only field cannot tell apart —
+ * both leave `strictRefusalReasons` empty. Recording the verdict positively is what makes "was
+ * this agent's output actually enforced?" answerable from an `ai_calls` row.
+ */
+type StrictStatus = 'applied' | 'refused' | 'compileRejected' | 'notAttempted';
+
 declare const ResourceGovernanceStatusSchema: z.ZodEnum<{
     active: "active";
     deprecated: "deprecated";
@@ -899,6 +908,7 @@ interface WorkflowDefinition {
  * Generic LLM Types
  * Universal interfaces for LLM interaction across all resource types
  */
+
 /**
  * Standard chat message format
  * Compatible with OpenAI, Anthropic, and other providers
@@ -932,15 +942,30 @@ interface LLMGenerateResponse<T = unknown> {
         totalTokens: number;
     };
     cost?: number;
+    /**
+     * What actually happened to `strict` on the request that produced this response. Every server
+     * adapter sets it on every call, so the value is a statement rather than an inference:
+     *
+     * - `applied` — the request carried `strict: true` and the grammar was in effect
+     * - `refused` — `toStrictSchema` could not express the schema, so the request went out unstrict
+     * - `compileRejected` — the schema passed `toStrictSchema` but the provider's grammar compiler
+     *   rejected it at request time, and the call was retried unstrict
+     * - `notAttempted` — this adapter does not send strict at all (OpenAI, Google, OpenRouter)
+     *
+     * This exists because `strictRefusalReasons` alone cannot answer the question. Its absence means
+     * "strict held" OR "nothing ever tried", and a prod run that recorded zero refusals while
+     * returning an array-typed field as a string is exactly the case where the difference matters.
+     *
+     * Internal-only, like `usage` — `UniversalLLMAdapter` lifts it onto the `ai_calls` row and
+     * strips it before the response reaches callers.
+     */
+    strictStatus?: StrictStatus;
     /**
      * Why this call went out WITHOUT `strict`, on an adapter that tried to send it with one.
      *
-     * Present only on a refusal, so absence means either "strict was in effect" or "this adapter
-     * does not attempt strict at all" — the two are distinguished by which adapter answered, not by
-     * this field. `toStrictSchema` already computes these reasons and, until now, nothing consumed
-     * them at the call site: an unstrict call was indistinguishable from a strict one anywhere
-     * outside a dev-only flow log. That invisibility is what let every tenant run unstrict against a
-     * strict-capable API for as long as it took someone to recognise a pre-strict error signature.
+     * The detail behind a `refused` / `compileRejected` `strictStatus` — the short, stable reason
+     * strings `toStrictSchema` computes. Read `strictStatus` to answer "was it enforced"; read this
+     * to answer "why not".
      *
      * Internal-only, like `usage` — `UniversalLLMAdapter` lifts it onto the `ai_calls` row and
      * strips it before the response reaches callers.
@@ -2749,15 +2774,24 @@ interface BaseAICall {
      */
     unvalidatedOutput?: string;
     /**
-     * Why this call went out without `strict` structured output, on an adapter that tried to send it
-     * with one. Present ONLY on a refusal — its absence on a row from a strict-capable adapter means
-     * strict was in effect.
+     * What happened to `strict` structured output on this call — `applied`, `refused`,
+     * `compileRejected`, or `notAttempted`. Every server adapter sets it, so this is the field that
+     * answers "is this agent's output actually being enforced?" without reading source.
      *
-     * This is the row that answers "is this agent's output actually being enforced?" without reading
-     * source. Counting rows that carry it, per resource, is the refusal count: a redeployed agent on
-     * a current bundle should read zero. It exists because the previous answer was a dev-only flow
-     * log, which meant production had no answer — and every sync-managed tenant ran unstrict against
-     * a strict-capable API until a 14-turn session surfaced a pre-strict error signature.
+     * It replaces an inference that turned out to be unsound. `strictRefusalReasons` alone records
+     * only refusals, so an empty row meant "strict held" OR "this adapter never tries" — and a prod
+     * run recorded zero refusals while a call returned an array-typed field as a string, which a
+     * grammar makes impossible. The absence proved nothing, because the deployed API had no way to
+     * write the field at all.
+     *
+     * Absent on rows written before this field existed; that absence is itself diagnostic (the API
+     * predates the change). Existing readers that only look at the fields above are unaffected.
+     */
+    strictStatus?: StrictStatus;
+    /**
+     * Why this call went out without `strict`, when a strict-capable adapter refused the schema. The
+     * detail behind `strictStatus: 'refused' | 'compileRejected'` — read `strictStatus` for whether
+     * it was enforced, this for why not.
      *
      * Existing readers that only look at the fields above are unaffected.
      */
@@ -2817,6 +2851,8 @@ interface LLMUsageData {
     outputValidationError?: string;
     /** Raw model output that failed validation — JSON-stringified, truncated, truncation marked inline */
     unvalidatedOutput?: string;
+    /** What happened to `strict` on this call — set by every server adapter, refusal or not */
+    strictStatus?: StrictStatus;
     /** Why the call went out unstrict, when a strict-capable adapter refused the schema */
     strictRefusalReasons?: string[];
 }

package/dist/test-utils/index.d.ts

@@ -335,6 +335,15 @@ interface ModelConfig {
     modelOptions?: ModelSpecificOptions;
 }
 
+/**
+ * What happened to `strict` on a request, recorded per call rather than inferred.
+ *
+ * `applied` and `notAttempted` are the two states that a refusal-only field cannot tell apart —
+ * both leave `strictRefusalReasons` empty. Recording the verdict positively is what makes "was
+ * this agent's output actually enforced?" answerable from an `ai_calls` row.
+ */
+type StrictStatus = 'applied' | 'refused' | 'compileRejected' | 'notAttempted';
+
 declare const ResourceGovernanceStatusSchema: z.ZodEnum<{
     active: "active";
     deprecated: "deprecated";
@@ -862,6 +871,7 @@ interface WorkflowDefinition {
  * Generic LLM Types
  * Universal interfaces for LLM interaction across all resource types
  */
+
 /**
  * Standard chat message format
  * Compatible with OpenAI, Anthropic, and other providers
@@ -895,15 +905,30 @@ interface LLMGenerateResponse<T = unknown> {
         totalTokens: number;
     };
     cost?: number;
+    /**
+     * What actually happened to `strict` on the request that produced this response. Every server
+     * adapter sets it on every call, so the value is a statement rather than an inference:
+     *
+     * - `applied` — the request carried `strict: true` and the grammar was in effect
+     * - `refused` — `toStrictSchema` could not express the schema, so the request went out unstrict
+     * - `compileRejected` — the schema passed `toStrictSchema` but the provider's grammar compiler
+     *   rejected it at request time, and the call was retried unstrict
+     * - `notAttempted` — this adapter does not send strict at all (OpenAI, Google, OpenRouter)
+     *
+     * This exists because `strictRefusalReasons` alone cannot answer the question. Its absence means
+     * "strict held" OR "nothing ever tried", and a prod run that recorded zero refusals while
+     * returning an array-typed field as a string is exactly the case where the difference matters.
+     *
+     * Internal-only, like `usage` — `UniversalLLMAdapter` lifts it onto the `ai_calls` row and
+     * strips it before the response reaches callers.
+     */
+    strictStatus?: StrictStatus;
     /**
      * Why this call went out WITHOUT `strict`, on an adapter that tried to send it with one.
      *
-     * Present only on a refusal, so absence means either "strict was in effect" or "this adapter
-     * does not attempt strict at all" — the two are distinguished by which adapter answered, not by
-     * this field. `toStrictSchema` already computes these reasons and, until now, nothing consumed
-     * them at the call site: an unstrict call was indistinguishable from a strict one anywhere
-     * outside a dev-only flow log. That invisibility is what let every tenant run unstrict against a
-     * strict-capable API for as long as it took someone to recognise a pre-strict error signature.
+     * The detail behind a `refused` / `compileRejected` `strictStatus` — the short, stable reason
+     * strings `toStrictSchema` computes. Read `strictStatus` to answer "was it enforced"; read this
+     * to answer "why not".
      *
      * Internal-only, like `usage` — `UniversalLLMAdapter` lifts it onto the `ai_calls` row and
      * strips it before the response reaches callers.
@@ -10322,15 +10347,24 @@ interface BaseAICall {
      */
     unvalidatedOutput?: string;
     /**
-     * Why this call went out without `strict` structured output, on an adapter that tried to send it
-     * with one. Present ONLY on a refusal — its absence on a row from a strict-capable adapter means
-     * strict was in effect.
+     * What happened to `strict` structured output on this call — `applied`, `refused`,
+     * `compileRejected`, or `notAttempted`. Every server adapter sets it, so this is the field that
+     * answers "is this agent's output actually being enforced?" without reading source.
      *
-     * This is the row that answers "is this agent's output actually being enforced?" without reading
-     * source. Counting rows that carry it, per resource, is the refusal count: a redeployed agent on
-     * a current bundle should read zero. It exists because the previous answer was a dev-only flow
-     * log, which meant production had no answer — and every sync-managed tenant ran unstrict against
-     * a strict-capable API until a 14-turn session surfaced a pre-strict error signature.
+     * It replaces an inference that turned out to be unsound. `strictRefusalReasons` alone records
+     * only refusals, so an empty row meant "strict held" OR "this adapter never tries" — and a prod
+     * run recorded zero refusals while a call returned an array-typed field as a string, which a
+     * grammar makes impossible. The absence proved nothing, because the deployed API had no way to
+     * write the field at all.
+     *
+     * Absent on rows written before this field existed; that absence is itself diagnostic (the API
+     * predates the change). Existing readers that only look at the fields above are unaffected.
+     */
+    strictStatus?: StrictStatus;
+    /**
+     * Why this call went out without `strict`, when a strict-capable adapter refused the schema. The
+     * detail behind `strictStatus: 'refused' | 'compileRejected'` — read `strictStatus` for whether
+     * it was enforced, this for why not.
      *
      * Existing readers that only look at the fields above are unaffected.
      */
@@ -10390,6 +10424,8 @@ interface LLMUsageData {
     outputValidationError?: string;
     /** Raw model output that failed validation — JSON-stringified, truncated, truncation marked inline */
     unvalidatedOutput?: string;
+    /** What happened to `strict` on this call — set by every server adapter, refusal or not */
+    strictStatus?: StrictStatus;
     /** Why the call went out unstrict, when a strict-capable adapter refused the schema */
     strictRefusalReasons?: string[];
 }

package/dist/test-utils/index.js

@@ -4461,26 +4461,24 @@ function resolveSecurityLevel(config2) {
 
 // ../core/src/execution/engine/agent/reasoning/prompt-sections/base-actions.ts
 function buildBaseActionsPrompt(includeMessageAction, includeNavigateKnowledge) {
-  let actionCount = 2;
-  const actions = ["1. tool-call (call a tool)"];
-  if (includeMessageAction) {
-    actionCount++;
-    actions.push(`${actionCount}. message (send message to user)`);
-  }
+  const actionNames = ["tool-call (call a tool)"];
   if (includeNavigateKnowledge) {
-    actionCount++;
-    actions.push(`${actionCount}. navigate-knowledge (load knowledge node)`);
+    actionNames.push("navigate-knowledge (load knowledge node)");
   }
-  actions.push(`${actionCount + 1}. complete (finish task)`);
-  actionCount++;
-  const actionsList = actions.join("\n");
+  actionNames.push("complete (finish task)");
+  const actionsList = actionNames.map((name, index2) => `${index2 + 1}. ${name}`).join("\n");
+  const actionCount = actionNames.length;
   return `# CORE AGENT INSTRUCTIONS
 
-You are an AI agent. Your response is captured as structured output. Two fields are required on
+You are an AI agent. Your response is captured as structured output. ${includeMessageAction ? "Three fields are required" : "Two fields are required"} on
 every response:
 
 - **reasoning** -- your thought process, as plain prose.
-- **nextActions** -- the actions to execute.
+- **nextActions** -- the actions to execute.${includeMessageAction ? `
+- **message** -- your reply to the user, as plain prose. This is the ONLY field the user sees.
+  Whatever you decide to say, it goes here. Use an empty string only when this iteration just calls
+  tools and you genuinely have nothing to tell the user yet -- an empty message ends the turn in
+  silence.` : ""}
 
 **reasoning is prose, not JSON.** Do not write field names, braces, or a response object inside it,
 and never continue the response envelope in the reasoning text -- nextActions is a separate field
@@ -4491,14 +4489,16 @@ that you fill separately. A response carrying reasoning alone is discarded and r
 ${actionsList}
 
 **Formats:**
-- tool-call: { "type": "tool-call", "id": "unique-id", "name": "tool_name", "input": {...} }${includeMessageAction ? `
-- message: { "type": "message", "text": "Your message" }` : ""}${includeNavigateKnowledge ? `
+- tool-call: { "type": "tool-call", "id": "unique-id", "name": "tool_name", "input": {...} }${includeNavigateKnowledge ? `
 - navigate-knowledge: { "type": "navigate-knowledge", "id": "unique-id", "nodeId": "node-name" }` : ""}
 - complete: { "type": "complete" }
-
+${includeMessageAction ? `
+Talking to the user is NOT an action. There is no message action -- put your reply in the
+**message** field beside nextActions.
+` : ""}
 ## Execution Flow
 
-1. You respond with reasoning + actions
+1. You respond with reasoning + actions${includeMessageAction ? " + your message to the user" : ""}
 2. System executes actions (tool calls run **in parallel**)
 3. Tool results automatically appear in your next iteration
 4. You see results and decide: more work needed? Or complete?
@@ -4510,10 +4510,10 @@ ${actionsList}
 - Dependent operations need separate iterations (tool B needs tool A's result)
 - "complete" cannot mix with navigate-knowledge${includeNavigateKnowledge ? "" : " (when available)"}
 - "complete" can mix with tool-call when the tool is a fire-and-forget side effect and you do not need its result before ending${includeMessageAction ? `
-- Always send at least one message before completing
-- Send at most one message per iteration. Multiple messages in a session turn are collapsed into one visible assistant message.
-- When you have your answer, send message + complete in the SAME iteration. Never send a message alone then complete in a later iteration.
-- Never repeat or rephrase the same answer across iterations. One clear answer, then complete.` : ""}
+- Always fill message before completing -- it is the only field the user sees, and completing with it empty ends the turn in silence
+- message holds one reply. Write the whole reply in it; do not split a reply across iterations
+- When you have your answer, put it in message and include complete in the SAME iteration. Never reply on one iteration then complete on a later one
+- Never repeat or rephrase the same answer across iterations. One clear answer, then complete` : ""}
 
 **Use "complete" when:**
 - Task finished successfully
@@ -4527,27 +4527,27 @@ ${actionsList}
 
 ## Examples
 
-Each example shows the two field values, not a JSON document to copy.
+Each example shows the field values, not a JSON document to copy.
 
 ### Example 1: Simple Task (No Tools)
-- reasoning: Simple greeting, no tools needed.
-- nextActions: [${includeMessageAction ? '{ "type": "message", "text": "Hi! How can I help?" }, ' : ""}{ "type": "complete" }]
+- reasoning: Simple greeting, no tools needed.${includeMessageAction ? "\n- message: Hi! How can I help?" : ""}
+- nextActions: [{ "type": "complete" }]
 
 ### Example 2: Tool Usage (Two Iterations)
 
 **Iteration 1 - Call tool (NO complete - waiting for results):**
-- reasoning: User asked for time. Calling get_time tool.
-- nextActions: [${includeMessageAction ? '{ "type": "message", "text": "Checking the time..." }, ' : ""}{ "type": "tool-call", "id": "t1", "name": "get_time", "input": { "timezone": "UTC" } }]
+- reasoning: User asked for time. Calling get_time tool.${includeMessageAction ? "\n- message: Checking the time..." : ""}
+- nextActions: [{ "type": "tool-call", "id": "t1", "name": "get_time", "input": { "timezone": "UTC" } }]
 
 **Iteration 2 - Tool result received, now complete:**
-- reasoning: Got time result: 12:00 PM UTC. Task done.
-- nextActions: [${includeMessageAction ? '{ "type": "message", "text": "The current time is 12:00 PM UTC." }, ' : ""}{ "type": "complete" }]
+- reasoning: Got time result: 12:00 PM UTC. Task done.${includeMessageAction ? "\n- message: The current time is 12:00 PM UTC." : ""}
+- nextActions: [{ "type": "complete" }]
 
 ### Example 3: Parallel Tool Calls (Independent Operations)
 When tools don't depend on each other, batch them for faster execution.
 
-- reasoning: User wants time AND weather. Independent operations - calling both in parallel.
-- nextActions: [${includeMessageAction ? '{ "type": "message", "text": "Getting time and weather..." }, ' : ""}{ "type": "tool-call", "id": "t1", "name": "get_time", "input": {} }, { "type": "tool-call", "id": "w1", "name": "get_weather", "input": { "city": "NYC" } }]
+- reasoning: User wants time AND weather. Independent operations - calling both in parallel.${includeMessageAction ? "\n- message: Getting time and weather..." : ""}
+- nextActions: [{ "type": "tool-call", "id": "t1", "name": "get_time", "input": {} }, { "type": "tool-call", "id": "w1", "name": "get_weather", "input": { "city": "NYC" } }]
 
 ### Example 4: Dependent Operations (Separate Iterations Required)
 
@@ -4557,8 +4557,8 @@ When tools don't depend on each other, batch them for faster execution.
 Problem: update_user needs userId from search_user result!
 
 **\u2705 CORRECT - Iteration 1 (get the dependency):**
-- reasoning: Need to find user first before updating.
-- nextActions: [${includeMessageAction ? '{ "type": "message", "text": "Looking up user..." }, ' : ""}{ "type": "tool-call", "id": "1", "name": "search_user", "input": { "email": "user@example.com" } }]
+- reasoning: Need to find user first before updating.${includeMessageAction ? "\n- message: Looking up user..." : ""}
+- nextActions: [{ "type": "tool-call", "id": "1", "name": "search_user", "input": { "email": "user@example.com" } }]
 
 **\u2705 CORRECT - Iteration 2 (use the result):**
 - reasoning: Found userId: user_123. Now can update.
@@ -4641,7 +4641,7 @@ function buildToolsPrompt(tools) {
   section += '{\n  "type": "tool-call",\n  "id": "unique-id",\n  "name": "tool-name",\n  "input": { /* tool input matching schema */ }\n}\n\n';
   section += "**IMPORTANT RULES:**\n";
   section += '1. "complete" CANNOT mix with navigate-knowledge actions in the same response\n';
-  section += '2. "complete" CAN mix with message - always pair your final message with complete in the same iteration\n';
+  section += '2. The "message" field CAN be filled on the same response that completes - always pair your final message with complete in the same iteration\n';
   section += '3. "complete" CAN mix with fire-and-forget tool-call actions when you do not need their results\n';
   section += "4. To use tools and inspect their results, return ONLY tool-call actions, then wait for results in the next iteration\n";
   section += "5. After receiving tool results, you can either call more tools OR complete with final answer\n";
@@ -5204,6 +5204,7 @@ var MemoryOperationsSchema = z.object({
 });
 var AgentIterationOutputSchema = z.object({
   reasoning: z.string(),
+  message: z.string().optional(),
   memoryOps: MemoryOperationsSchema.optional(),
   nextActions: z.array(AgentActionSchema)
 });
@@ -5252,6 +5253,17 @@ ${memory.framing}` : memory.framing },
   }
   return messages;
 }
+function withSynthesizedMessage(nextActions, message) {
+  const text = message?.trim();
+  if (!text) {
+    return nextActions;
+  }
+  const alreadyPresent = nextActions.some((action) => action.type === "message" && action.text.trim() === text);
+  if (alreadyPresent) {
+    return nextActions;
+  }
+  return [{ type: "message", text }, ...nextActions];
+}
 async function callLLMForAgentIteration(adapter, request) {
   validateTokenConfiguration(request.model, request.constraints.maxOutputTokens);
   const messages = buildAgentMessages(
@@ -5289,7 +5301,7 @@ async function callLLMForAgentIteration(adapter, request) {
     return {
       reasoning: validated.reasoning,
       memoryOps: validated.memoryOps,
-      nextActions: validated.nextActions
+      nextActions: withSynthesizedMessage(validated.nextActions, validated.message)
     };
   } catch (error) {
     flowLog("agent.iteration.validationFailed", {
@@ -5297,6 +5309,7 @@ async function callLLMForAgentIteration(adapter, request) {
       missingRequired: ["reasoning", "nextActions"].filter(
         (k2) => !(typeof response.output === "object" && response.output !== null && k2 in response.output)
       ),
+      messagePresent: typeof response.output === "object" && response.output !== null && typeof response.output.message === "string",
       zodIssues: error instanceof ZodError ? error.issues.map((i) => ({ path: i.path.join("."), code: i.code })) : void 0
     });
     throw new AgentOutputValidationError("Agent iteration output validation failed", {
@@ -5374,17 +5387,6 @@ function buildIterationResponseSchema(tools, includeMessageAction, includeNaviga
     required: ["type"],
     additionalProperties: false
   });
-  if (includeMessageAction) {
-    actionSchemas.push({
-      type: "object",
-      properties: {
-        type: { type: "string", enum: ["message"] },
-        text: { type: "string" }
-      },
-      required: ["type", "text"],
-      additionalProperties: false
-    });
-  }
   if (includeNavigateKnowledge) {
     actionSchemas.push({
       type: "object",
@@ -5403,9 +5405,15 @@ function buildIterationResponseSchema(tools, includeMessageAction, includeNaviga
       items: {
         anyOf: actionSchemas
       }
-    },
-    reasoning: { type: "string", description: "Your reasoning process" }
+    }
   };
+  if (includeMessageAction) {
+    properties.message = {
+      type: "string",
+      description: "Your reply to the user, as plain prose. This is the ONLY field the user sees. Use an empty string only when this iteration just calls tools and you have nothing to say yet."
+    };
+  }
+  properties.reasoning = { type: "string", description: "Your reasoning process" };
   if (includeMemoryOps) {
     properties.memoryOps = {
       type: "object",
@@ -5436,7 +5444,7 @@ function buildIterationResponseSchema(tools, includeMessageAction, includeNaviga
   return {
     type: "object",
     properties,
-    required: ["nextActions", "reasoning"],
+    required: includeMessageAction ? ["nextActions", "message", "reasoning"] : ["nextActions", "reasoning"],
     additionalProperties: false
   };
 }

package/dist/worker/index.js

@@ -2583,26 +2583,24 @@ function resolveSecurityLevel(config) {
 
 // ../core/src/execution/engine/agent/reasoning/prompt-sections/base-actions.ts
 function buildBaseActionsPrompt(includeMessageAction, includeNavigateKnowledge) {
-  let actionCount = 2;
-  const actions = ["1. tool-call (call a tool)"];
-  if (includeMessageAction) {
-    actionCount++;
-    actions.push(`${actionCount}. message (send message to user)`);
-  }
+  const actionNames = ["tool-call (call a tool)"];
   if (includeNavigateKnowledge) {
-    actionCount++;
-    actions.push(`${actionCount}. navigate-knowledge (load knowledge node)`);
+    actionNames.push("navigate-knowledge (load knowledge node)");
   }
-  actions.push(`${actionCount + 1}. complete (finish task)`);
-  actionCount++;
-  const actionsList = actions.join("\n");
+  actionNames.push("complete (finish task)");
+  const actionsList = actionNames.map((name, index) => `${index + 1}. ${name}`).join("\n");
+  const actionCount = actionNames.length;
   return `# CORE AGENT INSTRUCTIONS
 
-You are an AI agent. Your response is captured as structured output. Two fields are required on
+You are an AI agent. Your response is captured as structured output. ${includeMessageAction ? "Three fields are required" : "Two fields are required"} on
 every response:
 
 - **reasoning** -- your thought process, as plain prose.
-- **nextActions** -- the actions to execute.
+- **nextActions** -- the actions to execute.${includeMessageAction ? `
+- **message** -- your reply to the user, as plain prose. This is the ONLY field the user sees.
+  Whatever you decide to say, it goes here. Use an empty string only when this iteration just calls
+  tools and you genuinely have nothing to tell the user yet -- an empty message ends the turn in
+  silence.` : ""}
 
 **reasoning is prose, not JSON.** Do not write field names, braces, or a response object inside it,
 and never continue the response envelope in the reasoning text -- nextActions is a separate field
@@ -2613,14 +2611,16 @@ that you fill separately. A response carrying reasoning alone is discarded and r
 ${actionsList}
 
 **Formats:**
-- tool-call: { "type": "tool-call", "id": "unique-id", "name": "tool_name", "input": {...} }${includeMessageAction ? `
-- message: { "type": "message", "text": "Your message" }` : ""}${includeNavigateKnowledge ? `
+- tool-call: { "type": "tool-call", "id": "unique-id", "name": "tool_name", "input": {...} }${includeNavigateKnowledge ? `
 - navigate-knowledge: { "type": "navigate-knowledge", "id": "unique-id", "nodeId": "node-name" }` : ""}
 - complete: { "type": "complete" }
-
+${includeMessageAction ? `
+Talking to the user is NOT an action. There is no message action -- put your reply in the
+**message** field beside nextActions.
+` : ""}
 ## Execution Flow
 
-1. You respond with reasoning + actions
+1. You respond with reasoning + actions${includeMessageAction ? " + your message to the user" : ""}
 2. System executes actions (tool calls run **in parallel**)
 3. Tool results automatically appear in your next iteration
 4. You see results and decide: more work needed? Or complete?
@@ -2632,10 +2632,10 @@ ${actionsList}
 - Dependent operations need separate iterations (tool B needs tool A's result)
 - "complete" cannot mix with navigate-knowledge${includeNavigateKnowledge ? "" : " (when available)"}
 - "complete" can mix with tool-call when the tool is a fire-and-forget side effect and you do not need its result before ending${includeMessageAction ? `
-- Always send at least one message before completing
-- Send at most one message per iteration. Multiple messages in a session turn are collapsed into one visible assistant message.
-- When you have your answer, send message + complete in the SAME iteration. Never send a message alone then complete in a later iteration.
-- Never repeat or rephrase the same answer across iterations. One clear answer, then complete.` : ""}
+- Always fill message before completing -- it is the only field the user sees, and completing with it empty ends the turn in silence
+- message holds one reply. Write the whole reply in it; do not split a reply across iterations
+- When you have your answer, put it in message and include complete in the SAME iteration. Never reply on one iteration then complete on a later one
+- Never repeat or rephrase the same answer across iterations. One clear answer, then complete` : ""}
 
 **Use "complete" when:**
 - Task finished successfully
@@ -2649,27 +2649,27 @@ ${actionsList}
 
 ## Examples
 
-Each example shows the two field values, not a JSON document to copy.
+Each example shows the field values, not a JSON document to copy.
 
 ### Example 1: Simple Task (No Tools)
-- reasoning: Simple greeting, no tools needed.
-- nextActions: [${includeMessageAction ? '{ "type": "message", "text": "Hi! How can I help?" }, ' : ""}{ "type": "complete" }]
+- reasoning: Simple greeting, no tools needed.${includeMessageAction ? "\n- message: Hi! How can I help?" : ""}
+- nextActions: [{ "type": "complete" }]
 
 ### Example 2: Tool Usage (Two Iterations)
 
 **Iteration 1 - Call tool (NO complete - waiting for results):**
-- reasoning: User asked for time. Calling get_time tool.
-- nextActions: [${includeMessageAction ? '{ "type": "message", "text": "Checking the time..." }, ' : ""}{ "type": "tool-call", "id": "t1", "name": "get_time", "input": { "timezone": "UTC" } }]
+- reasoning: User asked for time. Calling get_time tool.${includeMessageAction ? "\n- message: Checking the time..." : ""}
+- nextActions: [{ "type": "tool-call", "id": "t1", "name": "get_time", "input": { "timezone": "UTC" } }]
 
 **Iteration 2 - Tool result received, now complete:**
-- reasoning: Got time result: 12:00 PM UTC. Task done.
-- nextActions: [${includeMessageAction ? '{ "type": "message", "text": "The current time is 12:00 PM UTC." }, ' : ""}{ "type": "complete" }]
+- reasoning: Got time result: 12:00 PM UTC. Task done.${includeMessageAction ? "\n- message: The current time is 12:00 PM UTC." : ""}
+- nextActions: [{ "type": "complete" }]
 
 ### Example 3: Parallel Tool Calls (Independent Operations)
 When tools don't depend on each other, batch them for faster execution.
 
-- reasoning: User wants time AND weather. Independent operations - calling both in parallel.
-- nextActions: [${includeMessageAction ? '{ "type": "message", "text": "Getting time and weather..." }, ' : ""}{ "type": "tool-call", "id": "t1", "name": "get_time", "input": {} }, { "type": "tool-call", "id": "w1", "name": "get_weather", "input": { "city": "NYC" } }]
+- reasoning: User wants time AND weather. Independent operations - calling both in parallel.${includeMessageAction ? "\n- message: Getting time and weather..." : ""}
+- nextActions: [{ "type": "tool-call", "id": "t1", "name": "get_time", "input": {} }, { "type": "tool-call", "id": "w1", "name": "get_weather", "input": { "city": "NYC" } }]
 
 ### Example 4: Dependent Operations (Separate Iterations Required)
 
@@ -2679,8 +2679,8 @@ When tools don't depend on each other, batch them for faster execution.
 Problem: update_user needs userId from search_user result!
 
 **\u2705 CORRECT - Iteration 1 (get the dependency):**
-- reasoning: Need to find user first before updating.
-- nextActions: [${includeMessageAction ? '{ "type": "message", "text": "Looking up user..." }, ' : ""}{ "type": "tool-call", "id": "1", "name": "search_user", "input": { "email": "user@example.com" } }]
+- reasoning: Need to find user first before updating.${includeMessageAction ? "\n- message: Looking up user..." : ""}
+- nextActions: [{ "type": "tool-call", "id": "1", "name": "search_user", "input": { "email": "user@example.com" } }]
 
 **\u2705 CORRECT - Iteration 2 (use the result):**
 - reasoning: Found userId: user_123. Now can update.
@@ -2763,7 +2763,7 @@ function buildToolsPrompt(tools) {
   section += '{\n  "type": "tool-call",\n  "id": "unique-id",\n  "name": "tool-name",\n  "input": { /* tool input matching schema */ }\n}\n\n';
   section += "**IMPORTANT RULES:**\n";
   section += '1. "complete" CANNOT mix with navigate-knowledge actions in the same response\n';
-  section += '2. "complete" CAN mix with message - always pair your final message with complete in the same iteration\n';
+  section += '2. The "message" field CAN be filled on the same response that completes - always pair your final message with complete in the same iteration\n';
   section += '3. "complete" CAN mix with fire-and-forget tool-call actions when you do not need their results\n';
   section += "4. To use tools and inspect their results, return ONLY tool-call actions, then wait for results in the next iteration\n";
   section += "5. After receiving tool results, you can either call more tools OR complete with final answer\n";
@@ -3296,6 +3296,7 @@ var MemoryOperationsSchema = z.object({
 });
 var AgentIterationOutputSchema = z.object({
   reasoning: z.string(),
+  message: z.string().optional(),
   memoryOps: MemoryOperationsSchema.optional(),
   nextActions: z.array(AgentActionSchema)
 });
@@ -3344,6 +3345,17 @@ ${memory.framing}` : memory.framing },
   }
   return messages;
 }
+function withSynthesizedMessage(nextActions, message) {
+  const text = message?.trim();
+  if (!text) {
+    return nextActions;
+  }
+  const alreadyPresent = nextActions.some((action) => action.type === "message" && action.text.trim() === text);
+  if (alreadyPresent) {
+    return nextActions;
+  }
+  return [{ type: "message", text }, ...nextActions];
+}
 async function callLLMForAgentIteration(adapter, request) {
   validateTokenConfiguration(request.model, request.constraints.maxOutputTokens);
   const messages = buildAgentMessages(
@@ -3381,7 +3393,7 @@ async function callLLMForAgentIteration(adapter, request) {
     return {
       reasoning: validated.reasoning,
       memoryOps: validated.memoryOps,
-      nextActions: validated.nextActions
+      nextActions: withSynthesizedMessage(validated.nextActions, validated.message)
     };
   } catch (error) {
     flowLog("agent.iteration.validationFailed", {
@@ -3389,6 +3401,7 @@ async function callLLMForAgentIteration(adapter, request) {
       missingRequired: ["reasoning", "nextActions"].filter(
         (k) => !(typeof response.output === "object" && response.output !== null && k in response.output)
       ),
+      messagePresent: typeof response.output === "object" && response.output !== null && typeof response.output.message === "string",
       zodIssues: error instanceof ZodError ? error.issues.map((i) => ({ path: i.path.join("."), code: i.code })) : void 0
     });
     throw new AgentOutputValidationError("Agent iteration output validation failed", {
@@ -3466,17 +3479,6 @@ function buildIterationResponseSchema(tools, includeMessageAction, includeNaviga
     required: ["type"],
     additionalProperties: false
   });
-  if (includeMessageAction) {
-    actionSchemas.push({
-      type: "object",
-      properties: {
-        type: { type: "string", enum: ["message"] },
-        text: { type: "string" }
-      },
-      required: ["type", "text"],
-      additionalProperties: false
-    });
-  }
   if (includeNavigateKnowledge) {
     actionSchemas.push({
       type: "object",
@@ -3495,9 +3497,15 @@ function buildIterationResponseSchema(tools, includeMessageAction, includeNaviga
       items: {
         anyOf: actionSchemas
       }
-    },
-    reasoning: { type: "string", description: "Your reasoning process" }
+    }
   };
+  if (includeMessageAction) {
+    properties.message = {
+      type: "string",
+      description: "Your reply to the user, as plain prose. This is the ONLY field the user sees. Use an empty string only when this iteration just calls tools and you have nothing to say yet."
+    };
+  }
+  properties.reasoning = { type: "string", description: "Your reasoning process" };
   if (includeMemoryOps) {
     properties.memoryOps = {
       type: "object",
@@ -3528,7 +3536,7 @@ function buildIterationResponseSchema(tools, includeMessageAction, includeNaviga
   return {
     type: "object",
     properties,
-    required: ["nextActions", "reasoning"],
+    required: includeMessageAction ? ["nextActions", "message", "reasoning"] : ["nextActions", "reasoning"],
     additionalProperties: false
   };
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@elevasis/sdk",
-  "version": "1.41.0",
+  "version": "1.42.0",
   "description": "SDK for building Elevasis organization resources",
   "type": "module",
   "bin": {

package/reference/claude-config/sync-notes/2026-07-28-agent-reply-is-its-own-field.md

@@ -0,0 +1,84 @@
+# The agent's reply to the user is now its own field
+
+## Why this note exists
+
+**Your agents' user-facing text was being silently corrupted, and no layer could catch it.**
+
+Measured across three 14-turn production sessions on 2026-07-28: 42 of 42 turns passed, and **20
+corruption sites landed across 12 of the 42 replies — 28.6%**. The model emits a JSON escape
+sequence for an em-dash and then completes it with the next letter of the sentence, so
+`Hold on — red-line for me` becomes `Hold on \red-line for me`. That parses as valid JSON, satisfies
+the response schema, and passes validation. There is no error state, no retry, and no provider-side
+fix to wait for. The characters are simply gone from the stored transcript.
+
+The cause is where the text sat in the schema, not the text itself. The reply used to be one variant
+of an `anyOf` union nested inside the `nextActions` array. In the very same responses, the flat
+top-level `reasoning` string carried **33 em-dashes with zero corruption** while the nested reply
+text carried **59 em-dashes with 20 corruption sites** — and `reasoning` is the longer field.
+
+The reply is now a flat top-level `message` property, declared beside `reasoning` rather than nested
+inside the actions array. Re-measured over a fresh multi-turn session: **42 em-dashes, zero
+corruption.**
+
+**This supersedes the two-field description in `2026-07-27-agent-strict-output-and-turn-drift.md`.**
+That note described the iteration response as `nextActions` then `reasoning`. It is now three
+fields, in this order: `nextActions`, `message`, `reasoning`. The ordering rationale from that note
+is unchanged and still holds — `reasoning` stays last so the actions and the reply are already on the
+wire before any mid-response drift can start.
+
+**`message` is required for session-capable agents.** This is not a detail you can ignore. When the
+field shipped as optional, the model filled it **zero times in three turns** and those turns produced
+no user-facing message at all. Under grammar-constrained sampling the model fills keys in declaration
+order, so `nextActions` is chosen before the model has reasoned about the reply, `complete` is the
+cheapest legal action, and a skippable `message` then gets skipped. Making it required costs nothing:
+an empty or whitespace-only value is suppressed and produces no message bubble.
+
+## Applies to
+
+- **Every `sessionCapable: true` agent.** `message` is the only field the user sees, so this is the
+  field that was being damaged.
+- **Agents on Anthropic models**, where the enforced-schema path is active. On the unenforced path
+  the platform still accepts a message delivered the old way, as an entry in the actions list, so
+  nothing breaks mid-transition.
+- **Anything that reads stored assistant messages** — a transcript, an export, a summarizer, a
+  downstream workflow. Already-stored text is not repaired by this change; see below.
+- **No agent definition changes are required.** You do not edit your agents. The shape lives in the
+  runtime your bundle carries.
+
+## Required actions
+
+1. **Take the `@elevasis/sdk` baseline bump** this train propagates, then reinstall in `operations/`
+   so the new worker bundle is present.
+2. **Redeploy your operations bundle.** This is the step that actually closes the defect. The
+   response schema is emitted by the runtime inlined into your deployed bundle, so an existing
+   deployment keeps emitting the old nested shape — and keeps corrupting replies — until it is
+   redeployed:
+
+   ```bash
+   pnpm -C operations exec elevasis-sdk deploy --prod
+   ```
+
+   A platform-side deploy does not fix this for you, and neither does the reinstall on its own.
+
+3. **If you read or display stored assistant text, do not treat old records as clean.** Nothing is
+   rewritten retroactively. Transcripts written before your redeploy keep whatever corruption they
+   already have.
+
+## Verification
+
+- Run a session and prompt for a reply likely to contain an em-dash — asking the agent to summarize
+  something in a couple of sentences is usually enough. Confirm the reply arrives, and read it: the
+  signature failure is a missing letter immediately after where punctuation belonged
+  (`Hold on \red-line`), not a visible error.
+- **Confirm every turn produced an assistant message at all.** A turn that completes with no message
+  is the symptom of a bundle that has the flat field but not the required flag — that combination
+  only exists in an unreleased build, but it is the one failure worth ruling out explicitly.
+- Check the observability rows for an execution: iteration calls should still record the enforced
+  path with no fallback reasons. This change does not push the schema off it.
+
+## Not handled by /git-sync
+
+- **The redeploy.** `/git-sync` commits and pushes the propagated dependency baseline. The corruption
+  continues on your deployed agents until you run action 2 above.
+- **Repairing existing transcripts.** No backfill is performed, and none is possible — the dropped
+  characters were never received.