kaxil commented on code in PR #74625:
URL: https://github.com/apache/airflow/pull/74625#discussion_r4258121840
##########
providers/common/ai/docs/message_history.rst:
##########
@@ -58,3 +58,30 @@ back unbounded.
operator raises at construction. The post-review (human-approved)
transcript
is not recoverable today, so emitting the pre-review transcript would
silently drop the reviewed turns.
+
+What this is, and what it is not
+--------------------------------
+
+``message_history`` is a hand-off of one conversation transcript from one run
to
+the next. When you pass ``message_history``, the operator reads that
transcript,
+and after the run it writes the full updated transcript to XCom under
+``message_history`` as pydantic-ai's JSON message format. Where that transcript
+lives between runs and which session key it is stored under are decisions for
+your Dag. The operator does not trim the transcript.
+
+Use it to resume a multi-turn conversation across task runs. If you need an
+agent to recall facts across unrelated sessions, note that the operator has no
+built-in cross-session memory.
Review Comment:
This names the gap but doesn't say what to do instead. Something like: to
give an agent facts from earlier sessions, store them yourself and load them in
an upstream task (the same load, run, store pattern above), then pass them in
the prompt or instructions.
##########
providers/common/ai/docs/message_history.rst:
##########
@@ -58,3 +58,30 @@ back unbounded.
operator raises at construction. The post-review (human-approved)
transcript
is not recoverable today, so emitting the pre-review transcript would
silently drop the reviewed turns.
+
+What this is, and what it is not
+--------------------------------
+
+``message_history`` is a hand-off of one conversation transcript from one run
to
Review Comment:
Most of this paragraph repeats L27-37 (the XCom key, and that the Dag owns
storage and keying). The new facts are the JSON format and the trimming note.
Could it shrink to those so the page doesn't say the same thing twice?
##########
providers/common/ai/docs/message_history.rst:
##########
@@ -58,3 +58,30 @@ back unbounded.
operator raises at construction. The post-review (human-approved)
transcript
is not recoverable today, so emitting the pre-review transcript would
silently drop the reviewed turns.
+
+What this is, and what it is not
+--------------------------------
+
+``message_history`` is a hand-off of one conversation transcript from one run
to
+the next. When you pass ``message_history``, the operator reads that
transcript,
+and after the run it writes the full updated transcript to XCom under
+``message_history`` as pydantic-ai's JSON message format. Where that transcript
+lives between runs and which session key it is stored under are decisions for
+your Dag. The operator does not trim the transcript.
Review Comment:
The operator adds no trimming of its own, but `capabilities=` goes straight
to the pydantic-ai `Agent`, so the `capabilities=[ProcessHistory(...)]` example
on the linked page works on `AgentOperator` unchanged. pydantic-ai writes the
processed list back into run state (`ctx.state.message_history[:] = messages`),
and `all_messages()` returns that, so with a processor set the value pushed to
XCom is the trimmed transcript, not the full one, and the dropped turns are
gone from the stored session. Could this say that, and drop the "not the
operator's parameters" framing at L85-87, which currently steers readers away
from the one way to bound a session?
--
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]
