Skip to main content
Glama

Log the turn to history

log_interaction

Records each completed turn with the exact final answer, verbatim user request, workspace, and persona attribution to history and Langfuse tracing sinks.

Instructions

End-of-turn logger. Compose the answer including its footer, call this tool with that exact response_content, then deliver the final answer. Pass the current user request verbatim as query, without paraphrasing or substituting a conversation summary, and workspace, your working directory.

persona: the `persona` object of the last SUCCESS/NO_CHANGE, copied verbatim
with all 7 keys (agent, activation_id, bundle_revision, scope, skills_loaded,
implants_loaded, rules_loaded); persona_action (keep/switch/refresh/restore)
only together with it. Compact subagents return their data envelope without
calling this tool. Other callers without a retained descriptor omit both and
add no footer; this does not waive initial activation. files/tags are JSON arrays.
Persona and persona_action are client-reported attribution, not proof of
instruction compliance. A partial, malformed or mismatching persona never
costs the turn: it is written marked ``unverified`` or ``mismatch`` and the
response carries ``warnings``. Do not retry such a call.

Two sinks, independent of each other:

* **history.md** — written via ``HistoryWriter`` (append-only, content-hash
  deduped; the persona line is not part of the hash). Defaults:
  ``intent=query``, ``action="Agent: {agent_name}"``, ``outcome=response_content``.
  Pass ``intent``/``action``/``outcome``/``files``/``tags`` to curate the entry.

* **Langfuse** — generation trace recorded only when ``LANGFUSE_PUBLIC_KEY`` /
  ``LANGFUSE_SECRET_KEY`` are configured; otherwise the call is a no-op via
  ``langfuse_compat``.

Returns at once, before either sink is written:
``{request_id, timestamp, langfuse: {status: "queued"}, history: {status: "queued"}}``
plus ``workspace`` (``root``, ``source``), ``pid``, ``history_last_error``
(``code``, ``errno``, ``path``, ``at``; only after an earlier history write
failed) and the attribution (with ``warnings`` and an ``instruction`` when it
was incomplete). While retrieval is still warming up, ``langfuse`` is
``{status: "skipped", reason: "warming_up"}`` and no trace is recorded. ``timestamp`` is the server's local time
(``YYYY.MM.DD HH:MM:SS``); the final answer starts with it on its own line,
and it is not part of ``response_content``. The sinks are written in the
background with that timestamp and do not prevent each other; a full queue
can also drop a write. A failed history write is logged once per path and
errno (WARNING, ``code=history_unwritable``) and reported on the next result
as ``history_last_error``; Langfuse failures are only logged. When no project
resolves, the turn goes to the installation's fallback journal (#292):
``workspace`` is ``{root: null, source: "fallback", claimed, reason, journal}``,
``claimed`` the directory the client named (recorded, never written), and the
``instruction`` says to mention it once. The only request-level rejection left
is a stdio client with MCP roots that named no workspace, asked to retry once
with it, or a fallback journal directory that cannot be created (a later write
failure shows as ``history_last_error``): a protocol ERROR without
``timestamp``, over stdio with ``pid`` and ``workspace_inputs`` (``cwd``,
``claude_project_dir``, ``agents_client_repo_root``, ``client``, ``roots``).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tagsNoOptional tags, as a JSON array of strings, e.g. ["bug", "fix"].
filesNoOptional files touched, as a JSON array of paths, e.g. ["src/a.py"].
queryYesThe current user request, verbatim.
actionNoOptional curated action; defaults to the agent name.
intentNoOptional curated intent; defaults to query.
outcomeNoOptional curated outcome; defaults to response_content.
personaNoThe `persona` object of the last SUCCESS/NO_CHANGE, copied verbatim, with all 7 keys: agent, activation_id, bundle_revision (64 hex characters), scope, skills_loaded, implants_loaded, rules_loaded. Without a retained descriptor omit both persona and persona_action. Incomplete values are still logged, marked unverified.
reasoningNoOptional short reason for the selection.
workspaceNoAbsolute path of your working directory, the project this session works in. Pass it whenever you have one: one server can serve several sessions.
agent_nameYesCanonical name of the active agent.
request_idNoOptional request id for correlation.
persona_actionNoOne of keep, switch, refresh, restore; send it only together with persona.
response_contentYesThe exact final answer text, without any time line.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv26.10.14+1807

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Far beyond the annotations: it discloses two independent sinks (history.md via HistoryWriter, Langfuse), that Langfuse is a no-op without LANGFUSE_PUBLIC_KEY/SECRET_KEY, that writes are backgrounded and can be dropped by a full queue, dedup and default field values, the unverified/mismatch attribution path with 'Do not retry such a call', the fallback journal, and the exact conditions for the only remaining request-level rejection. Annotations only cover safety hints, so the description carries and fully discharges the behavioral burden.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The imperative call sequence is front-loaded, which is correct, but the body is a very dense ~400-word wall that re-states the persona key list already enumerated in the schema and explains the return payload that the output schema already defines. Much is load-bearing, but there is real redundancy that an agent must wade through.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given a 13-parameter tool with nested objects, async sinks, fallback routing and a rejection path, the description covers the full picture: happy path, subagent exclusion, attribution failure handling, warming-up skips, and error surfacing. Nothing needed to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds real constraints beyond the schema: query must be verbatim with no paraphrase or conversation summary, workspace is the working directory, persona must be copied verbatim with all 7 keys, persona_action is only valid together with persona, and files/tags are JSON arrays. It repeats some schema content (the 7 keys), keeping it short of a 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence names a specific verb+resource ('End-of-turn logger') and immediately situates it in the turn lifecycle ('Compose the answer... call this tool... then deliver the final answer'). This is unambiguous and clearly distinct from siblings like read_history or get_agent_context.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states exactly when to call (end of turn, with the composed final answer) and when not to ('Compact subagents return their data envelope without calling this tool'). It even gives the sequencing relative to delivering the answer, which is the key orchestration detail an agent needs.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.