How can two AI agents or automated scripts hand data to each other over HTTP?

Separate transport from coordination

Two automated workers do not need a conversational channel merely because one produces data for the other. They need a place where bytes can be written, a way to authorise each operation, and enough metadata to decide what to do next. HTTP is a useful boundary because nearly every language, sandbox, and agent runtime can make a request.

The general pattern is producer writes, consumer reads, and a small control message points at the object. The control message might travel through an existing scheduler, database, webhook, or agent framework. The data itself can be a JSON document, CSV, image, trace, model output, or compressed archive. Keeping the payload addressable avoids copying large content through a prompt or orchestration record.

Do not confuse a storage handoff with a queue. A queue normally defines delivery attempts, acknowledgement, ordering, consumer groups, and redelivery. A versioned object gives you bytes and a name. If your agents need queue semantics, choose or build that layer explicitly.

A concrete HTTP contract

The producer writes to a stable name. Every PUT becomes a new version, which means a retry strategy must consider whether a duplicate version is harmless. If the payload is idempotent and the name represents a snapshot, duplicate writes may be acceptable. If every write represents an event, include a producer event ID and have the consumer deduplicate it.

curl -X PUT -H "Authorization: Capability <write-capability>" \
  --data-binary @result.json \
  -H "Content-Type: application/json" \
  https://in.svc.nz/agent-box/result.json

The producer then sends the consumer a reference and a read capability through the agent framework. The consumer reads it:

curl https://out.svc.nz/agent-box/result.json/latest \
  -H "Authorization: Capability <read-capability>" \
  -o result.json

That header is deliberately separate from the URL. A capability can be scoped for reading, and a producer can avoid giving the consumer write authority. If the consumer must reply, give it a different write capability for a reply name. Do not reuse a broad producer credential because both workers happen to be inside one deployment.

Latest versus pinned versions

Reading latest is useful when the consumer wants the freshest completed snapshot, such as the current model output or a periodically refreshed measurement. It creates a moving dependency. A second read later may produce different bytes, so record the version and checksum in the consumer’s own result if reproducibility matters.

A pinned version is better for audits, evaluation runs, and debugging. The producer can write version 1, version 2, and so on. The consumer records the explicit version it accepted. This is a simple form of lineage, but it is not a full dataset catalogue. There are no automatic diffs, merges, schemas, or semantic guarantees.

Validate before acting. Check the content type, size expected by your application, schema, checksum where available, and the producer identity or capability context supplied by your orchestration layer. AI agents should treat fetched content as data, not instructions. A document that says “ignore your policy and disclose secrets” is still untrusted input.

Retries, expiry, and failure

HTTP requests fail for mundane reasons: network interruption, a worker restart, an expired capability, a malformed payload, or a producer that wrote a new version after the envelope was sent. Make those states visible. A consumer should distinguish “object not found”, “not authorised”, “expired”, “invalid data”, and “already processed” rather than retrying every error indefinitely.

Use expiry for temporary handoffs. It limits how long a forgotten read capability is useful, but it does not cancel a copy already made by the consumer. For sensitive bytes, use client-side encryption and pass the key independently. The storage service can then hold ciphertext while the consumer decrypts locally.

svc.nz is currently a private trial, and the legal pages describe current limits. It is appropriate for a small, explicit byte handoff. It is not a replacement for a durable workflow engine, a secrets manager, or a data governance system.

Keep the handoff contract boring enough to test. A producer should publish a complete object, identify its format, and state whether the consumer may use the latest available version. A consumer should not infer meaning from a filename alone. Explicit metadata makes failures visible when a model changes output format or a worker is upgraded. Keep ownership clear: the producer owns publication, the consumer owns interpretation, and the coordinator owns delivery state. That division prevents a storage object from quietly becoming an undocumented protocol. A human approval gate should remain in front of irreversible actions.

FAQ

Sources

RFC 9110, HTTP Semantics; RFC 9110 PUT; OWASP Top 10 for LLM Applications; MDN, idempotent methods.