AI Agent Examples, and What Each One Needs

AI agent examples, and the one-line test

These are seven AI agent examples that people run on their own servers today. For each one you get what starts it, what it reads, what it is allowed to touch, which model it calls, and how big a host it needs. The test for whether something is an agent fits in one line: if the model chooses the next step and then sees the result of that step, it is an agent.

If you wrote every step in advance, it is an automation. If it answers once and stops, it is a chatbot. The test matters because it decides the risk. An automation does only what you wrote. An agent does what the model decides, so its permissions are the real limit on what can go wrong.

This page does not sort agents into families. For that, read the types of AI agents, from simple reflex to learning. It is also not a ranking. If you want to choose a product, start with our comparison of the best self-hosted AI agents.

Every figure below comes from one of our own tested guides, and each section links to the guide it came from. Where no guide has measured something, the section says so instead of guessing.

The five questions each example answers

• Trigger: what starts a run. A person typing, a webhook, a schedule, or an event such as a new pull request.
• Reads: the text the model sees. This is also the attack surface, because any text the model reads can carry instructions.
• Tools and permissions: what the agent can change. This sets the worst case.
• Model: a hosted API (application programming interface) such as Claude, or a local model served by Ollama on the same box.
• Host: where the agent loop runs, and how much RAM (random access memory) that box needs.

One point saves a lot of confusion. The agent loop and the model are often on different machines. A hosted-API agent sends each step to the provider, so the VPS only runs the loop and the tools. A local-model agent runs both, and the model weights then decide the size of the server.

1. A coding agent on a VPS

A coding agent such as Claude Code, Codex or OpenHands reads a repository, edits files, runs the tests, and reads the output. Then it decides what to change next. It is the clearest agent on this list, because almost every step depends on the result of the step before.

• Trigger: a developer, usually in a terminal session over SSH (secure shell), or an event such as a new pull request.
• Reads: source files, test output, build logs, and files such as CLAUDE.md or AGENTS.md that load into its context on their own.
• Tools and permissions: a shell and the file system. Run it as a dedicated user with no sudo, and give it a token scoped to one repository.
• Model: a hosted API in nearly every real setup, since code work needs a strong model.
• Host: OpenHands asks for 4 GB of RAM at minimum. For Claude Code the toolchain sets the size, not the CLI (command-line interface). Repositories, node_modules and Docker images fill the disk faster than the agent fills memory.

The event-driven version of this agent is a self-hosted AI agent that reviews pull requests. It runs on a GitHub Actions self-hosted runner and starts on the opened, synchronize and reopened events. It reads only the unified diff, and never checks out the branch. Its GITHUB_TOKEN is limited to contents: read and pull-requests: write. That narrow scope is the design: the agent can comment on code, but it cannot push code.

[
  {
    "label": "Claude Haiku 4.5",
    "input_tokens": "8,000",
    "cents_per_pr": 1.4,
    "usd_per_200_prs": "2.80"
  },
  {
    "label": "Claude Sonnet 5",
    "input_tokens": "10,400",
    "cents_per_pr": 3.64,
    "usd_per_200_prs": "7.28"
  },
  {
    "label": "Claude Opus 5",
    "input_tokens": "10,400",
    "cents_per_pr": 9.1,
    "usd_per_200_prs": "18.20"
  }
]

In that guide, Haiku 4.5 read 8,000 input tokens and reviewed the diff for 1.4 cents. That is $2.80 for 200 pull requests (PRs). Opus 5 cost 9.1 cents for the same diff. Haiku is the default there, and the REVIEW_MODEL variable switches it. If you run several coding agents on several machines, a self-hosted console that tracks coding agent token spend shows which run cost ten times the usual. Its reporters send token counts and the model id, but never prompts, file contents or credentials.

2. A support-ticket triage agent

A triage agent reads each new ticket and decides where it goes. This one runs fully on the VPS with a local model, so ticket text never leaves your server.

• Trigger: a new ticket sent as a POST request to a small receiver listening on 127.0.0.1:8099.
• Reads: the subject, the sender address, the customer's plan and the message body.
• Tools and permissions: nothing outside the box. The model answers fixed questions: pick one queue from a list of named options, place the ticket on an ordered scale such as urgency, or give the probability that a condition is true.
• Model: a local model served through Ollama.
• Host: the model weights set the size. The guide's default model is about 4.5 GB and needs an 8 GB plan. A 0.81 GB model fits in 2 GB, and a 9.5 GB model needs 16 GB.

