Most people who want to build an AI agent never ship one. Not because it is hard. Because everything they read sounds either too abstract or too hyped. Strip the noise away and an agent is one simple thing: a model in a loop, with tools.
The whole machine runs on one heartbeat. Request goes to the model. The model picks a tool. The tool runs. The result goes back to the model. The model decides the next step. Repeat until the answer is ready.
Here is the path we follow when we build one, and the same path you can follow this week.
1Pick one job, not a general agent
Forget the universal assistant. Pick one specific job you want done. Book an appointment. Watch job boards and send matches. Summarize unread email. Answer questions over a pile of documents.
The smaller and clearer the job, the easier the agent is to design, test, and debug. Every failed agent project we have seen started with a scope that fit on a poster instead of a sticky note.
Write the job as one sentence with a visible result. "Answers questions about our case archive with citations" is a job. "Helps the team with knowledge" is not.
2Use a model that already exists
Do not train anything. Pick a capable model off the shelf: commercial or open source, whichever fits your constraints. The only requirements are solid reasoning and reliable structured output, because the model has to pick tools and read their results.
Keep the model swappable behind a config setting. Models improve every quarter. Your agent should get smarter by changing one line, not by rebuilding.
Put the model name and endpoint in configuration, not in code.
3Give it a few focused tools
A chatbot talks. An agent acts. The difference is tools: the small set of actions the model can call. Search these files. Read this record. Query this API. Send this email.
Resist the urge to hand it everything. A few sharp tools beat a hundred overlapping ones. And skip the fancy retrieval stack on day one. If your knowledge lives in a few thousand files, plain search over those files gets you shockingly far. Add vector databases only when real usage proves you need them.
List the three to five actions your job actually needs. Those are your tools. Cut the rest.
4Wire the heartbeat
No heavy framework needed. The skeleton is small enough to hold in your head:
- Take the user's request.
- Send it to the model with instructions and the tool list.
- If the model asks for a tool, run it and feed the result back.
- Let the model decide the next step.
- Stop when it produces a final answer, and always cap the number of turns so a confused agent cannot spin forever.
That cap matters more than it looks. A turn limit is the first brake you install, and every agent needs brakes before it needs freedom.
Build the plainest possible version of this loop with one tool. Make it answer one real question end to end.
5Keep memory and the interface boring
Beginners assume agents need elaborate memory systems. They do not. Start with the recent conversation. If knowledge must survive between sessions, write it to a plain file the agent reads on startup. A markdown file the agent can append to is a real memory system, and you can inspect it with your own eyes.
The interface can be just as boring. A command line first. Then a small web page or a chat channel once the loop works. The interface is packaging. The loop is the product.
Give your agent one file it can write lessons to and read back next session. Watch what it chooses to remember.
Then test it on real work
Do not polish in private. Give the agent real tasks, watch where it breaks, patch it, run it again. Every reliable agent we have shipped went through dozens of these cycles. The failures are the curriculum.
And keep the scope locked. A single well-functioning agent that does one job beats a universal agent that keeps failing. When someone asks for a new capability, that is usually a second agent, not a bigger first one.
What this looks like in practice
We recently built a research assistant over roughly 1,900 regulatory case reports. One job: answer questions about the cases with exact citations. One existing model behind a config setting. Three tools: search the case files, read one case, and filter cases by structured facts like company, outcome, or clause. Plain files with structured front matter, no vector database. A capped loop drives it, and a small skills file lets it keep lessons between sessions, like which phrasings find cases faster.
It went from idea to a working tool in days, not months. Not because of exotic engineering. Because the job was narrow, the tools were few, and the loop was simple.
The next level
Once your first agent works end to end, you have already learned the full pipeline, and the second one takes a tenth of the effort. Then the interesting work begins: turning the loop you babysit into a loop that runs itself, with real checks, hard brakes, and a verifier that can say no. We wrote the guide for that step too: How to Implement Loop Engineering in Your Project, at radicalloop.com/blog/loop-engineering.
Start with one job. Wire one loop. Let it compound from there.