Expose queryable prompt and agent response timestamps for automation triggers

[hughesfleming]

Summary

Expose prompt and agent-response observability as queryable local events or records so users can trigger follow-up automation after a response completes.

Problem

Warp currently does not expose prompt/response timing in a way that can be queried locally and used as a reliable trigger surface. The user wants to build local automation around agent interactions, specifically by storing prompt timestamps and response-complete timestamps and then using queries against that data to trigger MCP or CLI workflows.

Today, the current network log is not sufficient for this use case because it is aimed at HTTP traffic debugging rather than first-class prompt/response observability for automation.

Reproduction steps or desired workflow

1. Submit a prompt to a Warp agent.
2. Warp records at least two queryable events or records: the user prompt timestamp and the agent response-complete timestamp.
3. Those records are available through a stable local surface, such as a SQLite table, event stream, or comparable local API.
4. A local query against that surface can be used as a trigger for follow-up workflows.
5. After a response completes, the user can automatically launch MCP-based memory tools or CLI actions to summarize, log, or process the prompt/response pair.

Artifacts

None attached

Warp version

v0.2026.04.29.08.57.stable_02

Operating system

Windows

[oz-for-oss]

@hughesfleming

Here's what I found while triaging this issue:

Thanks for the clear feature request. Warp appears to have internal agent conversation persistence and event handling, but I did not find a stable local API/event stream intended for user automation triggers; this is best treated as a product enhancement. Related requests include #7834 and #10112, but I am not marking this as a duplicate in this pass.

I have a few follow-up questions before I can narrow this down:

1. For your automation, would metadata-only records be enough, or does the trigger surface need access to the prompt and response text as well?
2. Which local surface would fit your workflow best: a queryable SQLite/log table, a push-style event stream, or command hooks that run automatically on prompt submit and response completion?

Reply in-thread with those details and the triage workflow will automatically re-evaluate the issue and update the diagnosis, labels, and next steps.

Maintainer details

I concluded that feature request for a stable local agent-turn observability surface that exposes prompt and response-complete timestamps for automation triggers..

Triage summary

This is an enhancement request for first-class local observability around agent turns: record user prompt timestamps and response-complete timestamps, then expose them through a stable local query/event surface that can drive MCP or CLI follow-up automation.

Current implementation notes

• Local agent conversations are persisted for restoration/history in SQLite via agent_conversations and agent_tasks, but the schema stores serialized conversation/task payloads plus last_modified_at; it is not a public, stable automation API.
• The older ai_queries table stores query-oriented history with start_ts, input, and output status, but its code comments frame it as up-arrow/history support and it does not provide a durable response-complete trigger record.
• Restored agent exchanges can derive start_time, finish_time, and time-to-first-token from internal API message timestamps, so the client has related internal concepts, but they are not exposed as user-queryable prompt/response event records.
• CLI-agent plugin events already distinguish prompt_submit and stop and can carry query/response content, but they update session context/status in-memory rather than publishing a stable local automation stream.
• The Network log pane is a bounded in-memory HTTP request/response debug snapshot, so it is not an appropriate trigger surface for prompt/response observability.
• Internal orchestration lifecycle/event code exists for parent/child agent communication, but that is not a general local automation hook for user workflows.

Duplicate/related issue notes

• Feature Request: Agent Lifecycle Hooks for Observability #7834 is a strong related request for broader agent lifecycle hooks and observability, including agent_prompt_submit and agent_response_complete style hooks.
• Agent conversations lack machine-readable export #10112 is related to machine-readable local agent conversation export/traces with timestamps and events.
• I am not marking this as a duplicate in this pass because the incoming issue is specifically about queryable prompt/response timestamp records as trigger inputs, and the dedupe workflow requires at least two clearly matching existing duplicates before applying the duplicate label.

Suggested next step

This likely needs product/API design before implementation because the stable surface could be a queryable SQLite contract, an event stream, command hooks, structured export, or some combination, and the privacy/scope of prompt/response content needs to be explicit.

