Kiro Crew log MCP server vs Sume job events: which record to trust

For what happened to a piece of generated media, trust Sume's job record; for what the agent was doing around it, a session log such as Kiro Crew's is the right place. Kiro's changelog says Crew 0.7.0 (2026-09-24) introduced a kirocrew-crew-log MCP server for durable session tracking (read 2026-10-03). The two records answer different questions, and treating the session log as the account of a paid job invites mistakes when they disagree.

The Kiro entry is on the changelog. The Sume job facts are in Jobs and results and MCP tools and gates.

Two records, two owners

A session log is written by the agent environment: it knows which steps ran, what was said, and which tools were called. It cannot know what happened inside a provider after the call returned. A Sume job record is written by Sume: it knows the status, the events, the result, and the media it produced. When an agent says the video failed and the job says completed, the job is right.

Record the id, then reconcile

The link between the two is the job id. Have the agent write the id and the idempotency_key into the session log the moment a create returns. Then on resume, the first move is to read the log for ids and call jobs_status or a batch jobs_wait on them. Sume allows 1 to 20 job_ids per batch wait and returns a snapshot for each, so one call can reconcile a whole run.

If the log has a key but no id, the create may not have completed. Repeat it with the same idempotency_key; a replayed key returns the original job rather than a second one.

• Log: task, key, job id, timestamp. Nothing secret.
• On resume: read the log, then one batch jobs_wait with include_results: true.
• Results that do not fit one answer are named in results_omitted.job_ids; read those with a batch jobs_result.

A reconcile call

This is the request body for a batch wait over the ids found in a log. The tool is jobs_wait, and the field names are from Sume's jobs documentation; confirm them with tools_schema in your session.

{
  "job_ids": ["<id-from-log-1>", "<id-from-log-2>"],
  "wait_for": "all",
  "include_results": true
}

If it returns wait_slice_expired, the slice timed out at about 55 seconds, not the jobs; call it again with the same ids. Do not paste signed URLs from results into the session log. The docs say to prefer public ids and media.sume.com URLs in reports. A durable log is worth keeping because it lets a different session, or a different person, continue the work; the discipline that makes it safe is the same discipline that avoids paying twice.

What to keep out of the log

A durable log tends to collect everything, which is how secrets end up in it. Keep API keys, OAuth tokens, and signed URLs out; Sume says to prefer public ids and media.sume.com URLs in reports, and to rotate any key that shows up in logs. Store the job id, the idempotency_key, the task name, and the final status you read from Sume.

Also decide who can read it. A log that records prompts may contain brand or campaign details, and a shared crew log is read by every teammate and agent that has the server. Restrict by project, and treat the log like any other shared document.

When the job is done, record the result by reference, such as the job id, instead of copying the media. The job record remains the source of truth, and a second copy of a status can only go stale.