An AI Agent Acts For You

I spent a day this week one on one training an executive, working through how AI fits the way their organisation runs. Partway through, and through a moment of confusion, they said they don't understand agents well enough. Everything else was making sense. That one felt like a separate subject they hadn't got to yet.

It isn't a separate subject. If you understand what happens when you type a question into one of these systems and read what comes back, you are most of the way to understanding an agent already. A year ago agents were harder to reach, and a lot of what gets said about them is left over from then.

An agent, in ordinary life, is somebody who does something for you on your behalf. A customs agent clears your cargo. A ship's agent represents you to the local authorities in port. You don't tell either of them which form to fill in or which desk to stand at. You tell them what you need and they go and deal with it, and you find out how it went when they come back to you.

It's close to the same thing in AI. An agent is a model you've pointed at an outcome, with the standing instructions it needs to get there, and access to the systems where the job happens.

The difference from prompting is that you stop doing the doing. When you prompt, you ask, you read the answer, and then you go and use it: you paste it into the email, you put it in the report, you send it. An agent sends it.

The difference from ordinary programming is the level you write at. Programming is specific and granular: you set out exactly how the thing gets done, in order, and software has been able to follow that precisely for decades, provided the situation is the one you anticipated when you wrote it. Vary the situation and it breaks or does something silly. With an agent you are still writing, and often a great deal, but you are writing the components it works from: the outcome you want, the standing rules of your business, the reference material, the checks it has to pass. Then it decides how to combine them for the case in front of it.

That trade costs you some control. Ask an agent the same thing twice and you'll get two slightly different answers, because these systems produce their output by probability rather than by rule. I wrote about that in The Butterfly in the Machine. It's the reason a good agent has checking built into it rather than bolted on afterwards.

What we call an agent is rarely one thing. It's a team of them, working to an org chart.

The structure is usually the same. There's a goal at the top. Under it sit the instructions that say how this job is done here, which is where your own knowledge goes. Then what it can reach: the mailbox, the scheduler, the website, the spreadsheet. Then a loop, where it does something, reads what happened, and decides what to do next. Then a second agent checking the first one's output (checks and balances). Then you, approving.

Designing one feels much more like designing a business function than like using a chatbot. You're writing a job description, then the process cards under it, then deciding who signs off. If you've ever written a procedure for a role you were about to hire into, you've done much of this before.

A maritime organisation I've been working with recently needed a fast solution for their marketing role which had become vacant. Hiring and retraining takes months, so what we built covers the doing. Somebody in the office emails a brief exactly the way they'd brief a coordinator. It comes back with a plan first, saying what it understands is wanted and what it still needs, and once that's agreed it comes back with the actual drafts on the same thread. A person approves, and approval is the go signal.

What comes back is the finished thing rather than a description of one. The marketing copy. The image tiles that go out with the posts, made to the brand's own templates. The EDMs, built the way that office builds them. Then, once a person has approved it, it books the posts into the scheduler, stages the campaigns ready to go, and files the finished version where the office already looks for things. It drafts, the team decides.

The team uses it heavily, and it saves them countless hours already.

And what looks from the outside like one assistant is several jobs sitting under that goal, each of which turns out to be four or five smaller ones underneath, from reading the brief through to the last filing step.

uglysweaters.com is a fun seasonal ecommerce business that I run. The domain dates back to 2007, and the early Wayback Machine captures of the site are hilarious. I bought it a few years ago and use it as my own testing ground. Client work comes with confidentiality, so this is the one I can take apart in public. The designs are AI-assisted, made to my creative direction on top of deep research into the category, the characters and the craft, and production runs on print on demand and knitting partners. If you looked at the site you wouldn't know it's one person and a lot of agents. (If you do go and look, do you like my humour?)

Design. Making one sweater design is not one job. It's a colourway, a character, a set of patterns, the shapes those patterns are built from, and then the making up of the actual product. Each of those has research behind it that had to be done once and written down: what sells in this category and why, the approved characters and what may and may not be done to them, the rules of traditional fair isle knitting, and a library of reusable motifs with their real dimensions.

All of that is written into what these tools call skills, which are just written instructions the AI loads when it needs them, kept in one place so a rule gets changed once instead of in every prompt. There are nine of them for this business. They point at the source documents rather than copying them, so there's one version of any rule and one place to correct it.

The order they run in is fixed:

