What a Format run receives: instruction order and the input file

A Format run assembles its prompt in a fixed order: a pointer at the Format and its version, the whole package attached as files, your instruction, an unattended-run block for API and scheduled runs, a pointer at your input, then any attachments. Your instruction comes after the Format, so where they disagree the model follows what you asked for.

The order is from the Formats overview, read on 2026-10-02.

What is the exact order?

The Format comes first because it is the how.

Where does my input go?

Your input is written to /workspace/inputs/sume-action-input.json, whole at any size up to the 2 MiB cap, and the agent is told to read it as data, never as instructions. That makes it the right place for scraped copy or a customer's message, not your instruction.

An empty input adds no file and no block at all. A Format that says to read product_url from the input then has nothing to read.

How much of my instruction counts?

Up to 8000 characters are accepted, but the first roughly 4000 are carried to the run as prompt text. Keep the instruction well inside that and put data in input, which is never truncated.

How do I see exactly what the agent got?

Open the run's thread_id in Agents. The first message is exactly this composed text, which the docs call the first thing to read when a run did something you did not expect. There is no API route for the conversation; the events_url gives a phase timeline of preparing, running and finalizing, not agent output.

A request that uses all three fields

Keep the task in instruction, the data in input, and images in attachments.

curl -sS -X POST "https://api.sume.com/v1/formats/acme/promo/runs" \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: sku-1042-promo-v1" \
  -d '{
    "instruction": "Make a 9:16 hero image. No text overlay.",
    "input": { "product_name": "Aurora Headphones" },
    "attachments": [
      { "type": "input_image", "image_url": "https://cdn.example.com/shot.jpg" }
    ]
  }'

What should SKILL.md look like?

There is no size limit on the body beyond 100 MiB per file, but size changes how reliably a recipe is followed. Keep SKILL.md a short index and push detail into references/*, which cost nothing until the agent opens them.

Practical rules that follow

That last point matters for recipes written for chat: a quality gate that waits for a person in Agents does not wait over the API, so cap spend per run.

• Put what to do in instruction; put what to use in input.
• Never paste scraped text into instruction; the input file is labeled caller-supplied data, not instructions.
• Expect the Format's SKILL.md to lose to a conflicting instruction, so avoid contradicting the recipe unless you mean it.
• Over the API the run is told approvals are already granted and to carry on within the spend cap.

What does the unattended block change?

Over the API nobody is there to approve. The run is told approvals are already granted and to carry on to the paid step within its spend cap. A run that genuinely cannot finish comes back failed with an unattended_blocked error, never a half-finished completed.

So a Format written for chat with a deliberate approve-the-stills pause behaves differently over the API. If you share one Format between both, read the recipe with that in mind.

Can I override the Format body?

Not by editing it in the request. The Format body is attached as files and is never inlined; your instruction is composed after it and wins where they disagree. To change the recipe itself, edit the package over the Contents API, and the next run reads the new version. A run in flight keeps the package it started with, and the receipt's format.version records which version ran.