How to Build a Custom AI Employee That Actually Runs

How-to — 2026-09-11 — by Mahmoud Zalt

Build a Custom AI Employee in seven parts: model, tools, memory, trigger, guardrails, monitoring, error handling. Plus the honest work after the demo.

You probably already had the good moment. You connected a model to one API, asked it to do something real, and it did. Then you left it alone for a week and came back to find it had answered the same request four times, missed the one that mattered, and left no trace of why.

That gap is normal. It is not a sign you picked the wrong framework. It is the difference between a script that can do a task once and a system that can do a task every day, under conditions nobody wrote down.

The loop itself is short. The model gets a goal, picks an action, calls a tool, reads the result, and decides what comes next, until the goal is met or a budget runs out. Almost every agent framework on the market is a nicer wrapper around those five lines.

The reason most people never finish is that the interesting part ends early and the tedious part lasts for months. That is also the reason we built Sistava. All seven parts are already assembled and watched, so you describe the job in plain English, connect the accounts it needs, and hire an AI Employee to do it. Building it yourself teaches you more. Hiring one gets you the output this month. Both are honest choices.

At a Glance

7: Parts in every agent that survives
1 day: To get a demo that impresses you
90%: Of the effort is after the demo
1 job: Where every good agent starts

What is actually inside a custom AI agent?

Seven things. A model that decides, tools that act, a memory that carries facts between runs, a trigger that starts the work, guardrails that stop bad actions, monitoring that shows you what happened, and error handling that decides what to do when a step fails. Miss any one and the agent works right up until it does not.

Most tutorials cover the first two and stop. That is why so many agents look finished and behave like a first draft. Here is what each part is really for.

The model. The decision maker. Pick one family and stay with it until you have evidence another one is better on your own tasks. Swapping models to chase a benchmark is the most common way to waste a week.
The tools. Functions the model can call: read a row, send a message, search a document, update a record. Ten sharp tools beat forty overlapping ones, because every tool name sits in the prompt of every single call.
The memory. Two kinds. Short term is the running conversation inside one task. Long term is what the agent still knows next week. A plain structured notes file beats a vector database for a long time.
The trigger. A schedule, a webhook, an inbox rule, or a person typing. Without this you do not have an agent, you have a command you keep running yourself.
The guardrails. A step limit, a spend cap, an allowed list of tools, and an approval gate on anything a customer will see. These are the bumpers that stop one bad loop from becoming a bad week.
The monitoring. Every run recorded: what it decided, which tools it called, what came back, what it cost. If you cannot answer what happened yesterday in under a minute, you are flying blind.
The error handling. What happens when a tool times out, an account disconnects, or the model returns nonsense. Retry, back off, stop, or ask a human. Choosing per tool is the difference between a quiet failure and a loud one.

How do you choose the first job to build for?

Pick a job you could describe in five bullet points and hand to a new starter without a meeting. It should happen often, produce something countable, and have an obvious right and wrong answer. Well specified beats important for a first build, every time.

The temptation is to start with the job that hurts most. That job usually hurts because it is vague, political, or needs judgment, which are exactly the conditions an agent handles worst. Start with the boring, repetitive, checkable one and you will learn how agents fail while the stakes are low.

A useful test: write the definition of done before you write any code. If you cannot say in one sentence what a good result looks like, you will not be able to tell whether the agent is improving, and you will spend your evenings arguing with a machine about taste.

A worked example: Nadia and the interview backlog

Nadia is a freelance UX researcher. She runs about twelve customer interviews a month for three clients, and every one produces a recording she never has time to write up properly. Her job description for the agent was one line: turn each new recording into a tagged summary in the right client folder.

Her first version took a weekend. A model, three tools, and a manual run. It worked on the two recordings she tested it with. The next three weekends were the real build, and none of them were exciting.

Weekend two, the trigger. A watcher on the recordings folder, plus a record of which files had already been processed, so a restart did not redo eleven of them.
Weekend three, the guardrails. A step limit of twelve, a hard stop if the same tool was called with the same arguments twice, and a rule that nothing gets written into a client folder until the summary passes a length and format check.
Weekend four, the boring half. A log of every run, an alert to her phone when one failed, and a retry that backs off instead of hammering an API that is having a bad afternoon.

Her honest summary afterwards: the part she was excited about took ten percent of the time. The part that made it trustworthy took the rest. That ratio is not unique to her, and it is the single most useful thing to know before you start.

