How to build an AI agent for a small team: pick the route, write the spec, test it on old work
You run operations at a firm of twelve people. Every Monday someone spends two hours pulling last week's numbers into a Slack post, and every Thursday someone else chases the invoices that are past due. You have read that an AI agent could take one of those jobs, so you search for how to build an AI agent and get two kinds of answer: coding tutorials for developers, and builder vendors whose first step is "pick a platform", meaning theirs.
Neither tells a team without a developer what to decide first. Most agents that go wrong at a small firm go wrong on three questions the tutorials leave for later: whose account the agent uses, which of its actions a person must approve, and how you know it works before it touches a real customer or a real invoice. This guide answers those three first. You get a table of the three routes and what each asks of you, a one-page spec to fill in before you choose, a worked example in a Slack thread, and a test you can run in an afternoon.
The short answer
Building an AI agent at a small firm comes down to five steps, in this order:
- Pick one recurring job with a clear owner and a clear finish, such as "the Monday numbers post" or "the Thursday overdue invoice list".
- Fill in the one-page spec below: trigger, sources, actions, whose account, approvals, refusals and three test cases.
- Choose the route the spec points to: write code against a model's API, assemble the agent in a no-code builder, or set up an agent that already works in Slack.
- Run it on three past examples whose right answer you already know, and compare.
- Let it run on live work with a person approving every change, and widen what it may do only after a few clean weeks.
The rest of this article explains each step and why the order matters.
What an AI agent is made of
Anthropic's guide to building effective agents draws a useful line. A workflow follows steps that someone wrote down in advance; an agent decides its own next step and which tool to use. The same guide recommends the simplest thing that works and adding complexity only when it is needed, and warns that the freedom which makes agents useful also brings higher costs and errors that compound from one step to the next.
OpenAI's practical guide to building agents breaks every agent into three parts: a model that reasons, tools that let it read and act in other systems, and instructions that set its behaviour and limits. It also says which jobs suit an agent: ones that need judgement on exceptions, ones whose rules have grown too tangled to keep up to date, and ones that mean reading messy text such as emails and documents.
For a small firm, the model is the easy part: you rent it. The tools are where the risk sits, because a tool is a connection to your Gmail, your CRM or your accounting app, and the agent can do whatever that connection allows. The instructions are where the work sits, because nobody has ever written down how the Monday report is actually made.
Most beginner guides at the top of the search results skip the tools and instructions questions. The Botpress beginner guide walks through seven steps from scope to monitoring, mentions Slack only as a place to deploy, and has no section on whose access the agent uses or on approval before it acts. monday.com's beginner guide does mention least privilege and approval for high-stakes actions, and says a first agent on a no-code platform takes 30 minutes to two hours. That figure is the vendor's claim for a simple agent; it does not include writing down the job, which is usually the longer part.
Three routes to an AI agent, and what each asks of a team with no developer
| Route | What you do | Who keeps it running | Fits when |
|---|---|---|---|
| Write code against a model API | A developer writes the agent, connects each tool's API and hosts it | That developer, for as long as it runs | You have a developer with time, and the job needs logic no product offers |
| Assemble it in a no-code builder | You drag steps together in an automation tool, add an AI step and connect accounts | Whoever built it, usually the ops person; every change to a connected app can break a step | The trigger and steps are fixed and you are happy to own a small system |
| Set up an agent that already works in Slack | You connect your own tools to an existing agent and describe the job in a thread | The vendor maintains the agent; you maintain the instructions and the schedule | The job is reading, summarising and making small, approved changes in tools you already use |
The coding route gives you the most control and the most upkeep. Anthropic's guide suggests developers start with the model's API directly rather than a framework, and understand any framework they do use. That is good advice for a developer and a clear signal for everyone else: if nobody at your firm can read the code, nobody can fix it when it breaks at 7am on a Monday.
The no-code route is where most "no code AI agent" searches end up. Builders such as Zapier and n8n let a non-developer chain a trigger, an AI step and a few actions. They work well for fixed sequences. Later, the person who built it becomes its only maintainer, and the builder usually runs on whichever account connected each app.
The third route skips the building. The agent already exists; your job is the spec, the connections and the approval rules. It suits a team whose work already lives in Slack threads, and it is the route this article's worked example uses.
Write the spec before you choose a route
Write the spec before you choose a route, because the trigger, the sources and the actions decide the route, not the other way round. If the job starts from a webhook in your billing system and must run in a fixed order every time, that points to a builder or to code. If the job starts with a person asking a question in a thread and needs judgement on what it reads, that points to an agent. You only find out which by writing it down. This is a recommendation, built on OpenAI's three parts: the spec is simply the instructions and the tools, written before anyone touches a product.
OpenAI's guide also says to build instructions from the documents you already have: operating procedures, scripts and policy pages. Most small firms have none for the job in question, so the spec doubles as the first procedure.
Copy this into a Slack canvas or a doc and fill it in for one job:
| Field | What to write | Example: the Thursday overdue invoice list |
|---|---|---|
| Job and owner | One sentence and one name | List invoices more than 14 days overdue and draft a nudge for each. Owner: Dana, ops |
| Trigger | What starts it | Every Thursday at 9am, or Dana asks in #finance |
| Sources | Where it reads, and nothing else | The accounting app's open invoices; the client channel for recent notes |
| Actions | What it may change or send | Draft a reminder email for each invoice. Send nothing on its own |
| Whose account | The person whose access it uses | Dana's own accounting and Gmail access, not a shared admin login |
| Needs approval | Every action a person must confirm | Each email before it is sent |
| Must refuse | What it says when it does not know | If an invoice has a dispute note, list it apart and draft nothing |
| Test cases | Three past runs with known answers | The lists from three past Thursdays, with what Dana actually sent |
The whole spec fits on one page. If you cannot fill in a field, the job is not ready for any route yet, and that is worth knowing before you spend a week on a builder.
Decide whose account it uses before anything else
Decide whose account the agent acts with before you pick a tool, because an agent that runs on one shared admin token can do anything that token can, whoever asked.
The beginner guides treat this as a setting, yet it decides how much damage one bad run can do. In a widely discussed Hacker News thread about an agent that deleted a production database, the author and many commenters put the main fault on a token with far more permissions than the task needed, and several argued the fix had to be permissions, not a polite confirmation step. Those are one team's report and commenters' opinions, not a study, but the mechanism is general: the agent's reach is the token's reach.
At a small firm, the agent should act with the access of the person who asked, so it can only see and change what that person could. A shared login that "everyone uses" turns every request into an admin request. If a route only works with a shared admin account, count that as a cost in the table above.
OpenAI's guide lists the actions that should go to a person until you trust the agent: anything sensitive, irreversible or high stakes, with cancelling orders, authorising large refunds and making payments as its examples. It also says to hand over to a person when the agent keeps failing at a task. Put both in the "needs approval" and "must refuse" rows of your spec.
A worked example in a Slack thread
Here is the overdue invoice job run on the third route. The names and figures are made up for illustration.
Dana posts in #finance: "@Kipwise list invoices more than 14 days overdue and draft a reminder for each. Skip any with a dispute note."
The Kipwise agent is mentioned once; after that, plain replies in the same thread continue the work. It reads the connected accounting app with Dana's own access, because each connected tool uses the asking person's own account and permissions. It replies with four invoices, the amount and days overdue for each, and one invoice set apart because its notes mention a dispute. For the four it drafts a short reminder.
Dana edits one draft in the thread ("make the Acme one softer, they paid late last time too") and asks it to send them. Before anything goes out, the agent shows an Approve or Deny card. Only Dana, who asked, can press it; the card expires after 30 minutes, and denying it or letting it expire means nothing is sent. The details are in our post on human approval for AI agent workflows in Slack, and the access model is covered in Slack AI agents and per-user permissions.
Once the run looks right, Dana asks: "Do this every Thursday at 9am and post the list here." Creating the scheduled task needs her approval once; its later runs do not ask again, as described in scheduling recurring AI agent jobs in Slack. Choosing which clients get a softer note, deciding what to do about the disputed invoice and talking to the client stay with Dana.
Nobody wrote code or drew a flow chart. The spec became the first message, the approval rule became the card, and the trigger became a schedule. If you want help phrasing that first message, our guide to briefing an assistant or an AI agent in Slack covers it.
When it goes wrong
Plan for four failures before the first live run.
- It reads the wrong thing. The sources row in your spec is your guard. If the agent pulls from a channel or folder you did not list, tighten the instructions or remove the connection.
- It is confident and wrong. The "must refuse" row exists for this. An agent that guesses on a disputed invoice is worse than one that says "I can't tell, here is why". Ask it to show where each figure came from.
- A connected app changes. On the code and builder routes, a renamed field can break a step silently. Whoever maintains it needs a weekly glance at the output, not just at errors.
- Nobody owns it. The interview research summarised in a Hacker News discussion of agents in production reports that the teams which got value started with tightly scoped tasks that were easy to check, and that most still keep a person reviewing output. Put a name in the owner field and keep it there.
Anthropic's guide gives the matching advice for builders: test in a safe environment, add guardrails, and let the agent stop for a person at checkpoints or when it is stuck.
Verify it works before it sees live work
Test the agent on three past examples whose right answer you already know before it sees a live one. Take three past Thursdays, give the agent the same starting point, and compare its list and drafts with what Dana actually sent. You are checking four things:
- Did it find the same invoices, no more and no fewer?
- Did it set aside the one that needed a person?
- Would you have sent its drafts with light edits?
- Did it say when it could not tell, instead of filling the gap?
This is a recommendation rather than a rule from either guide, but it follows Anthropic's advice to test in a sandbox before real use, and it costs an afternoon. Past examples beat made-up ones because you already know the right answer, and they include the awkward cases that made the job tedious in the first place.
If two of the three runs match, go live with approval on every action and check each run for two weeks. If fewer match, the spec is usually the problem, not the model: a source is missing, or a rule lives only in someone's head. For a fuller test plan, see our guide to testing AI agent workflows in Slack.
After a few clean weeks, widen one thing at a time: a second source, a second action, or fewer approvals on low-risk steps. Choosing which job to hand over next is covered in AI agents for a small business: what to hand off first and agentic workflows for a small Slack team.
What to do next
Pick the one job that costs your team the most hours each week and fill in the eight-field spec for it today, including the three past examples. That page tells you which route fits. If the answer is an agent that works in your Slack threads, the Kipwise agent costs $10 per user per month with a minimum of three users, as shown on the Kipwise pricing page: connect the one tool your spec names and run it on your first past example in a thread before you decide anything else about how to build an AI agent for your team.
