Skip to main content
Some Asteroid users like to keep their workflow definitions versioned in their own git repository. An agent is a directory of files. The API renders that directory, and it accepts the directory back. So you keep an agent in git the same way you keep code in git: write the files to disk, commit them, and review a diff. A push step, in CI or on your machine, makes the published agent match the repository and publishes the new version, so later API calls run it. Two values track change: the agent id says which agent you are pushing to, and the content hash says whether it still matches your checkout. Keep both in a lockfile beside the directory.

The directory

A workflow renders as a small tree. Each node gets a directory:
Two kinds of file live in the tree.
  • 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 checksum and a downloadUrl. The bytes come inline only if you ask for them.
Commit the dotfiles, and push them. .node-id and .sticky-note-id hold each node’s identity. Rename a node and its directory moves; the id file is what makes that a rename instead of a delete and an add.Most glob libraries skip dotfiles unless you ask for them (fast-glob and globby need dot: true). If your push misses them, it deletes them.

The endpoints

Three things are worth knowing:
  • The patch is rev-guarded. Send the rev you read as baseRev. 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}/execute with no version runs 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.
A push overwrites work done in the platform. Your repository wins: anything edited in the builder since your last pull is replaced, and anything the builder added that your listing does not name is deleted.Pull before you push, and compare the content hash first (see Detect drift). If it does not match the hash your last push returned, someone has changed the agent in the platform — pull and reconcile before pushing over it.
baseRev guards one edit, not one deploy. Read the head immediately before you patch it. A rev you read minutes earlier is stale, and the patch returns 409.

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:
Treat this like running a formatter. Push once, pull again, and commit what comes back. Nothing moves after that: every later pull and push leaves the files alone. Do this before you start comparing hashes, or your first CI run reports a change that is only the defaults being filled in.

Detect drift with the content hash

Every tree comes back with a contentHash: 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 push in 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.
Store the 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=all downloads 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 pull above 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=none when you only need rev or contentHash. It returns paths, sizes and checksums, and no file content at all.
  • Ask for less. paths= returns only the files you name. maxFileBytes and maxTotalBytes cap how much content comes back inline; anything larger comes back as a reference you fetch from its downloadUrl.

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.yaml

Production checklist

Publishing, API keys, retries, and monitoring