What will a custom AI agent not do, however well you build it?

It will not hold a long thread of context the way a person does. Across a task that spans days, agents lose the plot: they repeat work, act on a plan that went stale three steps ago, and confidently continue after the premise changed. This is the failure pattern that keeps showing up in serious agent benchmarks, and no prompt fixes it.

It will also not chase a real human until they reply, read a room, decide what matters this quarter, or take legal responsibility for a signature. Anything physical is out. Anything where the standard for done lives in someone's head and not on paper is out too.

Build inside those edges and an agent is genuinely useful. Build across them and you will spend your time supervising something that was supposed to save you time.

Build it in this order

Write the definition of done first — One sentence describing a good result, plus three real examples you already know the right answer to. This is your test set for the entire project.
Build the smallest version by hand — One model, three tools, no framework, run it yourself. Two hundred lines teaches you more about how agents fail than a month of tutorials.
Add the trigger and make it repeat safe — A schedule or a webhook, plus a record of what has already been handled. Assume every trigger fires twice, because eventually it will.
Put the guardrails in before the first unattended run — Step limit, spend cap, allowed tools, and an approval gate on anything a customer sees. Not optional, and much harder to retrofit.
Log everything, then alert on failure — Every decision, tool call, result and cost in one place you can query. Then a message to you when a run fails, not a silent skip.
Run it against your examples on every change — Prompt tweak, model swap, new tool, rerun the same three cases. Without this you cannot tell improvement from luck.

Notice how little of that list is about the model. Model choice matters, but it is one decision among seven, and it is the one you can change later with the least pain. The parts that are hard to retrofit are the trigger, the guardrails and the logging, which is exactly why they belong early.

Part	How it usually breaks	The cheap fix
Model	Picks the wrong tool when two do similar things	Merge overlapping tools, sharpen the descriptions
Tools	Sends the same message twice after a retry	Pass a deduplication key in from the caller
Memory	Context grows until the model loses the signal	Fold old turns into a structured summary, keep the goal
Trigger	Fires twice, work happens twice	Record the trigger ID, short circuit duplicates
Guardrails	One runaway loop burns a month of budget	Hard step limit plus a spend cap per run
Monitoring	Nobody notices it stopped working for nine days	Alert on failure and on silence, not just errors
Error handling	A dead account fails quietly forever	Stop after three identical failures and tell a human

FAQ

How long does it take to Build a Custom AI Employee?

A working demo takes an afternoon. Something you trust to run unattended takes three to six weeks of part time work for a single, well defined job. The demo is the model and the tools. The rest of the time goes into the trigger, the guardrails, the logging and the error handling, which is where the reliability actually lives.

Do I need to know how to code to build an AI agent?

To build one from scratch, yes, enough to call an API, handle errors and read a log. There are no code builders that get you a long way without that, and they are a genuine option for simple, low risk jobs. If the job touches customers or money, someone still needs to understand what happens when a step fails.

Which framework should I use to build an AI agent?

Start without one. Write the loop yourself in about two hundred lines so you can see every decision your agent makes. Once you know where it hurts, pick a framework that solves that specific pain, usually state handling for long tasks. Choosing a framework before you have felt the problem means inheriting somebody else's answer to a question you have not asked.

What is the hardest part of building an AI agent?

Making it behave the same way on the hundredth run as on the first. Models are non deterministic, tools time out, accounts disconnect and triggers fire twice. Handling all of that gracefully is unglamorous engineering, and it is roughly ninety percent of the total work on any agent that runs in the real world.

How do I stop my AI agent from running up a huge bill?

Three limits, all set before the first unattended run. A maximum number of steps per task, a spend cap per run and per day, and a rule that stops the loop when the same tool is called with the same arguments twice. Add an alert when any of them trips, so a stuck agent becomes a message rather than an invoice.

Should I build my own agent or use a platform?

Build if the agent is your product, if the workflow is unusual enough that no platform models it, or if learning the craft is the point. Use a platform if you want the work done and the agent is not the thing you sell. The wrong answer is the middle, half a framework you never read, running unwatched with no logs.

If you take one thing from this, take the ordering. The parts that feel like the project, the model and the clever prompt, are the parts you will change most often and worry about least. The parts that feel like chores are the ones that decide whether anyone can rely on what you built.

So pick one job, write down what done looks like, and build the smallest thing that does it. Then spend the boring weeks. That is the whole path, and there is no version of it where the boring weeks are optional.