How desert labs works

You tell an agent what job you want done. The agent does that job once by hand to learn what it takes. Then it builds the automation that does the job from then on.

​

Tell the agent what you want

You start in the chat on the left side of a workspace. Describe the job the way you would explain it to a new coworker. What comes in, what to do with it, what comes out, and what counts as a problem. You do not fill in a form. You do not wire boxes together. You just say it, and the agent turns your words into something that runs.

​

The agent runs the job first

This step is what makes the automation hold up later. Before the agent writes anything, it does the job itself. It opens the page. It checks the inbox. It calls the API and reads what comes back. Doing the job once surfaces the surprises. The repo turns out to be private. The export comes back in pages. The field you call “status” holds three different words. The agent hits those problems while it is still just looking around, instead of guessing and breaking on your first real run. So the automation you get matches what really happened, not what anyone assumed.

​

What the agent builds

Every automation mixes two kinds of steps. The agent picks the right kind for each one.

• Regular code handles the steps with one right answer. Fetch this page. Keep the rows from today. Format the list. Send the email. This code runs fast and does the same thing every time.
• Agent skills handle the steps that need judgment. Sum up a long thread. Decide if a message is urgent. Read a page that changes shape every week.

Most automations need both. Take “email me a summary when someone opens a pull request.” Everything up to the word “summary” is regular code. The summary itself needs judgment.

​

How the automation starts

Something has to set the automation off. You get four choices: One automation can use more than one. The same job can run every night on a schedule and also run right now when you press the button.

​

The agent remembers your corrections

Say you fix something. The tone is off. The cutoff should be 10, not 5. The agent handled an edge case the wrong way. The agent does not just patch that one run. It writes what you told it into its memory in that workspace. The next automation it builds already knows. This memory builds up over time, and it stays in the workspace it belongs to. A correction you make in your first week still holds in your sixth month. That is why a workspace you have used for a while gets things right on the first try more often than a brand new one.

​

What a workspace is

A workspace is one cloud machine with two halves. On the left, the chat that builds your automation. On the right, the UI you run it from. The sidebar chat holds the agent that builds your automation. This is not a help widget stuck on the side of the product. It is how you build the tool, and it is how you change the tool later. Leave the thread open. When you want a tighter rule or one more page, you ask for it right here. The automation UI is the app the agent wrote. It runs on that same machine. You use it once the automation works, and it has two tabs.

​

Triggers

This tab is your control panel, and it is where you land. The agent builds this page for you: the buttons you press, the forms you fill, and the results you read. It also shows the runs that already happened and what each one produced. The screenshot shows a list of automations on the left and one pull request summary on the right. Yours will look different, because the agent builds this page around your job.

​

Automations

This tab is your catalogue. It lists every automation in the workspace, what each one does, and how each one starts. Open one and you see the full description, its trigger badges, and the URL you copy if it uses a webhook. Use the Triggers tab to run things. Use the Automations tab to see what exists and how you wired it up.