How to Build an AI Agent From Scratch in 2026 (No-Code & Code Paths)

What Makes Something an AI Agent (Not Just a Chatbot)?

A chatbot waits for a message, replies once, and forgets the context. An AI agent does three things a chatbot does not: it maintains persistent memory across sessions, it can call external tools (APIs, databases, web scraping, code execution), and it can act autonomously on a schedule without waiting for a human prompt.

The practical difference: a chatbot tells you what the weather is when you ask. An agent monitors the forecast every morning, cross-references your calendar, and sends you a Telegram message when a rainstorm is going to clash with your outdoor meeting — without you asking.

Core Concepts Before You Build

The Agent Loop

Every agent runs a loop. The steps are always some variation of:

1. A trigger fires (inbound message, cron tick, webhook, user input)
2. The agent builds a context window: system prompt + recent memory + trigger payload
3. The LLM generates a response or a tool call
4. If a tool call is present, the agent executes it and captures the result
5. The result is added to context and the LLM runs again
6. When the LLM produces a final text response (no more tool calls), the agent sends it and stores the exchange in memory

Understanding this loop is the most important thing you can learn about agents. When your agent stalls, burns tokens, or ignores a tool result — the bug is always somewhere in this loop.

Tools (Function Calling)

Tools are functions the LLM can choose to call. You define the function signature (name, description, parameters) and pass it to the model alongside the prompt. The model returns a structured JSON object describing which tool to call and with what arguments. Your code executes the function and feeds the result back into the context.

Common tools: web search, reading/writing files, database queries, HTTP requests to external APIs, sending messages to Telegram or Slack, running shell commands (carefully), and reading calendar or email data.

Memory

LLMs are stateless. Memory is the layer that gives your agent continuity. Short-term memory is the in-session conversation history (the messages array you pass to the model). Long-term memory is stored externally — a SQLite file, a vector database, a Markdown knowledge file — and retrieved at the start of each session.

For most practical agents, a simple approach works well: append a session summary to a Markdown file at the end of each conversation, and prepend the last N summaries to the next session's context. More sophisticated setups use vector embeddings for semantic retrieval, but start simple.

Triggers and Heartbeat

An agent that only responds to messages is half an agent. A heartbeat is a cron-style schedule that wakes the agent at a defined interval — every hour, every morning, every week — so it can do proactive work: pull metrics, scan for anomalies, draft a report, post an update.

Most agent runtimes (OpenClaw, Nanobot, custom Node/Python scripts) implement heartbeat as a cron expression in the agent configuration. The runtime invokes the agent loop with a special trigger payload instead of a user message.

Path 1: Build From Scratch (The Code Path)

This path gives you full control. You understand every layer, can customise anything, and are not locked into any platform. The tradeoff is time: expect 2–4 hours for your first working agent if you are comfortable in a terminal.

Step 1 — Choose Your Model

Your model choice affects cost, latency, tool-call reliability, and whether you need an internet connection. Two practical options:

For a first agent: start with Claude 3.5 Haiku (fast, cheap, excellent tool calling) or Qwen 2.5 7B via Ollama if you want zero API cost. Avoid starting with a large local model on modest hardware — 70B parameter models will be too slow for interactive testing.

Step 2 — Write Your SOUL.md (System Prompt + Config)

The SOUL.md is the agent's configuration file. It contains the system prompt, role definition, tool declarations, memory configuration, and heartbeat schedule. Here is a minimal example for a content scout agent that monitors Reddit daily and sends a Telegram summary:

# SOUL.md — Content Scout Agent

## Identity
name: ContentScout
role: Content Scout
description: >
  Monitors Reddit for high-signal posts in target communities,
  summarises the top 5 discussions, and delivers a daily digest
  to the team Telegram channel.

## Personality
tone: concise, analytical, no fluff
response_style: bullet points with source links
language: English

## Tools
- name: reddit_search
  description: Search Reddit for recent posts in a subreddit
  parameters:
    subreddit: string
    query: string
    time_filter: "day" | "week"
    limit: number

- name: send_telegram
  description: Send a message to the configured Telegram chat
  parameters:
    message: string

## Memory
type: file
path: ./memory/scout-sessions.md
retain_last_n_sessions: 7

## Heartbeat
schedule: "0 8 * * *"   # 08:00 UTC daily
trigger_message: >
  Run your daily Reddit scan. Check [TARGET_SUBREDDITS].
  Find the top 5 most relevant discussions from the last 24h.
  Send a digest to Telegram. Be concise.

## Model
provider: anthropic
model: claude-3-5-haiku-20241022
max_tokens: 2048

A few things to notice: the tools section is a declaration, not an implementation. You still need to write the actual functions in your runtime code. The SOUL.md tells the LLM what tools exist and how to call them; your code is what actually executes the Reddit API request or sends the Telegram message.

Step 3 — Implement the Tools

Tools are just async functions. For a Node.js agent using the Anthropic SDK, each tool is a plain function your runtime calls when the model requests it. Keep them small and focused — one tool per side effect. A reddit_search tool should only search and return raw results; do not add summarisation logic inside the tool itself. Let the model do the reasoning on the returned data.

Practical tool hygiene: always return structured JSON from your tool, include an error field on failure instead of throwing (the model can handle a JSON error message and adapt; an uncaught exception breaks the loop), and cap results to a reasonable size so you do not blow out the context window.