1. Colour comes first, and it comes from the character. A blue and white capybara in a hot spring becomes a blue and white sweater. A warm fireside duck becomes red and green. There's no house default, because a default is what makes twenty products look like one product.
2. Then the character, which exemplar is used and how it's rendered for a printed garment against a real knitted one, since a knitting machine has hard limits a printer doesn't.
3. Then the patterns, the bands and borders and the rules they obey, including only two colours in any row, because that's what a knitting machine can do.
4. Then the shapes, half picked from the house library so that any two products read as siblings, and half invented fresh from that character so the shop doesn't look like twenty unrelated brands.
5. Then it's made up as a printed sweatshirt, a knitted sweater or a tee, each of which needs the artwork assembled differently.
6. Then a separate agent checks it against a numbered list, measuring positions and proportions rather than deciding whether it looks right.
7. Then it comes to me, and I approve it before a cent is spent with a production partner.

Twenty one characters have been through that sequence, and they carry 241 products: 83 tees, 79 matching sets, 46 for children, 35 sweatshirts, 30 knits, and the vests, the dog sweaters and the party goods. One design becomes a sweatshirt, a knitted crew, a vest, a matching version for the dog and a tee.

One of the agents is customer facing. Somebody can upload their own artwork and get back a design in the house style on a real garment. The colours of what they send are read and fitted onto the same value ladder the in-house designs use before the model is asked for anything, the design is rendered, a second model looks at the result and the original and gives a verdict, and then ordinary code assembles the print files to the exact dimensions the manufacturer needs, produces the mockup, and records the customer's approval against the order. That approval record is what says, later, exactly what they agreed to.

The production happens in batches, ahead of the season. The articles were written in September for November. The posts and the videos were made in one run and scheduled out to January. The campaigns were written and put in the diary weeks before the first one was due to send. So what happens automatically on any given day is publishing something that already exists, and the schedule is doing the distributing rather than the deciding.

Around that sits the watching. Small checks run through the day on their own timetables, confirming the shop is up, the payments work, the orders reached the manufacturer and the product feeds are alive. They email me only when something changes, plus one short note a day to say the monitoring itself is still there.

So the agents are not sitting at the desks all week. They come in, produce a season's material against the rules, and go away again, and I bring them back when the queue needs refilling or something needs deciding. Continuous would be dearer, slower and harder to check.

What all of it costs to run, and how you prove one of these works before you leave it alone, is a subject of its own. I will come back to it next week.

An agent takes over the producing. It does not take over running the business, and the list of what is left is longer than people expect. Five things came back to me on both builds, and I would expect them on yours.

You do not have to build one of these to make good decisions about them. What you need is a view on which of your own operations could be handed over, and enough of the mechanics to tell a serious proposal from an expensive one. Two things get you there, and neither is technical.

Look for the jobs somebody could describe. The test of whether something can be handed to an agent is whether a person in your business could write down how it is done, in enough detail that a capable new starter could follow it. Repeated, describable, and governed by rules you could state out loud. If nobody can describe it, no agent can do it, and that tells you something about the process rather than about the technology.

Know what to ask. When an agent is proposed to you, by your own team or by somebody outside, four questions separate a serious proposal from an expensive one. What does one run cost, and how many times a day will it run. Who approves before anything reaches a customer. What happens when it gets something wrong. And how will you show me it was tested, rather than telling me it works.

If you want the order to do the wider job in, the last episode of the Learn series covers the foundations, including the policy that decides which tools are approved and who has oversight of them.

The tools are available to everybody and they get cheaper and more capable every few months. Availability is not the same as use. There is a distance between using AI, having it do a whole job, and having it run without somebody watching every step, and crossing that distance is where the advantage sits at the moment. Further along, among the businesses that have crossed it, what separates them is whether somebody can say precisely how the job is done and can tell a good result from one that merely reads well. Both of those are ordinary management skills. Neither is technical, and neither is new.

Which is why the phrase "we just did it with AI" irritates me every time I hear it. It skips the person who decided what good looks like, wrote it down, tested it against the awkward cases, and kept checking it once it was running. That is where the value went. It did not disappear into the tool.

You have spent years learning your own field, which means you know what good looks like when it comes back, and you can tell an ordinary answer from a right one. That is the half you already have.

Kristina Agustin is the Founder and Principal Digital Navigator of Southern Sky AI, helping maritime and professional organisations adopt AI with capability and good governance.