Uploading inputs
Upload files up front for the agent to work against, then list or download them.Getting inputs in front of an agent
Files travel outward. Uploading puts bytes in org storage; it does not put them in the agent’s computer, and a session takes nofiles[] — there is no create-time mount. To hand an agent an input today, put it in the session’s first message, or let the agent fetch it itself with web_fetch or bash.
CLI
publish_file → in Files, durably.
Two kinds of storage
Scratch work belongs in the sandbox. Anything the agent should hand back belongs in Files.
Publishing an artifact
The built-inpublish_file tool promotes a file from the session sandbox into the persistent Files store. It is not the only writer: what generate_image or generate_video produces also lands here, and the session is told the new fil_ id. This is how a finished session leaves deliverables behind without a mandatory “deliver” step — the session simply goes idle and its published files remain.
path and returns the new persistent file object ({ id, name, size, created_at }) so the id can flow into a structured output or webhook:
string
required
Absolute path of the artifact in the session sandbox, e.g.
/workspace/report.pdf.string
The name to store it under in Files. Defaults to the basename of
path.boolean
default:"false"
How to handle a name that already exists in the org (see the collision rule below).
Name collisions
Names in Files are not unique keys — every publish creates a distinct file object with its own id. Whenname matches a file that already exists in the organization:
overwrite: false(default) — the new file is stored under a suffixed name (report.pdf→report-2.pdf) so nothing is clobbered and both are retrievable.overwrite: true— the existing file’s contents are replaced in place, keeping the same id so any prior reference still resolves.
id, not the display name.
Reading a session’s outputs
CLI
Next: tools & plugins
The extension point every capability plugs into.