Be honest about the one-line test here. Triage that only writes a label is a classifier. It becomes an agent when the label chooses the next step, for example to route the ticket or to draft a reply for a human to check. Keep that action step narrow.

The guide gives no accuracy figure, and you should not trust one from anyone else. Run a few hundred tickets you have already resolved through the endpoint, and count how often the agent agrees with what your team did. Two failures show up early. A 500 error on a small plan usually means the model could not load because memory ran out. A 413 means the request body was over the 64 KiB limit. The full setup is in triaging support tickets with a local model on a VPS.

3. An n8n workflow agent

In n8n, the AI Agent node wraps a model in a loop. You attach tools to it as sub-nodes. The rest of the workflow stays fixed, so you can put one agent step inside an otherwise ordinary automation.

• Trigger: a Chat Trigger for a conversation, a Webhook for events, or a Schedule Trigger for unattended runs.
• Reads: the chat message or webhook payload, plus whatever its tools return.
• Tools and permissions: for example an HTTP Request node used as a tool. The $fromAI() expression lets the model fill in the request parameters. Each tool uses credentials stored in n8n, so the agent can do anything those credentials allow.
• Model: the Anthropic Chat Model sub-node. A one-tool agent runs fine on Haiku. An agent that juggles several tools needs Sonnet.
• Host: n8n needs at least 1 GB of RAM, and you should plan for 2 GB once workflows do real work. The model runs at the API provider.

The guide to building an n8n AI agent with Claude and tools covers the failures you will meet. The Max Iterations setting defaults to 10. Lower it to 3 or 4, so a confused run stops early instead of calling tools in circles. If the model never calls the tool, the tool description is usually unclear, because the description is the only thing the model knows about the tool. If memory disappears in production, check for Simple Memory in queue mode, since that memory does not survive across workers. To get n8n itself running, follow self-hosting n8n on a VPS with Docker and HTTPS.

4. A research and browsing agent

A research agent searches, picks pages, reads them, and writes an answer with sources. The model decides what to search next from what it found, which is why it passes the one-line test.

• Trigger: a person asking a question, or another agent calling a research skill.
• Reads: search result snippets and the full text of pages that nobody has checked.
• Tools and permissions: a search command and a page-fetch command. A self-hosted SearXNG instance returns results as JSON on localhost:8080, and a headless browser pulls the readable text out of each chosen page. No credentials are needed, and it should stay that way.
• Model: usually a hosted API, since it must judge which sources to trust.
• Host: SearXNG and the headless browser run on the same VPS. The headless browser is the heavy part.

[
  {
    "label": "Self-hosted SearXNG",
    "usd_per_1000_queries": 0
  },
  {
    "label": "Brave Search API",
    "usd_per_1000_queries": 5
  },
  {
    "label": "Tavily",
    "usd_per_1000_queries": 8
  }
]

As of August 2026, a hosted search API cost $5 to $8 per 1,000 queries. SearXNG cost $0 beyond the VPS. The catch is rate limits. An agent fires searches in a burst, and search engines answer a burst from one IP address with a CAPTCHA. SearXNG then suspends that engine for 86,400 seconds, which is a full day. Leave a few seconds between batches of searches. The skill files and the pacing are in a browser and search skill for agents, backed by SearXNG.

5. An ops agent that watches logs

An ops agent reads recent errors on a schedule, groups them, and tells you what changed. We have no tested guide for this exact agent yet, so this section gives the safe shape and no figures.

• Trigger: a systemd timer every few minutes, or an alert from your monitoring.
• Reads: recent error-level journal entries and web server error logs.
• Tools and permissions: read-only. Any action that changes the system, such as restarting a service, goes behind a human approval.
• Model: a hosted API, or a small local model, since summarising log lines is a light task.
• Host: the box it watches, or a separate small VPS that reads logs over SSH. If you expose log reads as an MCP (Model Context Protocol) server, our MCP guide found 0.5 GB of RAM is plenty for the server itself.

