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..ca065124e 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, this is the simplest approach:
 
 ----
-node_a ──┐             
-node_b ──┼──► generate_email ──► send_email           
+process ──► generate_email ──► send_email
+----
+
+* `generate_email` accesses the content to write about using `@subagent.process.output`.
+* `send_email` obtains its content using `@generator.generate_email.output`.
+
+You can target any preceding node in the graph, not only the one immediately before the current node.
+
+Use `.input` when multiple nodes can transition into the current one and you want to decouple the node from the specific path taken. In this example, `@generator.generate_email.input` returns the output from whichever of `node_a`, `node_b`, or `node_c` actually transitioned into it:
+
+----
+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. Because a workflow can support multiple interface types, `@request` decouples your nodes from the specific trigger that fired.
+
+* `@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.