The directory
A workflow renders as a small tree. Each node gets a directory:- Structural files define the agent. Their content comes back inline, and writing one back rebuilds the graph.
- Agent files are the agent’s own files: memory, uploads, and whatever a node keeps beside itself. Each comes back with a
checksumand adownloadUrl. The bytes come inline only if you ask for them.
The endpoints
Three things are worth knowing:
- The patch is rev-guarded. Send the
revyou read asbaseRev. If it is stale you get a 409, so you cannot overwrite an edit someone made in the builder while you were working. - Publishing assigns the next version and unpublishes the previous one. Only one version is published at a time.
POST /agents/{agentId}/executewith noversionruns the published version — which, after a push, is what is in your repository.
Pull
Write the tree to disk, then commit it.Push
Send the files that changed, then publish. The patch takes whole files, so send each file you hold and list the paths you deleted. Anything remote that your listing does not name is deleted, so the listing has to be complete — dotfiles included.readdir returns them; most glob libraries do not.
The first push normalises
A push rebuilds the workflow from your files, and fills in any defaults you left out. So the first push of an agent you built in the builder changes files you never edited:Detect drift with the content hash
Every tree comes back with acontentHash: a SHA-256 of the whole directory. Compare it to find out whether the published agent still matches your checkout.
The hash always covers the whole workflow, even if you only asked for part of it. So a contents=none read gives you the same hash as a full one, for much less data.
committedHash is the contentHash your last push returned, stored in the lockfile. With this check in CI, a build fails if someone has changed the agent in the platform since you last pushed, and pulling shows you which files.
contentHash is missing if any agent file has no checksum yet. Treat a missing hash as “unknown” rather than “unchanged”, and compare the files instead.Put it in CI
- Commit the directory. It is the source of truth.
- Run
pushin the deploy job. Publishing is idempotent, so a deploy that changes nothing is safe to run. - Your application calls
POST /agents/{agentId}/execute, which runs the version in your repository.
contentHash each push returns in the lockfile, next to the agent id. You cannot work the hash out yourself — the server computes it from its own copy of the workflow — so the only way to know whether the agent still matches your checkout is to compare against the hash a push gave you.
Large agents
Some agents carry tens of thousands of agent files, so we recommend the following when you version one in git:- Do not ask for
contents=all. By default, structural files come back inline and agent files come back as references.contents=alldownloads every file as well, including ones you already have. - Use the checksum to skip downloads. Each agent file comes back with a checksum. If it matches the file on disk, you already have it and can move on. This is why
pullabove deletes only the files the server no longer lists, rather than clearing the directory — clearing it would throw away files it then has to download again. - Use
contents=nonewhen you only needrevorcontentHash. It returns paths, sizes and checksums, and no file content at all. - Ask for less.
paths=returns only the files you name.maxFileBytesandmaxTotalBytescap how much content comes back inline; anything larger comes back as a reference you fetch from itsdownloadUrl.
Call a workflow
Execute an agent and read its result
Versions and publishing
How saving, drafts and publishing decide which version runs
Nodes
What goes in a node’s
settings.yamlProduction checklist
Publishing, API keys, retries, and monitoring

