How to Build an AI Agent Without a Developer: Step by Step
Most AI agents do not fail on the technology. They fail because nobody wrote down what the agent was supposed to do.
I have been building agents for our own brands nano, mate and MUSTAX for almost two years. I am not a strong programmer. What I can do is cut a task small enough that a machine handles it reliably. That is what this is about. Six steps, two worked examples, and a list of things you should not build an agent for.
If you are not yet sure what separates an agent from a chatbot, that is covered in What is an AI agent. Here I assume you roughly know the difference.
Step 1: Scope the task as tightly as you can
The most common mistake is wanting an agent that "handles support". That is not a task, that is a department.
A usable task has three properties. It has a clear trigger. It has a clear outcome. And you can say in one sentence when it went wrong.
Badly scoped: "Answer customer enquiries."
Well scoped: "When an email asks about parcel status, pull the tracking state and write a reply with a real delivery date."
The second sentence is testable. The first one is not.
For scoping I always take the last 50 real cases. Not the ones I imagine. The ones that actually came in. Then I sort them by frequency. The biggest pile is your first agent, everything else comes later or never.
For us that biggest pile was "where is my parcel". It accounts for roughly 40 percent of all support requests. So an agent that handles only that single case already takes almost half the work off your desk.
Step 2: Decide what data the agent gets to see
An agent is only as good as its access to your systems. And only as safe as the limits on that access.
Write two lists before you connect anything:
- It may read: orders, tracking status, product data, shipping policies, FAQ text.
- It may write: a draft reply, an internal note. Nothing else.
This split is the most important seatbelt in the whole project. An agent that can only read and draft causes confusion at worst. An agent with write access to refunds causes damage at worst.
In practice that means its own API access, not your admin login. In Shopify you create a dedicated app for it and grant exactly the permissions from your read list. Takes twenty minutes and saves you a very unpleasant hour later.
Step 3: Give it tools, not knowledge
This is where most do-it-yourself attempts tip over. People write the shipping terms into the prompt, meaning the instruction, and then wonder why it quotes wrong deadlines two weeks later.
The rule: anything that can change belongs behind a tool, never inside the instruction.
A tool is a call the agent can trigger itself. "Fetch order by order number." "Fetch tracking status by shipment number." "Look up the text of the returns policy." The agent decides which one it needs and gets the answer fresh from the system.
In n8n you build tools like this as separate nodes and attach them to the agent node. If you have never touched n8n, first walk through your first n8n workflow. After that the agent is just one more building block.
The instruction itself holds only what never changes: the role, the tone, the limits. For us that is about 30 lines. If you need a 300 line prompt, you have usually forgotten a tool.
Step 4: Write the test cases before you build the agent
This feels backwards and is still the shortcut.
Take ten to fifteen real cases from step 1 and write down the correct answer for each. Three kinds have to be in there:
- The normal case. Parcel in transit, date known.
- The edge case. Two open orders, the customer gives no number.
- The case that must escalate. Parcel has not moved for ten days, customer is angry.
That list is your acceptance test. The agent is done when it solves every normal case correctly, asks cleanly in every edge case, and hands off every escalation case instead of improvising.
Without that list the same thing always happens. You test three cases, it looks good, you go live, and in week two the agent replies to a customer with the tracking status of somebody else's order.
Step 5: Build the approval step in, not before it
The first weeks of operation never run without a human. We had three stages, and I recommend the same path to everyone.
| Stage | What the agent does | What the human does | Duration for us |
|---|---|---|---|
| 1 | writes a draft | reads and sends every draft | 2 weeks |
| 2 | sends standard cases itself | checks samples and all special cases | 4 weeks |
| 3 | sends standard cases itself | only receives escalations | ongoing |
The jump from stage 1 to stage 2 comes only after a full week without correcting a single draft. No earlier. And the escalation rules stay hard: refunds, address changes and anything emotional still go to humans to this day.
Step 6: Operating it is the real work
An agent is not a project with an end date. It is a colleague who never tells you on its own that something has stopped working.
Three things you need permanently:
- A log. Every run with input, tools used and output. Without it you cannot trace errors.
- A weekly sample. Read ten cases, ten minutes. We do it on Fridays.
- A kill switch. One toggle that puts the agent straight back into draft mode. You rarely need it, and when you do it is urgent.
What running it costs depends mostly on model calls. A full breakdown of the line items is in What automation really costs.
Example 1: The parcel status agent at nano
Task: answer questions about delivery status.
The trigger is an incoming support email that has been recognised as a status question. A simple classifier upstream does the sorting, no agent involved. Why we separate the two is explained in Pre-sorting support emails with AI.
Tools: find order, fetch tracking status, look up shipping policy.
Flow: the agent finds the order via email address or order number. If it finds two open orders, it asks instead of guessing. It pulls the tracking state, compares it with the promised date and writes the reply.
Escalation: if the shipment has not moved for more than seven days, it does not reply. It files the case with a note.
Effort: just under three days to build, half a day of that for the test cases. Result: this one request type now runs without us. Together with the other automated cases, AI answers around 65 percent of our support requests.
Example 2: The reporting agent at MUSTAX
Task: pull together the Monday numbers and name what stands out.
Tools: query revenue per channel, query return rate, query stock level, fetch previous week.
Flow: the agent pulls the numbers, compares them with the previous week and writes a short text. No dashboard. Five sentences plus one table. Whatever stands out gets named first.
Limit: it may not claim a cause. It writes "return rate on model A rose from 8 to 14 percent", never "because of the new size chart". Language models invent causes readily and convincingly.
Reporting at MUSTAX used to take 2 days. Today it takes 2 hours, and those two hours are reading and deciding, no longer collecting.
When an agent is the wrong choice
This is the section I wish I had read two years ago.
- For fixed if-then chains. Order comes in, label gets created, customer gets an email. An agent there is slower, more expensive and harder to trace than a plain workflow. Our order fulfilment deliberately runs without agents.
- For money without control. Refunds, credit notes, payment approvals. Technically possible. You are liable in the end.
- For rare tasks. Anything that happens twice a quarter justifies neither the build nor the upkeep.
- For processes you cannot describe yourself. If three people on the team give three different answers on how a case should be solved, the process is the problem, and missing AI is not.
- For anything where a wrong answer is expensive and goes unnoticed. A workflow fails loudly. An agent sometimes fails quietly and politely.
We wrote up the choice between agent, chatbot and workflow in detail in AI agent, chatbot or workflow.
Conclusion
An AI agent without a developer is doable. The effort sits somewhere other than you expect.
Building it in n8n takes one to three days. Scoping the task, writing the test cases and setting the approval stages takes longer and decides whether the thing is any good. Flip that order and you build something impressive-looking that does not hold up in daily use.
Start with one request type. Take the most frequent one. Let it write drafts only for two weeks. After that you will know more about your own processes than any workshop would teach you.
If you are unsure whether your task should be an agent at all, write to us at Flowhouse. We will also tell you when a simple workflow is enough.