n8n-claw: an autonomous agent assembled from n8n workflows, Postgres and Claude
OpenClaw-inspired autonomous AI agent built entirely in n8n. Adaptive RAG-powered memory, Skills via MCP templates, Expert Agents with delegated sub-agents, proactive task management, media understanding - self-hosted with one setup script
At a glance
- What is it?
- n8n-claw is a self-hosted AI agent that runs on n8n workflows with PostgreSQL and Claude, reached through Telegram or an HTTP webhook. It is a reasonable fit if you already run n8n and want memory, task tracking and MCP skills inside your own infrastructure, but the repository lists no license, so verify that before adopting anything.
- Who is it for?
- Adopt n8n-claw if you already operate n8n and PostgreSQL, you want the agent's memory, tasks and reminders inside your own infrastructure, and you are willing to read the workflow JSON when something breaks. Do not adopt it if you need a published open source licence, a single-process deployment, or a support contract.
- Can I use it commercially?
- Not without permission. GitHub finds no licence file in the repository, and without a licence all rights are reserved by default: you may read the code but not reuse it. Check the README, or ask the authors, before using it.
- Is it still maintained?
- Yes. The repository last received commits 5 days ago.
- What is it written in?
- Mainly Shell, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap n8n-claw fills between a chat model and a running system
A hosted assistant keeps your conversation and your task list on someone else's servers. n8n-claw takes the opposite position: the README describes a fully self-hosted AI agent built on n8n, PostgreSQL and Claude, reachable through Telegram or an HTTP API. The people it is aimed at are the ones who already run n8n for automation and want an agent that lives in the same place, with the same database and the same credentials.
The feature list is long, but the interesting part is what it chooses to keep locally. Long-term memory is stored in PostgreSQL with hybrid search that fuses semantic, full-text and entity matching through RRF, plus time decay and category-based auto-expiry. The README states that this design survives embedding API outages, which matters if you have ever watched a retrieval pipeline fail because one upstream provider had a bad hour. Person lookup works by name, not only by vector similarity.
It is not a general framework for building agents. It is a pre-built agent with a fixed set of capabilities (tasks, reminders, memory, knowledge graph, web search, web reader, browser automation, media handling) that you extend by adding MCP skills or expert agents. If your need is a custom agent loop with your own control flow, you are looking at the wrong project.
How the workflow graph is wired: one agent, many tools, two entry points
The architecture diagram in the README shows two inbound paths converging on the same agent. Telegram messages and POST requests to /webhook/agent both land in the n8n-claw Agent, which runs on Claude Sonnet. From there the agent has a fixed tool set: a task manager, a project manager for markdown notes, memory save/search/update/delete, a knowledge graph, an MCP client that calls tools on skill servers, a library manager for installing skills, an MCP builder for creating new ones, a reminder tool, an expert agent that delegates to sub-agents, a Telegram status tool for progress updates during long jobs, an HTTP tool, web search through a bundled SearXNG instance, a web reader built on Crawl4AI, and a self-modify tool that can inspect and list n8n workflows.
The response path branches on the caller. A webhook caller gets a JSON response; a Telegram caller gets a Telegram reply. That branch is the reason the same agent can serve a chat user and an external system without duplicating logic.
Background work runs as separate n8n workflows rather than as part of the request. The README lists a heartbeat every five minutes for recurring actions, proactive reminders and file cleanup, a background checker that stays silent unless it finds something new, a memory consolidation job at 3am that summarizes conversations into long-term memory, a reminder runner every minute, and an error notification workflow that catches failures, sends a Telegram alert and logs to memory_long. That last one is the source of the failure-awareness feature: instead of reading n8n execution logs, you ask the agent what failed and it answers from memory.
Installation: a setup script, a stack, and the URLs it exposes
The repository describes installation as a one setup script, and the README has dedicated sections for installation, services and URLs, HTTPS setup, updating and a Postgres 17 upgrade path for existing installations. The stack section names n8n, PostgreSQL and Claude as the core. The topics list adds Supabase, SearXNG and Crawl4AI, which matches the bundled search and reader services described in the architecture.
What the README does not give, at least in the portion available here, is the literal command line for the setup script or the full set of environment variables. If you are evaluating this for a team, that is the first thing to check in the repository itself: read the setup script before running it, because it is the component that decides which ports open and which credentials get generated.
Configuration surfaces that are documented by name include the webhook endpoint at POST /webhook/agent, the optional webhook adapter that maps Slack, Teams, generic and custom webhooks into that endpoint through a Set node, and the MCP Skills Library for installing skills from a catalog. Google services are wired through OAuth2. Alternative LLM providers are covered in a dedicated section, so Claude is the default rather than a hard requirement. There is also a documented path for switching the chat channel from Telegram to WhatsApp, and a separate note on connecting Claude Desktop, ChatGPT, Claude Code, Lovable and Cursor to the agent.
MCP skills and expert agents are two different extension mechanisms
It is worth separating these, because the README lists them close together and they solve different problems.
MCP skills are tools. The agent calls them through an MCP client, and the library manager installs or removes them from a catalog. The MCP builder creates new skills from scratch, which the README frames as building API integrations on demand. So a skill is a capability the agent invokes: upload a file somewhere, query an API, run a search.
Expert agents are delegates. The expert agent tool hands a task to a specialized sub-agent. Three are included, and the README points to an agent catalog repository with 100+ entries across 12 categories. The agent library installs and removes them, mirroring the skill library.
The distinction matters for cost and debugging. A skill is one tool call in the main conversation. An expert agent is a separate agent with its own context, which means more tokens and a harder trace when something goes wrong. If you are budgeting, treat expert agents as the expensive path and reserve them for tasks that genuinely need a separate context.
There is also an OpenClaw integration for delegating coding tasks to an autonomous agent that can build websites, apps and run shell commands. That is a much larger trust boundary than a search tool, and the README does not, in the material available, describe sandboxing for it.
Browser automation, pooled sessions and the 2FA handoff
Browser use arrived in v1.9.0, and the README describes it in more detail than most features. The agent drives a real Chromium instance to perform actions on websites: newsletter signups, contact forms, click flows, and content behind a login. Sessions are pooled per domain so the agent stays logged in across calls, and the README is explicit that this pool is in-memory and lost on restart. That is a real constraint. After a restart, any site requiring a login needs to be authenticated again, and the agent has no persistent credential store for browser sessions.
The interactive 2FA flow is the more unusual part. The agent stops at the 2FA prompt, asks the user for the code through Telegram, the user replies with the TOTP code, and the agent enters it on the same live page to finish the login. This is a sensible design for a single-user setup, because the human is already the authentication factor. It is a poor fit for a shared or unattended deployment, where nobody is watching Telegram when the prompt appears.
Read the browser section as a capability with a supervision requirement, not as a background service. The README does not claim otherwise.
Where n8n-claw is the wrong tool
The licence is the first problem. The repository metadata in this material lists the license as unknown. That is not a detail you can postpone. Without a license file, the default position under copyright is that you have no granted rights to use, modify or redistribute the code, regardless of what the README promises. If you are evaluating this for a company, get that resolved before you build on it. Nothing here is legal advice; ask whoever handles licensing at your organisation.
The second problem is the runtime. Everything is an n8n workflow. Debugging means reading workflow JSON and execution logs, and the agent's own error notification workflow exists precisely because that is painful. If your team does not already know n8n, you are adopting two systems at once.
The third is version coupling. Release v1.9.1 is titled as a bugfix for an agents table collision with n8n 2.21 and later. That tells you the project tracks n8n's schema closely and that an n8n upgrade can break the agent's storage. Plan upgrades together, not independently.
The fourth is the in-memory browser session pool, covered above, and the fifth is scope: this is a personal-assistant-shaped agent. If you need deterministic, auditable automation with no model in the loop, n8n alone already does that, and adding an LLM to the path makes the behaviour harder to reproduce.
What you would compare it against
The closest comparison is not another agent framework. It is n8n on its own. A plain n8n instance gives you triggers, HTTP nodes, database nodes and error workflows with no model deciding what happens next. It is deterministic, cheap to run and easy to audit. n8n-claw adds an LLM in the middle so that natural language becomes the interface and the agent chooses which tool to call. You gain flexibility in how you ask for things and lose the ability to predict exactly which node fires. If your workflows are already stable, the agent layer is overhead. If you keep writing new n8n workflows for one-off requests, the agent layer is the point.
The other comparison is a hosted assistant with tool use. Those give you a managed runtime and someone else's uptime, and they keep your memory and task data on their infrastructure. n8n-claw keeps the data in your PostgreSQL and the orchestration in your n8n. The trade is operational: you own the upgrades, the Postgres 17 migration path, the HTTPS setup and the failure modes. The README has sections for each of those, which is a sign the maintainer expects you to hit them.
Maintenance, releases and what to check before you commit
The release history in this material shows three versions between May and June 2026: v1.9.0 adding browser use and interactive 2FA, v1.9.1 fixing the agents table collision with n8n 2.21 and later, and v1.9.2 fixing a 413 error in config backup and adding claw_agents to backups. The last push to the repository is dated 2026-09-08, and the repository is not archived. Two of the three recent releases are fixes rather than features, and one of them is about backups, which suggests the maintainer is reacting to real deployment problems rather than polishing a demo.
That also tells you what to expect from upgrades. Backups matter because the config includes agent definitions and the fix in v1.9.2 added claw_agents to the backup set, meaning earlier backups would have missed them. If you installed before v1.9.2, check what your backup actually contains. The README has an updating section and a separate Postgres 17 upgrade section for existing installations, so the upgrade path is documented, but the coupling to n8n versions means you should read the release notes before bumping n8n.
On licensing: the material gives no license identifier. Until that is resolved, treat n8n-claw as source you can read rather than source you can rely on. That single unknown outweighs every feature in the README.
Editorial conclusion
Adopt n8n-claw if you already operate n8n and PostgreSQL, you want the agent's memory, tasks and reminders inside your own infrastructure, and you are willing to read the workflow JSON when something breaks. Do not adopt it if you need a published open source licence, a single-process deployment, or a support contract. Verify the license field before you clone, check that your n8n version is compatible with the agents table after the v1.9.1 collision fix, and confirm that the setup script's assumptions about Docker and Postgres match your host.
Community notes