How to Build an AI Agent From Scratch in 2026

By Lazar Milicevic · Published July 10, 2026 · 9 min read

You've read the LangChain docs three times, cloned two GitHub repos that haven't been updated since last summer, and you still don't have a working agent. Meanwhile your inbox has 40 unread leads and the founder wants a demo Friday. This guide is the walkthrough I wish I'd had — the actual decisions, the code that ships, and honest tradeoffs against no-code platforms.

I'll build one agent end-to-end: a lead qualification agent that reads inbound emails, checks the CRM, drafts a response, and posts to Slack for approval. Real problem, real code, real failure modes.

Step 1: Decide if you actually need an agent

Most tasks people call "AI agent work" are actually workflows with one LLM call in the middle. The distinction matters because agents are 3-5x more expensive to build and run than workflows, and they fail in weirder ways.

Use a workflow if: the steps are known in advance. Read email → extract fields → look up contact → draft reply. That's a pipeline. One LLM call, deterministic glue.

Use an agent if: the model needs to decide which tool to call, in what order, based on what it sees. "Qualify this lead" is agent work because the right next step depends on whether the person is in your CRM, whether they mentioned pricing, whether they're a decision maker, etc.

A quick heuristic:

If you can draw the flowchart, build the workflow. If you can't, you need an agent. For our lead qualification example, the flow branches heavily based on CRM state, so an agent earns its keep.

Step 2: Pick your model and framework

The 2026 landscape has consolidated. You have three realistic paths:

Direct SDK (Anthropic, OpenAI): Best for solo builders who want control. You write the loop, you own the logic. 200-400 lines for a working agent. This is what I recommend for anything you'll run in production.

Agent framework (LangGraph, Pydantic AI, CrewAI): Useful when you have multi-agent coordination or need built-in observability. Adds a learning curve and dependency risk — I've had framework updates break agents twice this year.

No-code (BizFlowAI, n8n with AI nodes, Make): Fastest to a working prototype. Real ceiling on complexity, but for 70% of SMB use cases you never hit it.

For model choice in 2026, the practical picks are Claude Sonnet or GPT for reasoning-heavy agent loops, and a smaller/cheaper model (Haiku, GPT-mini, GLM) for tool-call classification. Don't use your expensive model for every step — I'll show the split below.

Here's the minimum viable agent loop, framework-free:

from anthropic import Anthropic

client = Anthropic()

def run_agent(user_message, tools, system_prompt, max_iterations=10):
    messages = [{"role": "user", "content": user_message}]
    
    for i in range(max_iterations):
        response = client.messages.create(
            model="claude-sonnet-4-5",
            max_tokens=4096,
            system=system_prompt,
            tools=tools,
            messages=messages,
        )
        
        # Model decided it's done
        if response.stop_reason == "end_turn":
            return response.content[-1].text
        
        # Model wants to call tools
        if response.stop_reason == "tool_use":
            messages.append({"role": "assistant", "content": response.content})
            tool_results = execute_tools(response.content)
            messages.append({"role": "user", "content": tool_results})
            continue
    
    raise RuntimeError(f"Agent exceeded {max_iterations} iterations")

That's the entire loop. Everything else is tools, prompts, and guardrails.

Step 3: Design your tools like an API, not a chat interface

This is where most first-time agent builders lose weeks. Your tools are the agent's hands. Bad tool design makes even a smart model look stupid.

Rules I follow:

1. One responsibility per tool. get_contact_by_email is good. crm_actions that takes an action parameter is bad — the model will pick the wrong action.

2. Descriptive parameter names. email_address not q. The model reads these to decide what to pass.

3. Return structured errors, not exceptions. When a tool fails, return {"error": "Contact not found", "suggestion": "Try search_contacts with partial match"}. The agent can recover. An exception kills the loop.

4. Idempotent writes. Agents retry. Your send_email tool needs a dedup key or you'll spam customers. Ask me how I know.

Here's a tool definition for our lead qualification agent:

tools = [
    {
        "name": "get_contact_by_email",
        "description": "Look up a contact in the CRM by their email address. Returns contact record with company, role, deal history, and last interaction date. Returns error if not found.",
        "input_schema": {
            "type": "object",
            "properties": {
                "email_address": {
                    "type": "string",
                    "description": "Full email address of the contact"
                }
            },
            "required": ["email_address"]
        }
    },
    {
        "name": "draft_slack_message",
        "description": "Draft a Slack message for human review before sending. Does NOT send. Returns draft_id that can be sent via send_slack_draft.",
        "input_schema": {
            "type": "object",
            "properties": {
                "channel": {"type": "string"},
                "message": {"type": "string"},
                "context": {
                    "type": "string",
                    "description": "One-sentence explanation of why this message"
                }
            },
            "required": ["channel", "message", "context"]
        }
    }
]

Notice the context field on draft_slack_message. That's not for the API — that's for the human reviewer. Force the agent to justify each action and your debugging time drops by 60%.

Step 4: Write the system prompt like a runbook

Your system prompt is not a personality description. It's an operational runbook. The best agent prompts I've written look like SOPs an ops manager would give a new hire.

Structure I use:

ROLE: What you are (one line)

OBJECTIVE: What success looks like (2-3 lines)

TOOLS AVAILABLE: When to use each one

PROCESS:
1. First, always do X
2. Then check Y
3. If Z, do A. Otherwise B.

CONSTRAINTS:
- Never do X without confirmation
- Always cite source when Y

OUTPUT FORMAT: Exact structure of final response

For our lead qualifier:

ROLE: You are a lead qualification agent for a B2B SaaS company.

OBJECTIVE: For each inbound email, determine if the sender is a qualified 
lead (defined below), enrich with CRM data, and draft an appropriate 
Slack message for the sales team.

QUALIFIED LEAD DEFINITION:
- Business email (no gmail/yahoo/hotmail)
- Company size 10-500 employees
- Message mentions a specific use case, not just "learning more"

PROCESS:
1. Extract sender email and message body
2. Call get_contact_by_email to check CRM
3. If existing contact: summarize deal history in draft
4. If new contact: assess against qualification criteria
5. Draft a Slack message with clear recommendation: QUALIFIED, 
   UNQUALIFIED, or NEEDS_HUMAN_REVIEW

CONSTRAINTS:
- Never send messages directly — always draft for review
- If any tool returns an error twice, stop and flag for human
- Never invent CRM data. If not found, say "no CRM record"

OUTPUT: End with a single-line summary: "Recommendation: [X]. Reason: [Y]."

The specificity is the point. "Be helpful and accurate" produces garbage. "If any tool returns an error twice, stop and flag for human" produces reliable behavior.

Step 5: Handle the failure modes before they happen

Agents fail in three ways in production. Plan for all three.

Failure 1: Infinite loops. The model calls the same tool repeatedly hoping for a different answer. Cap iterations at 10-15 and log every step. Add loop detection:

def detect_loop(messages, window=3):
    tool_calls = [
        block.name for m in messages[-window*2:]
        for block in m.get("content", [])
        if hasattr(block, "name")
    ]
    return len(tool_calls) >= window and len(set(tool_calls)) == 1

Failure 2: Hallucinated tool arguments. The model invents an email address or contact ID. Validate every tool input against a schema and return a structured error the agent can recover from — don't crash the loop.

Failure 3: Cost runaway. One misbehaving agent can burn through your API budget in a night. Set hard limits:

class BudgetGuard:
    def __init__(self, max_usd=5.00):
        self.max_usd = max_usd
        self.spent = 0.0
    
    def charge(self, input_tokens, output_tokens, model):
        rate = PRICING[model]  # you maintain this dict
        cost = (input_tokens * rate["in"] + output_tokens * rate["out"]) / 1_000_000
        self.spent += cost
        if self.spent > self.max_usd:
            raise BudgetExceeded(f"Agent hit ${self.max_usd} limit")

Wrap every client.messages.create call. This has saved me from a five-figure bill exactly once, which is enough.

Step 6: Deploy with observability, not vibes

"It works on my laptop" is not a deployment strategy. For agents specifically, you need three things:

Structured logs of every turn. Not "agent ran successfully" — the actual messages, tool calls, tool results, and token counts. When something goes wrong at 2am you need to replay the trace. I dump each run to a JSONL file plus a hosted trace tool (Langfuse and Braintrust both work fine, pick one).

A replay harness. Save the initial input plus every tool response, then replay against a new prompt or model. This is how you improve an agent without breaking what works. Without replay, every change is a coin flip.

A "shadow mode." Run the new version alongside the current one, compare outputs on real traffic, only cut over when you've reviewed 20-50 real cases. Skip this and you'll ship regressions you don't notice for weeks.

Deployment target matters less than people think. For SMB-scale agents (under 10k runs/day), a small container on Fly.io, Railway, or a $20 VPS is fine. Serverless (Lambda, Cloud Run) works but watch cold starts — an agent making 6 sequential LLM calls doesn't need another 2s of cold start.

Step 7: The honest cost breakdown

Here's what a production lead-qualification agent actually costs to build and run, based on projects I've shipped:

Runtime cost per lead qualified is roughly $0.05-0.15 either way — you're paying for the same LLM tokens. The difference is engineering hours upfront and maintenance ongoing. A from-scratch agent will need 2-4 hours of maintenance per month. A no-code one needs closer to 30 minutes.

When does from-scratch win? When you need custom tool integrations that no platform offers, when data can't leave your infrastructure, or when you're running enough volume that platform per-run fees exceed your engineering time.

How BizFlowAI approaches this

We build agents both ways depending on the client. For a solo founder who needs a lead qualifier by Friday, we deploy on BizFlowAI's platform — the CRM connectors, approval-queue Slack pattern, and budget guards are already there. Setup runs 3-5 hours instead of a week, and the client can tweak prompts themselves without redeploying.

For clients with custom internal tools or strict data requirements, we build from scratch using the pattern above and host it on their infrastructure. Same architecture, same guardrails, more engineering hours. The choice isn't ideological — it's about where the client's actual constraints are. Most SMBs don't have constraints that justify from-scratch, which is why we default to platform-first and only go custom when there's a real reason.

What to build first

Don't start with the lead qualifier. Start with something smaller: an agent that reads your inbox once an hour and drafts responses to a specific category (support, invoicing, scheduling). Two tools, one prompt, run it for a week, watch what breaks. That's the fastest way to develop the intuition for what agent-building is actually like — which is 80% tool design and prompt iteration, and 20% the parts everyone writes tutorials about.

The people who successfully ship agents in 2026 aren't the ones with the best framework. They're the ones who built five ugly agents, deleted four of them, and kept iterating on the one that solved a real problem.

Work with BizFlowAI

If you'd rather have this built for you, that's what we do: production AI automation for solo founders and small teams — agents, integrations, and document pipelines that actually ship.

Book a free discovery call — 30 minutes, we map the highest-ROI automation in your workflow. No pitch deck, just engineering.

More guides like this on the BizFlowAI blog.