How to build an AI agent on Windows, without a framework

What an agent actually is

Strip the marketing and an AI agent is a language model with three additions. The model proposes. The additions make it capable:

A chatbot is a model with no tools and almost no memory: it proposes, you execute. An agent executes inside a permission boundary you set. The interesting engineering — and the interesting failure modes — all live in those three additions.

Part 1 — Instructions: the job and the rules

Instructions are the agent's standing orders. Not "you are a helpful assistant" — that describes a mood, not a job. A usable instruction set answers four questions:

• What is the job? "Turn described outcomes into working files in this folder."
• What is the boundary? "Work only inside the project folder. Never touch files outside it."
• What must you ask about? Anything destructive or outward-facing — deleting data, sending mail, spending money — stops for confirmation.
• What counts as done? "The thing runs, and you can show what changed." Without this, the agent declares victory after writing code it never executed.

Written this way, instructions are testable. Every rule you add should be a rule you can catch the agent breaking. If you cannot imagine the failure, the rule is decoration.

Part 2 — Tools: the ways it acts

Tools are functions the model can call. A coding agent needs surprisingly few, done well:

• Read a file — and list a directory, so it can navigate.
• Write a file — create or overwrite, inside the boundary.
• Run a command — start the app, run the tests, install a dependency.
• Search — find a symbol or string across the project without reading everything.

Two design points decide whether this is safe or alarming. First, the permission model: read freely, write inside the folder, and gate the genuinely dangerous calls (deleting, network sends, anything outside the boundary) behind confirmation. Second, observability: every tool call should be visible, so "what did it actually do?" is answerable from a log rather than from memory.

Notice what is not required: dozens of integrations, a plugin marketplace, an agent-to-agent protocol. Four solid tools cover most real work. Complexity here is where simple agents become unauditable ones.

Part 3 — Memory: the part everyone underestimates

Memory is what lets turn ten build on turn one. In practice it has two layers:

• Session memory — the running context of the current task: what you asked, what it read, what it wrote, what error it just fixed.
• Project memory — the standing facts about the folder: structure, conventions, where things live. Ideally this is re-derived from the files themselves, because files do not go stale the way summaries do.

The failure you will recognise: an agent that nailed the first feature and then forgot it existed while building the fifth. That is a memory bug, not a model limitation. SAJEEL's approach is to keep project context alive across a long session (sign-in sessions last three days of activity) and to start every task by re-reading files rather than trusting a summary — the "file analysis" stage of its loop.

The loop that keeps it honest

The three parts only produce an agent when they rotate. SAJEEL runs the same seven stages on every request, and it is a good template whether you build your own or not:

The critical stage is testing. A loop without it is a writer: it produces plausible text and stops. A loop with it is a builder: it runs the thing, reads the error, and goes around again. When you evaluate any agent — including ones you build — check what happens in the loop when the first attempt fails. That is the entire product.

Build from scratch, or start from one that exists?

Two honest paths, and the right one depends on why you are here:

1. You want the outcome. Then building the agent is homework, not the goal. Start from a working desktop agent, point it at your folder, and spend your hours on what you actually want to make. The instructions, tools and loop above are already wired — this is the fastest route from idea to running software.
2. You want to understand agents. Then build a small one on purpose. A readable first project: a script that takes a goal, calls a model with your instruction set, and loops over four tools (read, write, run, search) with a stop condition and a log. Add memory second — re-reading files at each turn is a legitimate v1. Leave integrations for later; they teach you nothing that four tools do not.

Most people should do path one first and path two as a learning project on the side. Having used a real agent, you will know which parts of your own build are load-bearing.

A first task worth giving it

Concreteness beats ambition for a first run. This one exercises every stage:

Watch whether it reads before writing, whether files land in your folder, whether it runs anything, and whether the follow-up sentence costs it the context of the first. Those four observations tell you more about an agent than any architecture diagram.

Or skip the build and use one

SAJEEL ships the instructions, tools, memory and testing loop already wired. Download it, open a folder, and give it the first task above.

Download for Windows See how it works