How an AI automation actually works

If you have used a chatbot, you have used AI. You typed something, it answered, and that was the end of it. An automation is a different shape. Nobody is sitting there typing. It runs on Monday morning whether or not you remember it exists.

This post is about what is inside one. No code, and no assumption that you have written any.

The three parts

Every automation, however clever, is three things: something that sets it off, some steps in the middle, and somewhere the result ends up.

That is worth saying because the middle is the part people imagine when they hear "AI", and it is often the least interesting of the three. An automation that does brilliant work and drops it somewhere nobody looks has failed. One that does plain work and puts it in your inbox on time has not.

What sets it off

There are three common triggers, and they cover almost everything.

A clock is the simplest. Every Monday at 7am, or every night, or the first of the month. Something outside the automation keeps the time and knocks on the door when it comes round.

An event somewhere else is the second kind. Mail arrives, a payment goes through, someone opens a pull request. The automation is not sitting there watching for any of that; it gets told, the way your phone gets told about a text.

And then there is you, pressing a button because you want the thing now.

Most useful automations have more than one. A weekly report that you can also run on demand is normal, and so is an inbox watcher with a schedule behind it in case something was missed.

What the AI part is doing

Here is where it gets more interesting than most explanations let on, because the AI is doing two jobs that have almost nothing in common.

One job is reading things that are messy. A lease as a PDF. A forwarded email chain where the actual request is in the third message down. A competitor's pricing page that got redesigned last week. Software has always been bad at this, and it is the thing language models are genuinely good at. There is no rule you could have written in advance that gets the purchase price out of an email, because there was never a fixed place it was going to be.

The other job is writing the automation itself. You describe a process, and the model turns it into working code. This is the job people underrate, and it is where most of the value ends up sitting.

Build time and run time

The distinction that explains almost everything about how these behave, and about what they cost:

Build time is when the automation is being made. A model is reading your description, writing code, running it, looking at what came out, and fixing it. This is expensive, in the sense that it takes real work.

Run time is every occasion it goes afterwards, week after week, for as long as you keep it.

The useful move is to get as much as possible out of run time and into build time. If a step is the same every time, it should be code, decided once. If a step needs judgment about something that is different every time, it needs a model, every time.

A step that calls a model costs money on every run. A step that is ordinary code costs essentially nothing, forever. So an automation that spends its thinking up front and comes out the other side as mostly plain software is cheap to keep, and one that asks a model to redecide the same thing every Monday is not.

Why not just let the model do everything

Two reasons, and neither is about cost.

One is that models are not repeatable. Give one the same input twice and you can get two different answers, both reasonable. That is a feature when you are asking for a first draft. It is a problem when you are producing a number that goes into a spreadsheet, because now the spreadsheet quietly disagrees with itself depending on what day it ran.

The other is that code can be checked. You can look at it. You can test it against a case you already know the answer to. You can put a rule in front of it saying that if these seven things are not true, nothing goes out. You cannot really do any of that with a judgment made inside a model on the fly.

So the pattern that works is boring and a little unglamorous. Use the model where the input is messy and judgment is unavoidable. Use code for everything downstream of that.

Where the answer goes

The best place is almost always somewhere that already exists in your week.

A reply on the email thread the question arrived in. A message in the channel where the team is already talking. A file in the folder the file was always in. Automations that build a new place for you to go and check are asking you to add a habit, and new habits are expensive.

There is a small version of this that matters more than it sounds: what should happen when there is nothing to report? A weekly check that found no changes should be allowed to say so in one line. If it has to justify its existence every week, it writes a page about nothing, and after a month nobody opens it.

Fixing it when it is wrong

This is the part that surprises people who have automated things the old way.

The first version of an automation is usually right in shape and wrong in detail. It read the wrong field. It included something you did not want. It made an assumption where it should have asked. In the old model of building software, each of those is a ticket, a change, a deploy.

Here, it is a sentence. You say what was wrong in plain language, the same way you would tell a new colleague, and the correction becomes part of how it behaves from then on. The automation is a running thing with a schedule attached, so a sentence typed on a Tuesday changes what happens every Monday after it.

That also means the way you get a good automation is not by writing a perfect description up front. It is by writing a decent one, looking at the first real output, and saying what is wrong with it.

How to describe a process well

If you want to try this, five things carry most of the weight.

Say when it should run, or what should set it off. Name what it should look at, specifically enough that a colleague could go and look at the same things. Say what counts as worth telling you about, and then say what to ignore. That fourth one is the sentence people leave out most often, and it is the one that keeps the output short enough to read.

The fifth is what should happen when there is nothing to say, which is worth deciding on purpose rather than finding out in week three.

None of that requires knowing how any of it works underneath. It is the same briefing you would give a competent person starting on Monday.

Pick something small and irritating that lands on a fixed day. A rival's price list you keep meaning to look at. A spreadsheet you rebuild by hand on the first of the month. Small jobs like those are easy to brief and easy to judge, and one cycle is enough to tell you whether you got the briefing right.

That is what desert labs does, if you want to try it on one of yours.