docs: simulation tests section for agent tests

agents/build/custom-llm.mdx

@@ -58,16 +58,16 @@
         "parameters": {
           "type": "object",
           "properties": {
             "order_number": { "type": "string", "description": "The order number, e.g. A12345." }
           },
           "required": ["order_number"]
         }
       }
     }
   ],
   "session_id": "sess_01j9x4k2m8v3q7n5p6r8t9w0y1",
   "user_id": "user-42",
   "fishaudio_extra_body": { "chat_id": "chat-9" }
 }
 ```
 
@@ -134,6 +134,6 @@
 
 ## Limitations
 
-- [Agent tests](/agents/test/agent-tests) are not supported. A scripted test run refuses to execute rather than substitute a platform model for yours.
+- Single Turn and Tool [agent tests](/agents/test/agent-tests) are not supported. A scripted test run refuses to execute rather than substitute a platform model for yours. Multi Turn tests run on your endpoint.
 - Configuration is API-only for now. A console UI comes later.
 - The prompt-level safety guardrails still ride the assembled context, but your model decides whether to honor them.

agents/build/dynamic-variables.mdx

@@ -32,7 +32,7 @@
 and they are on the {{plan}} plan. Greet them by name.
 ```
 
 Pass values as a flat object of strings, numbers, or booleans. Variable names must match `[A-Za-z][A-Za-z0-9_]*` (no hyphens or dots; the dotted `system.*` names are reserved for [system variables](#system-variables)), string values are capped at 1,000 characters, and a request can carry at most 50 variables. Violations reject session creation with `422`:
 
 <CodeGroup>
 ```bash API (curl)
@@ -94,16 +94,16 @@
 ```
 
 <Tip>
 In `agentId` mode, values arrive from the end user's browser. Treat them as untrusted input, and use `sessionToken` mode when personalization must come from data only your backend knows.
 </Tip>
 
 ## System variables
 
 The platform fills a handful of `{{system.*}}` placeholders itself, on every session. You cannot supply or override them: the names you pass in `dynamic_variables` cannot contain a dot, so the two namespaces never collide.
 
 | Variable | Value | Notes |
 |---|---|---|
-| `system.channel` | `phone_inbound`, `phone_outbound`, or `web_voice` | Web SDK, API, preview, and agent test sessions are all `web_voice`. |
+| `system.channel` | `phone_inbound`, `phone_outbound`, or `web_voice` | Web SDK, API, preview, and Single Turn and Tool test sessions are `web_voice`. A Multi Turn test uses its [channel](/agents/test/agent-tests#channel). |
 | `system.timezone` | The session's resolved IANA timezone, for example `Asia/Tokyo` | `UTC` when nothing resolves. Always equals the session's `timezone` field; see [which timezone a session uses](/agents/build/time-timezone#which-timezone-a-session-uses). |
 | `system.today` | Today's date in that timezone, ISO 8601 `YYYY-MM-DD` | The calendar date at session creation. There is no `system.now`; see [World context](#world-context). |
 | `system.language` | The session language code, one of the [52 supported languages](/agents/build/voice-language#speaking-language) |
@@ -155,12 +155,12 @@
 A reference to a system variable that does not exist (`{{system.foo}}`) is rejected with `422` when you save the configuration or the tool, and when you send it in session overrides. The error lists the available names.
 
 <Note>
 There is no `system.session_id`. The configuration is rendered before the session receives its id, so the id cannot be templated into it. Read it from the `POST /v1/agent/sessions` [response](/agents/deploy/authenticated-sessions), the SDK's `connect` event, or the `session` object in [webhooks](/agents/monitor/webhooks).
 </Note>
 
 ## World context
 
 The agent knows the current date and time without any variable. The platform states the date and the session's timezone at the start of every session and refreshes the time on every turn, so "tomorrow morning" or "next Tuesday" resolve correctly even in a long conversation. You don't need a custom `{{today}}` or `{{now}}`, and there is no `system.now`: variables render once, when the session is created, so a templated time would be stale from the first reply onward. When you want the date or timezone as text in a template, for example in a webhook tool URL, use the [`system.today` and `system.timezone`](#system-variables) system variables.
 
 See [Time & timezone](/agents/build/time-timezone) for how the timezone is resolved and how to turn the injection off for a session (`world_context: false`).
 

agents/build/webhook-tools.mdx

@@ -110,7 +110,7 @@
 
 ## Mock responses
 
-A tool can store mock responses: canned payloads, each with a `name`, a `status_code` (100–599), a `content_type`, and a `body`. Mocks are saved with the tool's configuration for test scenarios, but they don't intercept anything yet: preview and live calls always hit the real endpoint.
+A tool can store mock responses: canned payloads, each with a `name`, a `status_code` (100–599), a `content_type`, and a `body`. Mocks are saved with the tool's configuration for test scenarios. [Multi Turn agent tests](/agents/test/agent-tests#tool-mocks) that mock all tools answer the tool with its first mock response. Live calls always hit the real endpoint.
 
 ## Test your tool
 
@@ -166,7 +166,7 @@
 { "ticket_id": "T-1042", "expected_reply": "within 24 hours" }
 ```
 
 Ticket numbers get spoken aloud: short, pronounceable IDs survive text-to-speech far better than UUIDs.
 
 <Note>
   An in-call ticket depends on the model choosing to escalate. For a safety net