> ## Documentation Index
> Fetch the complete documentation index at: https://docs.rundesert.com/llms.txt
> Use this file to discover all available pages before exploring further.

# How desert labs works

> Describe a job in plain English and get an automation that runs it.

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:

| Trigger                                         | It runs when                     |
| ----------------------------------------------- | -------------------------------- |
| [**Scheduled task**](/triggers/scheduled-tasks) | The time you picked comes round. |
| [**Webhook**](/triggers/webhooks)               | Another app calls its URL.       |
| [**Incoming email**](/triggers/incoming-email)  | A message lands in your inbox.   |
| [**Manual**](/triggers/manual)                  | You press a button.              |

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.

<div className="dl-figure">
  <img src="https://mintcdn.com/desertlabs/yriovLtjCNsTfMuj/images/workspace.png?fit=max&auto=format&n=yriovLtjCNsTfMuj&q=85&s=02c8d3e569f83033caed935090439625" alt="A workspace with the agent chat on the left and the automation UI on the right" width="1634" height="909" data-path="images/workspace.png" />

  <span className="dl-region dl-region-chat">
    <span className="dl-region-label">Sidebar chat</span>
  </span>

  <span className="dl-region dl-region-ui">
    <span className="dl-region-label">Automation UI</span>
  </span>
</div>

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