Give the agent its own user, and let it read the journal through group membership instead of sudo:

sudo useradd --system --create-home --shell /usr/sbin/nologin logagent
sudo usermod -aG systemd-journal logagent
sudo -u logagent journalctl -p err --since "1 hour ago" --no-pager

The last command should print the error-level entries from the past hour, or -- No entries -- on a quiet box. If it starts with Hint: You are currently not seeing messages from other users and the system., the group change did not apply, so the agent would only ever see its own messages.

This agent has a quiet injection risk. Logs contain text that strangers wrote. When someone tries a user name that does not exist, sshd records whatever name the client sent, as a line like Invalid user admin from 203.0.113.5 port 52314. Web server logs record the User-Agent header the client chose. So a log-reading agent reads attacker text on every run. Read-only tools are what make that safe. To serve tools over MCP without opening a hole, follow running MCP servers on a VPS behind authentication. Its first rule is never to expose an unauthenticated MCP endpoint.

6. A personal assistant agent: Hermes or OpenClaw

A personal assistant agent lives in your chat app. You send it a message, and it plans and runs the steps. Hermes Agent comes from Nous Research and was released in February 2026. OpenClaw is MIT-licensed and passed 380,000 GitHub stars by mid-2026.

• Trigger: a message in Telegram or Discord for Hermes. OpenClaw adds WhatsApp and Slack through its channel connectors.
• Reads: your messages, its own persistent memory, and whatever its tools fetch.
• Tools and permissions: OpenClaw can run shell commands, control a browser, and read and write files. Hermes writes its own reusable skills as it works, and its settings decide how much it does without asking first.
• Model: both are model-agnostic. Hermes connects to whichever language model you choose, and OpenClaw works with hosted APIs or with Ollama.
• Host: our Hermes guide found a $5-a-month VPS, at 2026 prices, enough for a personal, always-on agent. OpenClaw fits a small VPS, and needs more once it drives a browser.

This is the example with the widest reach, because one process takes orders from a chat app and holds a shell. In March 2026, nine security issues in OpenClaw were disclosed within four days. One was a privilege-escalation flaw, CVE-2026-32922, rated 9.9 out of 10. The OpenClaw gateway listens on 127.0.0.1 by default, so it is not reachable from the internet unless you expose it. Keep it that way. Run either agent as a dedicated user with no sudo, and put dangerous tools behind an approval step. The setups are in self-hosting Hermes Agent on a VPS and building your own OpenClaw agent.

7. A scheduled report agent

A report agent wakes up on a schedule, collects data, and sends you a summary. It is the most common first agent, and it is often not an agent at all. If it always runs the same fetch, summarise and send steps, it is an automation with one model step. It becomes an agent when the model decides which sources to check, or whether a finding needs a closer look before the report goes out.

• Trigger: a Schedule Trigger in n8n, or a scheduled job in an agent workspace such as KiroCrew.
• Reads: whatever it reports on. For an inbox digest, that is new mail from the Gmail Trigger, which polls Gmail on the schedule you set.
• Tools and permissions: the Gmail credential in our guide requests the https://mail.google.com/ and gmail.modify scopes, which allow sending and deleting mail. Give the agent node only a read tool, and let a fixed node after it send the report.
• Model: a small hosted model such as Haiku. Summaries do not need more.
• Host: the same n8n box as example 3.

The failure that stops these reports is quiet. Google expires a test user's authorization seven days after consent. The refresh then fails with invalid_grant, and the report simply stops arriving. Connecting Gmail to self-hosted n8n shows how to avoid that. Scheduled runs also spend money while you sleep. In a self-hosted KiroCrew workspace, scheduled inference bills to your Kiro plan whether or not anyone reads the result.

How much server does each AI agent example need?

[
  {
    "label": "MCP tool server",
    "ram_gb": 0.5
  },
  {
    "label": "n8n workflow agent",
    "ram_gb": 2
  },
  {
    "label": "Triage, 0.81 GB local model",
    "ram_gb": 2
  },
  {
    "label": "Coding agent (OpenHands)",
    "ram_gb": 4
  },
  {
    "label": "open-kritt scanner, 2 workers",
    "ram_gb": 5
  },
  {
    "label": "Triage, 4.5 GB local model",
    "ram_gb": 8
  },
  {
    "label": "Triage, 9.5 GB local model",
    "ram_gb": 16
  }
]

