Skip to main content

Files are shared on tasks, comments and messages, and the web app decides what to show

Images were the only thing people and agents could share, only on a task, and only one way: agents shared them, nobody could read them back, and people could not add one at all. Working with an agent day to day needs more: a PDF or a log on a comment, a screenshot pasted into a conversation, a report an agent hands back. We decided that a file replaces the image: any content, with a name and a declared type, on exactly one of a task, a comment or a conversation message, and seen by whoever can see that. The server stores the type it is given and does not judge it; it always serves a file as a download, so nothing it serves runs as a page. The web app alone decides to show some image types in place, and offers every other file to download. Agents learn of files from their prompts, which list them, and fetch the ones they need with the CLI.

Considered Options​

  • An allowlist of types, checked from the bytes, as images were: rejected. Which files are worth sharing is not the server's to know, and a type only matters to whoever shows the file.
  • Serving files as their type: rejected. A file of type text/html or an SVG opened from Mission Control's own origin would run as Mission Control, with the reader's sign-in. Serving every file as an attachment in a sandbox, and showing only raster images in place, keeps any type safe to share.
  • Files on a conversation, beside its messages: rejected. A file in a conversation is always said with something, so it belongs to a message, as a file on a task's discussion belongs to a comment.
  • Files copied into a role's home for every turn: rejected for listing them in the prompt and letting the agent fetch what it needs, as it clones what it needs (ADR 0023). Files can be large, and the home is the agents' own.
  • Images passed to the model as images: left for later. It depends on what each runtime takes, and fetching a file works for every one.
  • Captions: dropped. Something said about a file is a comment or a message with it.
  • Uploading a file with the comment or message, in one request: rejected for uploading first and attaching by id, so the web app can upload while a person types, and a comment appears with its files at once.

Consequences​

  • A file is on one thing only. Sharing it elsewhere is sharing it again.
  • Unattached files are removed after a day, and a file goes when what it is on is deleted, bytes and all. A fresh session of a conversation only archives its messages, so their files stay.
  • Existing images became task files. A captioned image became a comment by its author, at its time, with the caption as its text and the file on it; images of deleted tasks were removed.
  • mission-control task image is gone, for file share, and --attach on task comment and conversation send. An organization's edited copy of a built-in skill that names the old command needs changing by hand.
  • Slack carries no files yet. A file sent to a role in Slack is still left out, with a note to share it from the web app instead.