Question reasoning

1. For your automation, would metadata-only records be enough, or does the trigger surface need access to the prompt and response text as well? — The report asks for timestamps and mentions processing the prompt/response pair, so product scope and privacy expectations depend on whether content must be exposed or only metadata is needed.
2. Which local surface would fit your workflow best: a queryable SQLite/log table, a push-style event stream, or command hooks that run automatically on prompt submit and response completion? — The issue names several possible surfaces; knowing the reporter's preferred integration model would guide a spec and ownership split.

This is my automated analysis and may be incorrect. A maintainer will verify the details.

Powered by Oz

[hughesfleming]

Refining this request to the smallest useful primitive:

This does not need full transcript exposure, lifecycle hooks, or changes to Warp's existing conversation storage model.

The minimal feature is just two queryable local timestamps per agent turn:

• user_prompt_timestamp
• agent_response_completed_timestamp

The important one is agent_response_completed_timestamp, because that is the deterministic trigger boundary for external memory automation.

Why this is enough

I already have a separate memory system that distills and stores only high-signal context in Postgres. The missing piece is not storage or summarization logic — it is a reliable trigger that does not depend on the agent remembering to call a tool.

Today, agent-managed logging is fragile because:

• it depends on the agent remembering to execute a logging step
• context compression / summarization can cause that instruction to degrade or disappear
• once that happens, conversation logging becomes unreliable

With a queryable agent_response_completed_timestamp, Warp would provide a product-owned completion signal. That signal can trigger the external memory pipeline automatically.

Requested behavior

For each local agent interaction, expose a stable local surface containing at least:

• conversation/session identifier
• user_prompt_timestamp
• agent_response_completed_timestamp

Optional but helpful:

• request/debug identifier
• a monotonic turn id

What should happen externally

When agent_response_completed_timestamp appears for a new turn, an external watcher can:

1. detect that the turn is complete
2. read the relevant prompt/response context from the existing conversation state
3. store distilled memory to Postgres

That makes memory capture robust because the trigger is owned by Warp, not by the agent's short-term adherence to instructions.

Important scope clarification

This request is intentionally narrow:

• not a request for transcript export
• not a request for full observability hooks
• not a request to change Warp's existing persistence architecture
• just a minimal local completion signal that can be queried reliably

If Warp already stores enough internal state to restore/resume conversations, then exposing these two timestamps locally would likely be a small additive surface that unlocks robust downstream automation.

[oz-for-oss]

@hughesfleming

Here's what I found while triaging this issue:

Thanks for narrowing the request. This is clear enough to triage as a focused enhancement for a stable local agent-turn completion signal, not a request for full transcript export or broad observability hooks.

Maintainer details

I concluded that feature request for a minimal, queryable local agent-turn completion signal that exposes prompt and response-complete timestamps for automation..

Triage summary

This is a well-scoped enhancement request for a product-owned local completion signal for agent turns. The clarified minimum primitive is queryable per-turn metadata containing a conversation/session identifier, user_prompt_timestamp, and agent_response_completed_timestamp, optionally with a request/debug ID or monotonic turn ID.

Current code inspection suggests Warp already has internal primitives close to the requested data: AIAgentExchange carries start_time and optional finish_time, the response stream emits an internal AfterStreamFinished event, and local agent conversations/tasks are persisted in SQLite with serialized conversation/task data plus last_modified_at. Those surfaces are internal implementation details, not a stable automation API or queryable per-turn event log.

The request should be treated as an agent/automation feature rather than a bug. The existing in-app network log is intentionally scoped to HTTP traffic debugging and is not a good fit for prompt/response observability or durable automation triggers.

Duplicate search enumerated all open non-PR issues. #10112 is related because it asks for machine-readable agent conversation export, but it is broader/different from this request: this issue asks only for local timestamp/completion metadata as a trigger primitive, not transcript export. I did not find two or more likely duplicates, so this should not be labeled duplicate.

This is my automated analysis and may be incorrect. A maintainer will verify the details.

Powered by Oz