The pattern is plain. An agent that calls a hosted API is small, because the VPS runs only the loop and the tools. The n8n agent fits in 2 GB. An agent with a local model is as large as its weights plus overhead, which is why triage with the 9.5 GB model needs 16 GB. Code agents sit in between, because they run real builds. The open-kritt security scanner needs about 5 GB for two workers, and 40 GB of disk.

Where AI agents go wrong

Every example above has the same two weak points. Both come from one fact: the agent does what the model decides, and the model can be wrong or misled.

Over-broad permissions

The worst case of an agent equals its permissions. A coding agent with your personal GitHub token can push to every repository you own. A personal assistant running as root can do anything root can do. The open-kritt vulnerability scanner is an honest example. It runs each target's build as root with network access, and it mounts the host Docker socket, which is the same as root on the host. Its guide says this openly and keeps it on a disposable machine.

The fixes are the same for every example. Run each agent as its own user with no sudo. Scope each token to the one repository, inbox or bucket the agent needs. Keep production credentials off the box. Put irreversible actions behind an approval.

Prompt injection

A model reads the user's request, the files, the web pages and the tool output as one stream of tokens. No token carries a mark that says "this is data, not an instruction." So anyone who controls text the agent reads can try to give it orders. That text can be a README, an issue comment, a web page or a log line.

The damage needs three things together: the agent holds private data, it reads untrusted content, and it can send data out. Remove one and an injection has much less to steal. The research agent should hold no secrets. The log agent should have no outbound tools. The coding agent usually has all three. That is why prompt injection against coding agents ranks disposable machines, short-lived scoped credentials, a clean environment with no secrets, and egress rules above approval prompts. Those controls still work when the model has been fooled. A tired human clicking "approve" does not.

Poisoned memory and runaway loops

Agents with persistent memory, such as Hermes and KiroCrew, add one more risk. An injected instruction saved to memory comes back in every later session, long after the page that carried it is gone. How agent memory gets poisoned covers how to find and remove it. Loops cost money too. Cap the iterations, cap the output tokens per call, and watch for the PR review agent's JSONDecodeError, which means a response hit the token ceiling halfway through a JSON object.

Which example to start with

Pick the example closest to a job you already do by hand, and start it with read-only tools. A scheduled report or a log summary is a safe first agent, because the worst it can do is send you a wrong summary. Add write access one tool at a time, once you have read enough of its runs to trust its choices. If you want to see the loop itself before you adopt a framework, building your own AI agent on a VPS writes it from scratch.

FAQ

What is a simple example of an AI agent?

A research agent is a clear example. It searches the web, reads the pages it picks, and decides from what it found whether to search again or write the answer. That loop, where the model chooses the next step and sees its result, is what makes it an agent. A script that always runs the same fixed steps with a model in the middle is an automation.

What is the difference between an AI agent and an n8n automation?

An n8n workflow runs the steps you drew, in the order you drew them. The n8n AI Agent node adds a loop inside one step: the model chooses which attached tool to call, reads the result, and decides whether to call another. So one n8n workflow can be mostly automation with a single agent step in the middle.

How much RAM does a self-hosted AI agent need?

It depends on where the model runs. An agent that calls a hosted API needs little, because the VPS only runs the loop and the tools: our n8n guide plans for 2 GB, and an MCP tool server runs in 0.5 GB. An agent with a local model needs room for the weights. A 4.5 GB model needs an 8 GB plan.

Can an AI agent use a local model instead of an API?

Yes. OpenClaw and n8n can both point at a model served by Ollama, and our support-ticket triage agent runs only on a local model. Local models keep data on your server and cost a flat monthly price. The trade is quality: complex multi-tool work, such as a coding agent, still works best on a strong hosted model.

What is the biggest risk of running an AI agent on a VPS?

Permissions that are wider than the job. An agent will at some point read text written by an attacker, in a web page, an issue or a log line, and that text can steer it. What the attacker gets then depends on what the agent can reach. Run it as its own user with no sudo and scope its tokens to one resource. Keep production secrets off the machine.