How can an AI agent send a file to a person?

Run peeza link . The agent gets back a one-time, end-to-end-encrypted URL to pass along; the person opens it in a browser with no account and no app.

How do I get a file from an agent's machine to my laptop?

peeza send --to — it crosses NAT itself, needs no SSH key or open port, and delivers on return if the laptop is closed.

Does the file touch a cloud server?

No file is stored anywhere. Transfers go device to device; when a relay has to forward, it forwards ciphertext it cannot decrypt and keeps nothing.

What happens if the agent dies mid-transfer?

Nothing is lost: a background daemon owns the transfer, and it resumes from the last byte on disk when both machines are back.

peeza — file sharing for AI agents

The last step of every agent task

Agent work ends in a file — a build, a report, a render, a dataset. Then comes the step that actually matters: getting that file to the person who asked for it, or to the machine where it's needed. scp wants a key and a reachable port. Cloud drives park your file on someone else's server. peeza makes delivery one command.

$ peeza link render-final.mp4
https://g.peeza.app/7XK4M2QD#k=…

$ peeza send build.zip --to <device>      # peeza devices lists yours

The minted link prints alone on stdout, so $(peeza link file) is the link — ready to paste into a chat, an email, a pull request.

01A link any human can open

peeza link mints a single-use, end-to-end-encrypted download link. The person on the other end needs no account and no app — any browser will do.

One-time by design. The link is spent by the first fetch — once your recipient has the file, the URL left behind in a chat log is worthless.
The key never touches a server. The decryption key rides in the link's # fragment, which browsers never send — the mechanics are on the tech page.
No signup on either end of the handoff. The receiving human clicks; that's the whole onboarding.

02Your machines, without SSH

peeza send --to reaches the machines on your account wherever they are. No key on the far machine, no open port, no VPN, no shared network.

Crosses NAT by itself. Direct peer-to-peer when possible; a blind relay carries ciphertext when it isn't.
Offline is fine. A machine that's asleep or away receives the file when it returns.
Same desk? peeza send --nearby moves files over the local network — no internet, no relay, no account.

03The transfer survives the agent

Transfers belong to a background engine, not to the process that started them.

An agent that exits — or a session that ends, or a laptop that reboots — doesn't kill the delivery. Transfer state is persisted before anything else happens, and an interrupted transfer resumes from the last byte written, not from zero.

04Made to be scripted

The command line was specified for machines from day one — an agent hits edge cases a human never does.

Verbs block until the transfer is actionable and exit with documented codes (0–6), so a script never has to guess whether the send took.
--json turns every answer into machine-readable output; peeza ls and peeza watch report live transfer state.
An MCP server (peezad mcp) exposes the same operations to agent frameworks — wiring it in is a deliberate opt-in, never a default.

05The same security, whoever's driving

A transfer started by an agent is encrypted exactly like one started by a person: end to end, on every path, always.

Files stream directly between devices; when a relay has to step in, it forwards only ciphertext it cannot read and stores nothing. The full mechanics — keys, pairing, what the relay keeps — are on the tech page and in the privacy policy.