diff --git a/agent-network/2.0/modules/ROOT/pages/af-agent-script-reference.adoc b/agent-network/2.0/modules/ROOT/pages/af-agent-script-reference.adoc
index ca8b6a10c..1efa6f1d9 100644
--- a/agent-network/2.0/modules/ROOT/pages/af-agent-script-reference.adoc
+++ b/agent-network/2.0/modules/ROOT/pages/af-agent-script-reference.adoc
@@ -1234,6 +1234,9 @@ These references are used.
 
 Every node has `.output` (the value it produced) and `.input` (the output of whichever node transitioned into it).
 
+* If a node doesn't produce a value (for example, a router), its `.output` is `None`.
+* If the preceding node is a trigger, `.input` is `None`.
+
 *Example*
 
 ----
@@ -1241,17 +1244,50 @@ Every node has `.output` (the value it produced) and `.input` (the output of whi
 @generator.writeEmailContent.output              # returns the string generated by the `writeEmailContent` node
 ----
 
-* Use `.output` when you know exactly which upstream node you're referencing.
-* Use `.input` when multiple nodes transition into the current one and you want to decouple it from the specific path taken.
+==== When to Use `.output` vs `.input`
 
-In this example, `@generator.generate_email.input` returns whichever of `node_a`, `node_b`, or `node_c` actually transitioned into it.
+Use `.output` when you know exactly which upstream node you need data from. In a straight-line graph, `.output` is the simplest approach:
 
 ----
-node_a ──┐             
-node_b ──┼──► generate_email ──► send_email           
+process ──► generate_email ──► send_email
+----
+
+* `generate_email` reads `@subagent.process.output` as the source content.
+* `send_email` reads `@generator.generate_email.output` as its content.
+
+An expression can target any preceding node in the graph, not only the node immediately before the current node.
+
+To decouple a node from the path that reached it, use `.input`. In this example, `@generator.generate_email.input` returns the output from whichever of `node_a`, `node_b`, or `node_c` transitioned into `generate_email`:
+
+----
+node_a ──┐
+node_b ──┼──► generate_email ──► send_email
 node_c ──┘
 ----
 
+=== Accessing Trigger Data
+
+The `@request` namespace provides access to the trigger's incoming request data. Use `@request` expressions to read the payload, headers, and other properties of the request that started the workflow.
+
+* `@request.payload`: Returns the request payload. For the `on_message` handler of the A2A trigger, this expression returns a `SendMessageRequest` object.
+* `@request.interface`: Returns the name of the interface that produced the message (for example, `a2a`).
+
+For A2A triggers, these additional references are also available:
+
+* `@request.headers`: A case-insensitive dictionary of the HTTP request headers. For example, `@request.headers["Authorization"]` and `@request.headers["authorization"]` return the same value.
+* `@request.taskId`: The current A2A task ID, either provided in the request or automatically generated by the trigger.
+* `@request.contextId`: The current A2A context ID, either provided in the request or automatically generated by the trigger.
+
+*Example*
+
+[source,yaml]
+----
+reasoning:
+  instructions: -> @request.payload.message.parts[0].text
+  actions:
+    concur: @actions.concur-agent with http_headers = {"Authorization": @request.headers["Authorization"]}
+----
+
 === Setting Action Headers
 
 Any actions that connect to an external system often need to set custom headers. Use cases range from propagating authorization headers (for example, in OBO authentication) to adding custom correlation information.