[github-actions]

Rendered output was not compared with the base build: the site does not build at the base commit ed3fb85, so rendering outside the declared versions is unchecked.

agentgateway/agentgateway#4241 — llm: expose request context to response CEL on streaming responses

Docs versions: standalone/main, kubernetes/main

What changes for users: LLM response transformations on streamed responses can read request-side CEL context, including llm.provider, llm.requestModel, and llm.streaming. Response-derived fields such as llm.responseModel are still unavailable until the stream is parsed.

What the docs now say: The standalone transformations and CEL variables pages now state which request-side LLM fields are available for streamed response transformations. The Kubernetes LLM transformations reuse asset now gates the same streamed-response guidance to main and says to use those request-side fields instead of llm.responseModel on streamed response transformations.

How agentgateway-4241 was drafted, and what was not verified

• Code PR: llm: expose request context to response CEL on streaming responses agentgateway#4241
• Code issue: llm.provider not returned on streaming responses agentgateway#4218
• Product: agentgateway (upstream) → agentgateway/website
• Docs version: standalone/main and kubernetes/main
• Category: scoped-edit / pr

Plan, and what changed it

• Planned: Check the candidate LLM and guardrail pages and document the response CEL behavior where the page already describes transformations.
• Learned: The target list had broader LLM pages, but the specific pages for the behavior are the standalone traffic-management transformations page and the Kubernetes LLM transformations reuse asset. The diff tests assert response transformations on streamed responses can read llm.provider, llm.requestModel, and llm.streaming, while llm.responseModel is absent.
• Did: Documented the streaming response-transformation CEL context on the specific transformation pages and narrowed the standalone CEL reference caveat.

Why a documentation change is necessary

The pull request changes response-side CEL behavior for streamed LLM responses. The Kubernetes transformations page already warned readers away from parsing response.body on streaming routes but directed them to llm.responseModel, which the test in the dossier shows is not available at that point. The standalone transformations and CEL variables pages did not say that request-side LLM fields are available on streamed response transformations, so readers could not safely write these response header transformations.

What changed on disk

• assets/agw-docs/pages/agentgateway/llm/transformations.md: Gates main guidance for streamed response transformations and says to use request-side LLM fields instead of llm.responseModel on streamed response transformations.
• content/docs/standalone/main/documentation/configuration/traffic-management/transformations.md: Adds the available request-side LLM fields for streamed response transformations.
• content/docs/standalone/main/reference/cel/variables.md: Narrows the streaming caveat to distinguish request-side fields from response body and response-derived fields.

How to verify this change

1. Run the code test process_streaming_exposes_request_llm_context_to_response_cel from the dossier. The test asserts that response CEL sees llm.provider == "openai", llm.requestModel == "input-model", llm.streaming, and no llm.responseModel.
2. Run the code test llm_streaming_response_transformation_sees_llm_context from the dossier. The test asserts that a streamed LLM response transformation sets x-llm-provider: openai, x-llm-request-model: replaceme, and x-llm-streaming: true.
3. Review the built pages after the workflow runs Hugo. The Kubernetes main page must show the gated streamed-response guidance, and older Kubernetes version trees must not show it.

Proposed release note

See proposed-release-note.md.

What was not verified

• Internal links are unchecked because Hugo was not run.
• The version-gated asset was checked statically against the configured version tokens, but the rendered pages were not built.

How the pages were chosen (triage report)

Feature clusters

Kept apart on purpose. Merging wrongly produces a guide that documents two things and explains neither, so these are reported for a person to merge rather than grouped automatically:

• ext_proc: keep CEL executor out of request future agentgateway#4246, llm: expose request context to response CEL on streaming responses agentgateway#4241 all mention "CEL" in the title and are in different clusters; check whether they are one feature

Draft a documentation change

agentgateway/agentgateway#4241 — llm: expose request context to response CEL on streaming responses

• Product: agentgateway (upstream) → agentgateway/website
• Docs version: standalone/main, kubernetes/main
• Code issue: llm.provider not returned on streaming responses agentgateway#4218
• Summary (read from the body): Attach LLMContext to the response like the buffered path so llm.provider resolves in transformations.
• Not tested: no cluster was available, so every command in this diff is unrun

Release notes

This pull request also adds its release-note entries:

• content/docs/standalone/main/release-notes/release-notes.md: llm: expose request context to response CEL on streaming responses (fix, under LLM, in a new 1.8 section)

Release notes kept out of a tree. Check that each change really does not reach the trees named here:

• llm: expose request context to response CEL on streaming responses agentgateway#4241: not placed for kubernetes/main, because the draft edited no page there. If the change also reaches that tree, add the note there.

Draft branch: pr-tracker-draft-agentgateway-4241

[cloudflare-workers-and-pages]

Deploying agentproxy with    Cloudflare Pages

Latest commit:	3fd39ff
Status:	✅  Deploy successful!
Preview URL:	https://f002fab6.agentproxy.pages.dev
Branch Preview URL:	https://pr-tracker-draft-agentgatewa-bahi.agentproxy.pages.dev

View logs

[kristin-kronstain-brown]

Moved this PR's release-notes entry to the combined release-notes PR, #1482, so the draft PRs stop conflicting on the release-notes pages. Review or change the entry there.