Step 4 — Build the Agent Loop

Your runtime needs a loop that: loads the SOUL.md config, prepends long-term memory to the context, calls the model, checks the response for tool calls, executes them, appends results, and calls the model again until it returns a final text response. Then save the session to memory and optionally send the response to a channel.

If you are using OpenClaw, this loop is already built — you only need to write the SOUL.md and implement any custom tools not already in the standard library. If you are building from scratch with the Anthropic SDK or OpenAI SDK, plan for about 80–120 lines of orchestration code for a minimal loop with tool calling and basic file memory.

Step 5 — Add the Heartbeat

On a Linux/macOS server, the simplest heartbeat is a cron job that calls your agent script on the schedule defined in SOUL.md. If you are running OpenClaw, heartbeat is handled by the gateway daemon — it reads the schedule field and invokes the agent loop automatically.

For a custom implementation, parse the cron expression from SOUL.md and use a library like node-cron (Node) or APScheduler (Python) to schedule the loop invocation. The heartbeat trigger message replaces the user input for that run.

Step 6 — Deploy

The standard deployment target for self-hosted agents is Docker on a VPS. A minimal Docker setup for a Node.js agent looks like:

# docker-compose.yml
services:
  agent:
    build: .
    restart: unless-stopped
    env_file: .env
    volumes:
      - ./memory:/app/memory
      - ./SOUL.md:/app/SOUL.md:ro

Mount the memory directory as a volume so session data persists across container restarts. Mount the SOUL.md as read-only. Store API keys in the .env file, not baked into the image. A $4–6/month VPS with 1 vCPU and 1GB RAM is sufficient for a single agent using a cloud model. If you are running a local model, you need a machine with enough VRAM (8GB for a 7B model, 16GB for a 13B model).

Path 2: Build Without Code Using CrewClaw

If you want a working agent without setting up a runtime, writing a SOUL.md from scratch, or configuring Docker by hand, CrewClaw covers those steps through a browser-based builder. The tradeoff is less low-level control in exchange for significantly less setup time.

CrewClaw is built on OpenClaw under the hood. The agents it produces are standard SOUL.md-based OpenClaw agents — so if you later want to take the exported package and customise it by hand, you can.

How the CrewClaw Builder Works

1. Pick a role template. CrewClaw ships with 17 pre-built templates: PM agent, SEO analyst, content writer, support bot, revenue tracker, Reddit monitor, competitor watcher, and more. Each one comes with a sensible SOUL.md default, pre-wired tools, and an example heartbeat schedule.
2. Customise the role. Edit the agent's name, description, tone, and focus area directly in the browser. Adjust the system prompt to match your specific use case. The playground shows a live preview of how the agent responds as you edit.
3. Select integrations and model. Choose which tools to enable (Telegram, Stripe, GitHub, Notion, PostgreSQL, Reddit, and more), pick your AI model (Claude, GPT-4o, Gemini, or a local model via Ollama), and set the heartbeat schedule if you want proactive triggers.
4. Test in the playground. Chat with the agent live in the browser before committing to a deployment. Verify it responds the way you want, handles edge cases, and uses the right tone.
5. Export or go hosted. Two options at this point: export a complete Docker deploy package (SOUL.md, docker-compose.yml, .env template, integration configs, and a setup script) and run it on your own server — this is the self-host tier at $9 one-time. Or choose the hosted tier at $29/month, where CrewClaw runs the agent 24/7 on its own infrastructure.

What the Export Package Contains

The self-host export is a zip file with everything needed to deploy the agent on a fresh VPS:

• —SOUL.md — the agent's full configuration, ready to read and edit
• —docker-compose.yml — the full container stack, including Ollama if you chose a local model
• —.env.example — all required environment variable keys with instructions
• —Integration configuration files for every enabled service
• —setup.sh — a setup script that installs Docker if needed and starts the stack

You copy the zip to your server, fill in the .env file with your API keys and Telegram bot token, and run docker compose up -d. The agent starts, registers the heartbeat schedule, and begins running.

Code Path vs No-Code Path: Which Should You Choose?

Choose the code path if you need a custom tool that does not exist in any library, want to deeply understand agent architecture, or are building something that will be maintained by an engineering team. Choose the no-code path if you have a clear use case that fits one of the templates, want to get to a deployed agent quickly, and prefer not to manage a runtime yourself.

Common Mistakes When Building Your First Agent

• 1.
  Writing a system prompt that is too long. A 2,000-token system prompt is not twice as good as a 1,000-token one. Long, vague instructions confuse the model. Write specific, short instructions. If you have more than 5 bullet points for "how the agent should behave," cut three of them.
• 2.
  Giving the agent too many tools at once. Start with 1–3 tools. Every tool you add is another decision the model has to make. A small, focused tool set produces more reliable behaviour than a large one.
• 3.
  Not testing the heartbeat trigger manually first. Before trusting a cron schedule, manually invoke the heartbeat trigger message against your agent and watch the output. Cron silently succeeds even when the agent errors.
• 4.
  Storing API keys in the container image. Use environment variables, always. A Docker image with a baked-in API key will eventually end up in a registry or a shared server and the key will be compromised.
• 5.
  Ignoring the context window limit. If your memory system appends every session in full, you will eventually exceed the model's context limit and the agent will silently fail or start hallucinating. Always summarise old sessions rather than appending raw transcripts.

FAQ