Why did my AI agent ignore my instructions? Debug a Sume Format run
A checklist for a Sume Format run that did something unexpected: the composed first message, the carried instruction, the version, events, and output.
When a Sume Format run ignores part of your instruction, start with what the agent actually received: open the run's thread_id in Agents, where the first message is exactly the composed text. Then check that your instruction fit in the roughly 4000 characters that are carried, that your data sat in input, and which Format version ran.
The checks below come from the Format docs, mainly Instruction composition, Create a run, and Runs and results, read on 2026-09-26. Statuses, polling, and webhooks are covered in Sume Format run lifecycle.
Which check fits which symptom?
Start from what you saw, then read the field or place in the second column. Each is explained below.
| Symptom | Check first |
|---|---|
| It ignored part of my instruction | The first message of the run's thread, and whether the instruction is past ~4000 characters. |
| It ignored my data | Whether the data is in input under keys the recipe reads. {} adds nothing. |
| It followed an older recipe | format.version on the receipt. |
| It skipped a step that asks for approval | Runs over the API are unattended, so approvals are pre-granted. |
| It looks stuck | at on the last events_url entry, and queue.state on the status. |
output is empty or odd | output_error, output_schema.source, and output_schema.filled_by. |
| My webhook never arrived | webhook_delivery.status and last_error on the receipt. |
What did the agent actually receive?
Sume composes the run in a fixed order. The Format comes first because it is the how; your instruction comes after it, so where the two disagree the model follows what you asked for. Your input is written whole to /workspace/inputs/sume-action-input.json, and the agent is told to read it as data, never as instructions.
Open the run's thread_id in Agents: the first message is exactly this text, and it is the first thing to read when a run did something you did not expect. It is not available over the API; there is no messages endpoint.
The [Sume unattended run] block appears only on API and scheduled runs. A recipe written for chat may pause for approval; over the API nobody is there, so the run is told those approvals are already granted and carries on within its spend cap. A run that genuinely cannot continue without a person fails with unattended_blocked, and its message says why.
[Format: product-promo v12] <- a pointer at the recipe; the body is never inlined
[Format attached: … SKILL.md] <- the whole package, on disk in the run's workspace
[Format run instruction] <- your instruction, or the Format's default
[Sume unattended run] <- API and scheduled runs only
[Sume action input] <- a pointer at your input, written whole to a file
[Attached files] <- your attachments, when presentWas my instruction or input cut off?
instruction is accepted up to 8000 characters, but only the first ~4000 are carried to the run as prompt text. Keep it well inside that and put data in input, which is carried whole, up to 2 MiB, as a file the agent reads.
input has no published field list: the Format's recipe reads the keys it recognizes. An empty {} adds no file at all, so a Format that says to read product_url from the input has nothing to read. The Format's io profile is the only declared contract for what it takes. Where untrusted text belongs is covered in passing customer data to an AI agent safely.
Did the run use the recipe version I expected?
The receipt's format.version is the Format version that actually ran, unchanged by later edits, and an edit never touches a run already in flight. If an edit seems ignored, compare that number with the Format's current version; Sume Format versions covers tracking them.
Is the run stuck, or just slow?
GET /v1/format-runs/{run_id}/events is a phase timeline: preparing, running (the agent working the recipe, where the time goes), and finalizing. Consecutive entries with the same phase and status collapse, so at on the last entry is the run's progress clock. If it stops moving for several minutes, the run is stalled, not slow, and will be finalized at its deadline.
The timeline is not a log stream; agent output and tool calls are not published over the API. A run that stays queued has its own signal, queue.state, covered in Sume Format run lifecycle.
Why is output empty or different from what the run made?
Check output_error before reading output. output_schema.source says which schema shaped output: default, the Format's own action_default, or your request_override. output_schema.filled_by says who filled it: agent means the run submitted it; projection means a fallback pass built it from the run's media and closing text only.
The projection never sees your input or instruction, so on that path identifiers you sent do not come back, and null prose with full media fields is the shape of a run that stopped early. Over the API, a projection that misses your schema makes the run failed, with artifacts[] still listing the media; Sume Format run failure codes covers what each code means.
What should I send Sume support?
Quote the x-sume-request-id header from the response, the receipt's request_id, the run id, and the error.code. Do not send API keys, signing secrets, or raw media URLs. A runtime_unavailable queue state that lasts more than a few minutes is worth a ticket with the request_id.
Before reporting a missing webhook, read webhook_delivery on the receipt: on failed or exhausted, last_status_code and last_error (Sume's transport error, never your response body) say why, and the run itself is unchanged. Debug Sume webhook delivery covers the rest.
Sources
Related posts
Written by Sume