Interaction Models

Tracks a tool the agent used during an interaction. Multiple tools can be used per interaction.

A learning (profile, user playbook, or agent playbook) the caller retrieved from Emend and injected into the agent context before the agent responded. Attach every injected learning—not only the ones that visibly changed the answer—so evaluated sessions receive detailed per-learning relevance and impact analysis. These stable identities also provide attribution data for future optimization of retrieved learnings. See Retrieved-learning evaluation.

A learning the agent claims actually influenced its response — the narrower counterpart to RetrievedLearning, which records everything injected whether it helped or not. Attach citations on the Assistant turn so retrieval attribution can distinguish learnings that shaped the answer from learnings that were merely present.

Represents information about a user interaction stored in the system.

Model for user-provided interaction information (also called InteractionRequest).

// POST /api/publish_interaction{"user_id": "user_123", "session_id": "session_abc", "interaction_data_list": [{"role": "User"}, {"role": "Agent"}]} // 422 Unprocessable Entity// every interaction is empty: at least one must set "content" (or any of: ...)

Two further rules return a 422, because they are contradictions rather than absences: a user_action other than none requires a user_action_description, and interacted_image_url and image_encoding cannot both be set. The message names the offending interaction_data_list index. All of these apply on both the synchronous and the default asynchronous publish path.

Unrecognised field names are ignored, but reported. Every field below is optional with a default, so a misspelled key binds to nothing and its value is discarded — a mis-keyed content produces an interaction that is then dropped as empty. As long as one interaction survives, the request still succeeds; if the mis-keying empties every interaction, you get the 422 above, and its message names the offending field. On success, the response's warnings names the unrecognised fields and the interaction_data_list index each appeared on, including nested paths such as tools_used[0].stat. Read that list; a correctly-shaped payload produces no payload warnings.

Two qualifications. The list is bounded — at most 5 names per interaction and 20 entries overall, each with a +N more suffix — so on a large broken batch treat it as a sample rather than an inventory. And per-interaction user_id and session_id are stripped without a warning, because callers routinely repeat those request-level fields on every interaction; their absence from the list is not evidence that they bound.

Still build your payload from an allowlist of the fields below rather than passing an internal record through — the warning tells you a field was dropped, it does not stop the drop.

Request model for publishing user interactions.

Response model for interaction publication requests. Diagnostic fields (endpoint_url, storage_type, storage_label, profiles_added, profiles_updated, playbooks_added, playbooks_updated) are populated only when the publish was made with wait_for_response=True. request_id is returned on both paths.

Request model for searching user interactions.

Response model for interaction search requests.

Request model for getting user interactions.

Response model for getting user interactions.

Request model for deleting a user interaction.

Response model for interaction deletion requests.