The short version: an AI agent is a model you have given a job, a set of tools, and a standard to hold itself to. The model is the easy part. The standard is the part everyone skips, and it is the part that decides whether the thing is useful or just confident.
I build these for a living. My agents run on my own documented marketing standards, the same ones my team works from. Here is how I build one, start to finish, using Claude. No hand-waving, no "and then the AI figures it out". Just the steps.
New to all of this? If agent, workflow and loop are still fuzzy words, start with the plain-English guide: What are AI agents? Then come back here to build one.
On this page: Write the standard · The system prompt · Tools and MCP · The loop · Testing · Human gates · Shipping · FAQ · References
Most people build an agent by opening a chat window, writing "you are a helpful marketing assistant", bolting on a few tools, and shipping it. Then they act surprised when it invents a campaign that contradicts the brand, emails the wrong segment, or writes three paragraphs where one would do.
The agent did exactly what it was told. It was told almost nothing. An agent trained on nothing produces nothing you would keep. The quality of the output is capped by the quality of the standard you hand it, and "be helpful" is not a standard.
Build the standard first. Then build the agent around it.
Pick one job. Not "do our marketing". Something a competent junior could do with clear instructions: draft a launch email in our voice, triage inbound leads, turn a call transcript into a follow-up. Then write down how you would do it, the way you would brief a person.
For a writing agent, my standard covers the voice rules, the words we never use, how we handle claims (every claim carries a receipt), and three worked examples of good and bad. For a lead-triage agent, it is the qualifying questions, what counts as a fit, and what gets escalated to a human and when. This document is the whole game. If you cannot write the standard, the agent cannot follow it, and you have just found out you do not actually have a process, you have a person doing it from memory.
Claude takes a system prompt: the instructions that sit above the conversation and govern everything the model does. That is where your standard goes, close to verbatim. Not a summary of it. The actual rules, the actual examples.
This one step does more than any other and it costs nothing but the writing. A strong system prompt with real examples beats a clever bit of engineering every time. When the agent drifts, the fix is almost always in here: the rule was missing, or it was vague. Tighten the standard, not the code.
A model on its own can only talk. An agent can act, because you have given it tools: functions it can call to look something up, write something down, or trigger something. You define each tool with a name, a description, and the inputs it takes. Claude reads what is available and decides when to reach for one. You run the tool, hand back the result, and it carries on.
For the plumbing between Claude and the systems you already pay for, use MCP, the Model Context Protocol. It is an open standard for connecting a model to real tools and data through a small server that speaks a common language. There are MCP servers for a lot of the stack already, HubSpot among them, so your agent can read a contact, check a deal, or draft into your CRM without you writing a bespoke integration for each one. This is the difference between an agent that talks about your marketing and one that touches it.
ANATOMY OF AN AGENT THE STANDARD the system prompt THE MODEL reasoning picks the next step TOOLS look up · write · trigger MCP the bridge YOUR SYSTEMS HubSpot CRM · your data The anatomy of an agent: the standard sits above the model, the model calls tools, and MCP lets those tools reach the systems you already run.Strip away the mystique and an agent is a loop:
That is the entire trick. The intelligence is in the model choosing good next steps, and it chooses better steps when the standard is clear and the tools are well described. Most "the agent went rogue" stories are really "the loop had no stopping condition and no standard", which is a design problem, not a mystery.
You wrote the standard down, so now you can grade against it. Collect ten to twenty real cases, run the agent, and check each output against the rules: did it hold the voice, did every claim carry a receipt, did it escalate what it should have. Fix the standard where it failed, run again. This is unglamorous and it is the work. An agent that has never been graded is a demo, not a system.
Pick the model to fit the step, too. The simple, high-volume steps can run on a fast, cheap model. Save the strongest model for the hard judgement. You do not need the most expensive option deciding whether to add a comma.
Automate right up to the point where a mistake costs real money or trust, and stop there. Sending to a list, spending budget, anything a customer sees: those get a human approval before they fire. Everything up to that gate can be automatic. This is not a lack of ambition, it is the design that lets you sleep. My agents draft, prepare, and queue; a person presses send.
Do not launch a fleet. Launch one agent doing one job, watch it for a week against real work, and only widen once it earns it. The standard you refine on the first one is reusable on the next, so the second agent is faster to build and the tenth is faster still. That compounding is the actual return, not the novelty of any single bot.
The model calls are cheap and getting cheaper; that is not where the cost is. The cost is the standard, and it is paid in your time, once, writing down how the work is actually done. Most teams find that the hardest part is not the AI at all. It is discovering that the process they thought they had lived only in one person's head. Writing it down to feed the agent is worth doing even if you never ship the agent.
And it does break. It breaks when the standard is thin, when a tool returns something unexpected, when the job was fuzzier than you admitted. None of those are the model's fault, and all of them are fixable in the standard or the design. That is the good news: the failures are yours to fix, not a black box's to shrug at.
Agents trained on nothing ship nothing. The model is a commodity now, available to everyone at the same price. The standard you give it is not, and that is the whole edge. Build the standard first. The agent is the easy part.
A model you have given a specific job, a set of tools it can call, and a written standard for how the job should be done. The model supplies the reasoning, the tools let it act, and the standard keeps it honest.
Do I need to be able to code to build one?Less than you would think. The hardest and most important part, the standard, is writing, not code. You do need some engineering to define the tools and run the loop, but the quality of the result is decided by the standard, which anyone who knows the work can write.
Why does the standard matter more than the model?Because the model is a commodity now, available to everyone at the same price, while the standard is your process written down, and nobody else has yours. Two teams using the same model get very different agents depending on the standard behind each one.
What is MCP, and why use it?MCP, the Model Context Protocol, is an open standard for connecting a model to real tools and data through a small server that speaks a common language. It saves you writing a bespoke integration for every system: there are ready MCP servers for a lot of the stack, HubSpot included, so your agent can act inside the tools you already pay for.
Where should a human stay in the loop?Anywhere being wrong costs real money or trust: sending to a list, spending budget, anything a customer sees. Automate right up to that gate and stop. The agent drafts, prepares and queues; a person presses send.
I build marketing systems and the agents that run on them, on documented standards, in HubSpot and beyond. If you want one built properly, that is what I do.