Artemis | Channels | Content Updates

agent-platform/abl/reference/agent-declaration.mdx

@@ -498,6 +498,33 @@ EXECUTION:
 
 <Note>Every key also accepts its camelCase spelling (`greetingStyle`, `confirmCriticalValues`, `spellSensitiveValues`). This delivery policy is separate from the per-output [scoped `barge_in`](/agent-platform/abl/reference/flow#scoped-barge-in) policy.</Note>
 
+### Voice instructions and grounding guards
+
+`EXECUTION.voice.instructions` sets the agent's spoken-style rules and fills `## Voice Delivery Instructions` in the prompt.
+
+```yaml
+EXECUTION:
+  voice:
+    instructions: "Speak warmly in plain sentences. No lists. One or two short sentences per answer."
+    grounding_guards:
+      tool_arguments: true
+      reply_figures: true
+      reply_repairs: true
+```
+
+| Field | Type | Default | Description |
+|-------|------|---------|-------------|
+| `instructions` | `string` | The platform's own voice rules (plain speech, no markdown, no emoji, no numbered lists) | **Replaces** the platform's default voice formatting rules, not just adds to them. |
+| `grounding_guards.tool_arguments` | `boolean` | `false` | Refuses a tool call whose arguments (an ID, say) can't be traced back to a tool result or session value already in the turn. |
+| `grounding_guards.reply_figures` | `boolean` | `false` | Drops a spoken number or figure from the reply when no tool result or session value supports it. This only catches text that hasn't started playing yet. |
+| `grounding_guards.reply_repairs` | `boolean` | `false` | Allows one repair pass when the model promises an action (sends a confirmation, say) but the matching tool call never actually ran. |
+
+<Warning>Because `instructions` **replaces** the platform voice rules rather than extending them, its own "plain speech, no lists" wording is what keeps the agent from reading out bullet points or markdown on a voice channel -- restate that in your own text. An agent with a custom `SYSTEM_PROMPT:` doesn't get the default voice formatting rules either, for the same reason: state spoken-style rules in the prompt text itself, or in `EXECUTION.voice.instructions`.</Warning>
+
+All three `grounding_guards` default to off and apply to voice channels only. `reply_figures` and `reply_repairs` work against values already present in the turn's tool results and session state, so a tool whose `MODEL_CONTEXT` strips a figure the model later needs to confirm will have that figure dropped from the spoken reply too.
+
+See [Voice agents](/agent-platform/channels/voice) for how these settings differ between pipeline and realtime voice, and [Voice coordinator policy](#voice-coordinator-policy) above for the realtime-only delivery-tone settings.
+
 ### Complete execution example
 
 ```yaml expandable=true

agent-platform/abl/reference/configuration-reference.mdx

@@ -22,7 +22,7 @@ ABL settings take effect in new conversations once saved, or once published and
 | [`EXECUTION.inline_gather`](/agent-platform/abl-reference/agent-declaration#configuration-properties) | Agent ABL | `false` (on in the voice profile) | `## Information Collection` instead of the `GATHER` list |
 | [`EXECUTION.compaction.*`](/agent-platform/context-compaction#size-limits-and-compaction) | Agent ABL | See [Context size, compaction, and budgets](/agent-platform/context-compaction) | Tool results, earlier turns, and `## Current Context` budgets |
 | `EXECUTION.models.summarization` | Agent ABL | Project tier | The model used for tool-result summaries |
-| `EXECUTION.voice.instructions` | Agent ABL | -- | `## Voice Delivery Instructions` and voice formatting rules |
+| [`EXECUTION.voice.instructions`](/agent-platform/abl-reference/agent-declaration#voice-instructions-and-grounding-guards) | Agent ABL | -- | `## Voice Delivery Instructions` and voice formatting rules |
 | `EXECUTION.guardrail_builtins` | Agent ABL | `false` | Whether a guardrail check can read `content`, `session_state`, and `tool_results` |
 | [Tool `MODEL_CONTEXT`](/agent-platform/abl-reference/tools#model_context-on-a-tool-result) (`FIELDS` / `TEMPLATE`) | Tool ABL | -- | What the model sees of a tool result, now and later |
 | [Response `MODEL_CONTEXT`](/agent-platform/abl-reference/flow#model_context-on-a-response) | Hook `RESPOND`, `COMPLETE`, `FLOW` step | -- | What the history records for a rich response |

agent-platform/abl/reference/tools.mdx

@@ -1148,6 +1148,40 @@ TOOLS:
 
 <Note>When neither `effect` nor `hints.side_effects` is declared, the runtime infers one: for an HTTP tool, `GET`, `HEAD`, and `OPTIONS` default to read-only and every other method defaults to side-effecting; SearchAI and read-only table bindings default to read-only; any other non-HTTP tool defaults conservatively to side-effecting. An explicit `effect`/`side_effects` always wins over the inferred default.</Note>
 
+### Concurrent tool execution
+
+
+A reasoning agent works in steps. At each step, the model chooses which tools to call. When it requests more than one tool in the same step, the platform runs them at the same time. A tool whose arguments depend on another tool's result can't be requested until that result exists, so it is naturally called in a later step.
+
+```yaml
+TOOLS:
+  get_profile(customer_id: string) -> {name: string, tier: string}
+    description: "Fetch the customer profile"
+    effect: read_only
+
+  get_orders(customer_id: string) -> {last_order_id: string, orders: array}
+    description: "Fetch recent orders"
+    effect: read_only
+
+  get_delivery_status(order_id: string) -> {status: string, eta: string}
+    description: "Get delivery status for one order"
+    effect: read_only
+
+INSTRUCTIONS: |
+  For an account and order update:
+  1. Call get_profile and get_orders together in the same step.
+  2. When get_orders returns, call get_delivery_status with its last_order_id.
+  3. Then answer using all three results.
+```
+
+`effect: read_only` marks a tool as a pure lookup. A read-only tool executes immediately: it is never held back while a separate call is waiting on customer [confirmation](#confirmation).
+
+The model decides which tools to request together, so `INSTRUCTIONS` is what makes the grouping consistent: tell it which calls are independent and can run together, and which call needs another call's result first. Instructions guide this grouping; they don't enforce it, since the model still chooses what to call at each step. For a fixed, guaranteed execution order, attach the calls as a [workflow tool](#workflow-tools) instead and define the order on the workflow canvas. See [Build workflow logic](/agent-platform/workflows#build-workflow-logic) for how nodes on the same branch run concurrently.
+
+<Note>This concurrency is automatic and needs no extra configuration. It's unrelated to a workflow tool's `mode` property (`sync` or `async`), which controls whether the calling agent waits for a long-running workflow run to finish, not whether multiple tool calls run together.</Note>
+
+To confirm which calls ran together, open the session trace: tool calls that ran at the same time show overlapping start and end times.
+
 ### Result compaction
 
 

agent-platform/administration/workspace-and-team.mdx

@@ -729,6 +729,8 @@ MEMORY:
       TTL: "{{env.MEMORY_TTL_DAYS}}d"
 ```
 
+<Warning>The **Secret** flag only masks a variable's value in the Studio UI -- it doesn't change what the agent sends anywhere the variable is referenced. Referencing a secret variable in the agent's persona, goal, or limitations sends its resolved value to the model as plain prompt text, the same as referencing it in `RESPOND` sends it to the customer. Reserve secret variables for constructs the model and the customer never see -- HTTP tool endpoints, headers, and auth -- and keep anything referenced in the system prompt or a response non-secret.</Warning>
+
 ### Edit a variable
 
 Select the **Edit** icon next to a variable to change its value, description, or secret setting. Your change reaches new agent sessions immediately.