How an AI agent gets built (explained without code)

Search for "how to build an AI agent" and you will find two kinds of answers: programming tutorials full of Python, and videos promising a working agent in ten minutes without writing a line. Both are true. Both miss what a business owner actually needs to know. A custom AI agent that works inside a real company is assembled from six ingredients, and behind each one sits a business decision nobody but you should be making.

This article walks through those six ingredients in plain language. Not to turn you into a programmer: so you can follow, and where needed challenge, any conversation with a vendor. If the concept itself is still fuzzy, start with our primer on AI agents, then come back.

The short answer, for the busy

An AI agent is assembled from six ingredients. The language model, rented from a provider like Anthropic or OpenAI, never built from scratch. The instructions, its job description, written in plain language. The tools, what it is allowed to do: check a calendar, send an email, create an invoice. Data access, what it is allowed to see inside your systems. Guardrails, the limits that trigger a handover to a human. And evaluation, a battery of test scenarios that defines what "good" means before the agent goes live, and again after every change. Code is what holds these pieces together; each ingredient, though, maps to a business decision the owner makes without writing a line. For an SMB, a serious agent takes a few weeks to put in place: longer than a ten-minute demo, far shorter than a traditional IT project.

The engine is rented, not built

First ingredient: the language model, the engine that reads, understands and writes. Nobody, not your vendor, not your talented nephew, builds this engine. It belongs to a handful of labs (Anthropic, OpenAI, Google) and is rented by usage, like electricity. When an agency talks about "its proprietary AI", in the vast majority of cases it rents the same engine as everyone else.

The practical consequence: the model is the least differentiating ingredient on the list. Two vendors using the same engine can deliver an excellent agent and a useless one. The entire difference lives in the five ingredients that follow. The only decision that belongs to you here: knowing whose engine is being rented and where your data travels. That is a question to ask, not a technical choice to make yourself.

Instructions: the job description

Second ingredient: the instructions. Concretely, a document several pages long, written in plain English or French, telling the agent who it is, what it does, in what order, in what tone, and what it never does. The work resembles writing an employee handbook for a recruit who is brilliant, fast, and has zero judgment about your business.

Three decisions are yours alone: its exact mandate (answering quote requests, not "helping customers" in general), the tone it uses in your company's name, and what it must never say or promise. A useful reflex when shopping around: ask to read the instructions. Anyone can understand them. A vendor who refuses to show you the job description of your own digital employee is telling you something about the rest of the relationship.

Tools and data: what it can do, what it can see

Third and fourth ingredients, the ones with the heaviest consequences. A model with instructions only makes conversation. What turns it into an agent is tools: connections to your calendar, your invoicing, your CRM, your inbox, that let it act. And data access: your past quotes, your price list, your procedures, so it answers from your reality rather than its general knowledge.

These connections are standardizing fast. Since November 2024, an open protocol, the Model Context Protocol (MCP), has been normalizing how agents plug into external software. Launched by Anthropic, then adopted by OpenAI and Google, it was handed over on December 9, 2025 to the Linux Foundation, which counted more than 10,000 active public MCP servers at the time. Translation: connecting an agent to your systems is less and less custom plumbing and more and more a standard part, which lowers costs and reduces vendor lock-in.

The decisions that fall to you here are the most important of the whole project. What may it do on its own? Reading your calendar commits you to nothing; emailing a client, creating an invoice or issuing a refund does. And what may it see? The moment the answer includes personal information, Quebec's Law 25 governs what you do with it. The prudence rule we apply: an agent starts read-only and earns the right to act, one permission at a time. Our tour of concrete use cases for Quebec SMBs shows what these combinations look like in the field.

Guardrails: where the line sits

Fifth ingredient: guardrails. Explicit limits: the topics it does not touch, the amounts beyond which it stops, the situations that trigger an immediate handover to a human, and a log that records everything it did, so you can audit after the fact.

This is not an anxious engineer's add-on. The development kits from the major labs, Anthropic's Claude Agent SDK and OpenAI's Agents SDK, treat guardrails as a core building block of any agent, on the same level as tools. The decision that belongs to you: which situations require a human, no exceptions. A complaint? A visibly angry customer? A price request outside the list? Nobody can answer for you, because the answer depends on what can genuinely hurt your business.

Evaluation: defining "good" before going live

Sixth ingredient, the one every demo skips: evaluation. A battery of scenarios drawn from your daily reality, the routine request, the confused customer, the edge case, the trick question, each paired with what a good answer must contain. The agent takes this exam before going live, then retakes it after every change, because a tweak to the instructions can improve one scenario and break another.

The decision that belongs to you: what does "good" look like? What error rate is tolerable, and on which questions should it refuse to answer rather than risk one? A serious vendor will make you work on this before launch. If they cannot show you their evaluation grid, they probably do not have one.

The ten-minute demo and the agent that survives Monday morning

The ten-minute agent exists, drag-and-drop visual builders exist, and the demo is often impressive. But look back at the ingredient list: that demo is a rented engine plus summary instructions. No connection to your real data, no guardrails, no evaluation. Three of six ingredients are missing, and they are precisely the ones separating a toy from a digital employee.

Recent industry history illustrates the limit. In October 2025, OpenAI launched Agent Builder, a visual canvas for building agents by drag-and-drop. Eight months later, on June 3, 2026, the company announced its retirement for November 30, 2026, recommending a migration to its SDK, where the agent lives as code that can be tested, fixed and versioned. When the maker of ChatGPT concludes that serious agents do not live in a drag-and-drop tool, the argument deserves a hearing.

Hence honest expectations on timelines: for an SMB, a production agent takes a few weeks to put in place. The time rarely goes into coding; it goes into scoping the mandate, writing and refining the instructions, connecting the systems, setting the guardrails and running the exam. Not six months. Not ten minutes either.

Six decisions that belong to you

You will not write the code, and you do not have to. But the mandate, the tone, the permissions, the accessible data, the red lines and the definition of "good": those six decisions are yours, and a vendor asking for a cheque without having asked you these questions is building blind. Our guide to choosing an AI agent vendor in Quebec turns this list into interview questions.

At Peich, the first conversation is for exactly this: walking through the six decisions together, identifying the task that justifies an agent, and telling you honestly whether the project is worth it. 30 minutes, no commitment.

→ First conversation, no commitment