kaxil commented on code in PR #71464:
URL: https://github.com/apache/airflow/pull/71464#discussion_r3764865832
##########
providers/anthropic/docs/operators/anthropic.rst:
##########
@@ -282,6 +282,60 @@ task's real outcome is preserved and a warning is logged.
session records instead. This is the same scenario as the retry warning
above, so
``retries=0`` keeps both problems away.
+Configuring the agent
+"""""""""""""""""""""
+
+Agent-level settings are not operator arguments: they belong to the agent,
which is created
+once and referenced by ID on every run.
+:meth:`~airflow.providers.anthropic.hooks.anthropic.AnthropicHook.create_agent`
forwards
+keyword arguments to the API unchanged, so these need no provider support.
+
+**Pinning the inference region.** Pass ``model`` as a config object instead of
a bare id to
+confine inference to one region:
+
+.. code-block:: python
+
+ hook.create_agent(
+ name="us-only-analyst",
+ model={"id": "claude-opus-4-8", "inference_geo": "us"},
+ )
+
+The accepted values are ``"us"`` and ``"global"``; anything else is rejected
with
+``400 inference_geo: must be one of ["global" "us"]``. When ``inference_geo``
is unset,
Review Comment:
Good call, and I've gone with your second option -- the list is gone rather
than maintained here.
Enumerating the regions means this guide owns a list Anthropic controls, so
it drifts silently the moment a region is added. It now says an unsupported
value is rejected with a 400 naming the accepted set, and links to [Data
residency](https://platform.claude.com/docs/en/manage-claude/data-residency)
for the current regions and the workspace-level controls.
On the "additional logic check" question: there is no validation in the
provider, deliberately. `inference_geo` is `Optional[str]` in the SDK, not a
Literal, so a client-side allowlist would be a second copy of the same list
with the same drift problem -- and it would reject a newly-supported region
before the API did. Letting the 400 through is the fail-open direction here,
but it is the API's list that decides, and its error already names the accepted
set.
While confirming this I also picked up something worth documenting, now
added: the pin is re-validated against the workspace allowlist when the agent
is saved, when a session is created, **and on every turn a session serves**. So
narrowing the allowlist stops in-flight sessions, not just new ones.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
