Start with a job.
Not with a model.

Pick one job with a visible result.

Most AI agent projects fail before any code is written, at the moment someone says the agent should handle customer service. That is a department, not a job. An agent needs a task with a defined input, a defined output, and a person who can say whether the output was right.

Good first jobs look like this: qualify an enquiry and record five fields in the CRM. Answer staff questions from the policy manual and cite the page. Extract the fields from an inspection report into a template for review. Draft the follow up message for a quote that has gone quiet. Each one has a clear boundary and a clear owner.

Write the job down in one paragraph before choosing anything else: what arrives, what the agent must produce, what it must never do, and who checks the result. That paragraph is the specification, and every later decision is tested against it.

Know which of three shapes you are building.

The word agent covers three different things, and the difference decides the build. The first shape is an assistant that answers: it reads approved information and responds, with no ability to change anything. The second is a workflow with an AI step: a fixed sequence in which the model classifies, drafts, or extracts and the workflow does the rest.

The third shape is an agent with tools: the model decides which actions to take, calls tools to read or write systems, checks the result, and continues until the job is done or it needs a person. This is the shape people usually mean, and it is the one that needs the most care, because the model is choosing actions rather than following a script.

Start with the simplest shape that does the job. A surprising amount of value sits in the second shape, and it is far easier to test. Move to the third when the task genuinely needs the model to decide what to do next, not just what to say.

Prepare the information the agent will use.

An agent is only as reliable as the information it reads. Before connecting a model to your documents, decide which sources are approved, who keeps them current, and which parts a given user may see. A policy manual with three conflicting versions produces an agent that confidently cites the wrong one.

Separate the facts that change from the instructions that do not. Prices, availability, and customer records belong in systems the agent reads at the moment it needs them. Tone, rules, and boundaries belong in the instructions. When a fact is baked into the prompt, it is stale the day it changes and nobody notices.

For question answering, retrieval from a prepared collection of documents works well when the collection is small enough to curate. Chunk the documents sensibly, keep the source reference with every chunk, and make the agent show which source supported its answer. When the sources do not contain the answer, the correct behavior is to say so.

Give it tools with limits.

A tool is a function the agent can call: look up a contact, read an order, create a task, send a message. Start with read tools. An agent that can only read cannot do damage, and you learn a lot about its judgment by watching what it looks up and what it concludes.

Add write tools one at a time, each with its own limit. A tool that creates a CRM task is low risk. A tool that sends a message to a customer is not, and it should either draft for approval or operate inside rules the business has agreed: which customers, which hours, which topics. A tool that moves money should not exist in a first version.

Every write tool needs to be safe to call twice, because agents retry and models repeat themselves. Store a key for each intended action and check it before the side effect, the same pattern the duplicate actions guide describes for workflows. Validate the tool’s inputs in code; do not trust the model to format an identifier correctly.

Choose a stack you can operate.

If your business already runs n8n, its AI Agent node gives you tools, memory, and model choice inside the workflow builder, and the surrounding workflow handles the parts an agent should not: validation, storage, notifications, and the handoff to a person. The n8n advanced AI documentation covers the nodes. For most small businesses, this is the fastest path to a working agent that the team can see and edit.

When the logic is custom, the volume is high, or the agent lives inside an application your team uses, build it in code with the model provider’s SDK. Each major provider documents an agent loop with tool calling and structured outputs; the Claude tool use documentation is one example. Code gives you full control over prompts, tools, evaluation, and the interface people use, at the cost of needing an engineer to change it.

Hosted agent builders sit in between and change quickly. Whatever you pick, choose the model by testing it on your real tasks rather than on benchmarks, and keep the model swappable. The instructions, tools, and evaluations are the durable part of the system; the model is a component you will replace.

Decide what it remembers, and where.

Conversation memory is the transcript the model sees. Operational state is what the business needs to know: which customer this is, what stage they are at, who owns the next step, what was already sent. The first lives in the model’s context. The second belongs in your CRM or a database, where a person can read it and a workflow can act on it.

Keeping those two apart is the single design decision that most separates a demo from a system. In the bilingual sales system I built, the conversation memory served the reply, and the qualification fields, the property, and the handoff state were written to records that existed whether or not the conversation continued.

Decide how long conversation memory lasts and what happens when a person takes over. An agent that keeps replying after a human has joined the thread is a common and embarrassing failure, and it is prevented by a single field in the operational state.

Test it like software, because it is.

Collect twenty to fifty realistic inputs before you build: real enquiries with details removed, awkward questions, incomplete records, messages in the wrong language, and a few that should be refused. Write down the acceptable output for each. This set is your test suite, and it grows every time the agent surprises you.

Run the set on every change to the instructions, the tools, or the model. Score the outputs against the acceptable answers, and keep a short list of unacceptable behaviors that fail the whole run: inventing a price, promising a delivery date, giving legal advice, acting without the approval the job requires.

Structured outputs make this tractable. When the agent must return fields, ask the model for a defined shape and validate it in code. A free text answer is hard to score; a JSON object with five fields is easy. The evaluation is the part of the project most teams skip and most teams regret skipping.

Roll out with a person in the loop, then widen.

The first version runs beside the existing process, not instead of it. The agent proposes, a person approves, and the record shows both. A few weeks of that produces two things: trust from the team, and a list of the cases the agent gets wrong.

Widen the agent’s authority by category, not all at once. Let it send the routine acknowledgement unattended once the approvals show it never gets that wrong, while quotes and complaints still route to a person. Keep the handoff fast and visible: the agent should know when to stop, and the person should see the full context when it does.

The operations platform case study shows this pattern inside an application: scoped tools, independent review, and approvals attached to an exact version of what was proposed. The same idea applies to a single n8n workflow with an approval step.

Count the real costs.

Model usage is usually the smallest line. The larger ones are the time to prepare the information, the review time the agent needs while it earns trust, and the maintenance when a source, a tool, or a model changes. A quote that covers only the build is not a quote for a working agent.

Measure the result against the job you wrote down, not against a general claim of efficiency. Complete records, faster first responses, fewer missed follow ups, and hours moved from typing to reviewing are countable. Recovered hours are not automatically a cash saving, and it is better to say that up front.

If a simpler rule or an existing feature in your software does the job, that is a good outcome of the assessment. AI earns its place by being useful, and an agent that exists because agents are fashionable is a maintenance cost with no owner.

First agents worth building in a small business.

These are the jobs I see deliver most reliably, with the boundary that keeps each one safe. They are described in more depth under AI agents and knowledge systems.

Enquiry qualification

Reads a website or message enquiry, asks the missing questions, records agreed fields in the CRM, and hands to a person with the context collected. Boundary: it never quotes a price or promises a date.

Internal knowledge assistant

Answers staff questions from approved documents with the source shown. Boundary: read only, respects document permissions, says when the sources do not answer.

Document extraction with review

Pulls fields from reports, forms, or contracts into a template for a person to confirm. Boundary: mapping is deterministic, and nothing is sent until reviewed.

Quote follow up drafting

Drafts the follow up for a quote that has gone quiet, from the actual line items and the customer’s messages. Boundary: a person approves anything beyond a reminder, and the sequence stops when the customer replies.

Support triage

Reads inbound requests, classifies urgency and topic, gathers the order or job context, and routes to the right person with a summary. Boundary: it prepares, it does not resolve.

Questions.