Skip to main content
A harness is the agent’s git repository — the code that decides who the agent is. The API is the read side of it: which harnesses exist, which versions each one has, and exactly what files a given version holds. Writing is done with git; see Versions.

List

That is the whole index entry: an id and a name. There is no description and no timestamp, because the prose lives in the harness’s own files and its age is the commit that made it. Nothing makes name unique either — two harnesses may carry the same one, since a name is a label a person typed and never an address.

Read one

versions is the registry of every published tree, newest first. A version is a pair: the commit is the tree, and the number is the label refs/versions/N puts on that commit for people to read. The commit is the selector; the number never is.

Read one exact version

Name the commit and you get the files — the same bytes the runtime parses to execute the harness:
files is every path in that commit against that file’s contents, UTF-8, verbatim — the version is its files. message is what the publish said, and it is the only provenance kept: the harness above was made by copying a starter, and the commit message says which one and at what sha. A commit that never existed, or a harness that is not yours, is the same 404 as any other invisible resource.

Create

A harness can also be created from the API, files and all. It is one atomic operation: the harness and its version 1 come into existence together.
201, with Location: /v2/harnesses/h_01M1GFTAQ6EDPV30NNAF9TYK7Z. Omit files and you get the default starter instead of an empty repository. What may be in those files is enforced on the way into git, and a tree that is not a harness is refused by name:

Rename

The name is the one mutable thing about a harness. Renaming creates no version and changes no file:

Delete

204, and the harness is gone from every listing:
The delete is a soft one. Runs that already happened stay readable with their history intact; new runs against the harness fail with 404. Nothing in the system deletes a harness repository.

There is no endpoint that publishes a version

You will not find a POST .../versions, and that is deliberate. A version is created by pushing:
The git proxy is the only write path into a harness’s history, so what a version holds is always exactly what somebody pushed. The API reads that history back.

In the SDKs

The list endpoint returns index entries, so a harness from list carries no versions; get is what fills them in.