Query deployment artifact data
query_deployment_artifactRuns a read-only DuckDB SELECT against queryable deployment artifacts listed in the run manifest. For replacement-deployment history, pass up to 10 exact {deploymentId, runId} targets; they are owner-checked, queried concurrently, and returned with both IDs on every row under one global maxRows limit. Never combine a runId from one deployment with another deploymentId. Use table name data, the same as backtest query_csv. For kind-based queries such as agent_detail, the tool queries all manifest-listed hot/chunk Parquet or CSV files for that kind as one logical table. Use agent_detail plus memory_events/memory_retrievals/memory_state for questions like 'why did this live bot buy NVDA?' or 'why did it not buy anything?'. When summarizing team advice, preserve each recommendation and its stated reason, then explain the trader choice and actual order outcome. A brief reason per adviser is enough; separate earlier advice from the latest run and never invent an unrecorded reason for a hold. Results are bounded to protect agent context. For agent_detail, start with aggregate SQL plus at least one ordered timeline/excerpt query with LIMIT; aggregate counts alone are not enough to answer what the agent was doing. Use LEFT(long_text_column, N) for prompt/context/call text fields; never raw-select full effective_system_prompt, base_system_prompt, runtime_context_text, context_text, memory_state_text, event_payload_json, event_text, summary, or final_text. Aggregating a long text column does not make it safe: do not use MAX(summary), MAX(final_text), ANY_VALUE(summary), or ANY_VALUE(final_text) unless the aggregate is wrapped in LEFT(..., N). Useful agent_detail examples: SELECT event_kind, tool_name, COUNT(*) AS events FROM data GROUP BY event_kind, tool_name ORDER BY events DESC; SELECT call_index, event_index, event_kind, tool_name, LEFT(event_text, 500) AS event_text, call_input_tokens, call_output_tokens, call_latency_ms FROM data ORDER BY call_index, event_index LIMIT 50; SELECT call_index, MIN(timestamp) AS first_ts, MAX(timestamp) AS last_ts, MAX(agent_name) AS agent_name, LEFT(MAX(summary), 500) AS summary_excerpt, LEFT(MAX(final_text), 500) AS final_text_excerpt, MAX(call_input_tokens) AS input_tokens, MAX(call_output_tokens) AS output_tokens, MAX(call_latency_ms) AS latency_ms FROM data GROUP BY call_index ORDER BY call_index LIMIT 50. For scheduler AI-agent verification, query agent_detail for event_kind/tool_name counts, thinking events, call_thinking_tokens, call_input_tokens, call_output_tokens, call_latency_ms, summary excerpts, and final_text excerpts; query memory_events/memory_retrievals/memory_state to prove memory writes, retrieval provenance, and durable memory state across scheduled runs. Use show_bot_activity first for current account performance, holdings and recorded orders. Separate recorded bot telemetry readers are for targeted bot-attribution or fill investigations, not duplicate performance reports.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | ||
| kind | No | agent_detail | |
| runId | No | ||
| maxRows | No | ||
| targets | No | ||
| artifactKey | No | ||
| deploymentId | No |