Agentic AI hub on n8n
One tool hub for my AI clients. Rules-first routing, per-client MCP tools, and a work queue that agents claim under their own identities.
running Running. Agents tested on test tickets; no real work in daily use yet.
- AI did
- Code, tests, reviews
- I did
- Routing rules, approval model, veto, live approvals
Works
- Queue engine: 5 of 5 live tests passed before go-live; the token tests passed separately.
- Error handler set on 20 of the 23 active hub and agent workflows.
- Race test: 12 rounds of 24 parallel claims, exactly one winner every round.
- A wrong token, or another agent's, gets HTTP 403.
- Guarded node reboot: 366 of 366 tests.
- Sandboxed node agents: 45 of 45 allowlist cases.
Designed only
- The approval step itself is not built; urgent or live items are routed to me.
- A race between the agents themselves has no recorded result yet.
- Agents do no real work in daily use yet.
Failed or missed
- Router evaluation: the whole pipeline scored 30 to 34 of 50, and only 6 of 8 requests that needed a person reached the human tier.
- A default match setting let one agent overwrite another's held row; caught by the race test before go-live and fixed.
1Problem
Several AI clients were each set up on their own, with no shared model routing, audit trail or approval gates. I wanted one tool hub that routes each request to the lightest capable model, and agents that work a queue under their own identities. The first version was an inherited scaffold that mostly did no real work, so I rebuilt it in Oct 2026.
2What I built
- A router with 7 tiers: fast local model, thinking local model, big-memory node, laptop agent, frontier model, a design tier, and a "human" tier for anything that needs a person. Rules decide first. A small local classifier labels only the unsure middle.
- 12 MCP endpoints across 6 tool groups. Each client has its own bearer token.
- A ticket and work queue with claim and lease, wired to 3 agent runtimes (OpenClaw, one per machine). The two on the AI nodes run sandboxed.
- Built as code: 36 workflow generators, 10 deploy scripts with rollback snapshots and 13 offline test files. Every workflow is exported to git daily.
- Size, Oct 2026: 67 n8n workflows, 49 of them active, about 1,100 nodes across the active ones. That count includes home automations; only the hub, operations and agent workflows are described here. 20 of the 23 active hub and agent workflows carry an error handler.
- Gaming-aware routing: when a game starts on the desktop, its local models unload and AI work moves to the 128 GB node. Drills and smoke tests for that hand-over passed.
3How AI was used
Claude Code built it. Researcher and skeptic pairs worked the design decisions, auditors went through the inherited scaffold, and adversarial reviewers checked live changes before they went out. Routing is local-first: local models on Ollama are the default tiers, and hard tasks go to the frontier tier.
Agents researched and proposed the platform decisions under my veto. I set the routing rules and the approval model, and I approved every live deploy.
4Results
A race test on the queue's claim step ran 12 rounds of 24 parallel claims, 288 calls in all. Exactly one agent won every round.
The router evaluation was humbling. I ran 50 sample requests; the labels are still provisional. The deployed 4B classifier alone scored 60%. Two other candidates scored 62% and 86%. The rules in front of the classifier decide 45 of 50 requests and get only 29 right. So the whole pipeline scored 30 to 34 of 50, depending on the classifier, and only 6 of 8 requests that needed a person reached the human tier. The rules are the real fix. The human tier is not yet a safety net on its own.
5Securing the agents
| Control | How it works | State |
|---|---|---|
| Per-client bearer tokens | A wrong token, or another agent's, gets HTTP 403 | Tested live |
| Sensitive-term guard | A keyword guard kept a planted test phrase out of the ticket store | Tested live |
| Read/write split | Operations tools are read-only. Tickets are written only through a separate tickets facade. Other tool groups allow only narrow writes, such as claim and lease, or a guarded reboot | In place |
| Guarded node reboot | Refuses mid-setup, mid-update or in hibernation; checks it has the right machine; waits for a new boot. 366 of 366 tests after 16 review fixes | Tested live |
| Untrusted-output labels | Web, agent and log text is passed on as data, not instructions | In place |
| Approvals agents can't grant | Urgent or live items go to me, and agents cannot act on them. The approval step itself is not built yet | Routing in place |
| Sandboxed node agents | Unprivileged user, network limited to the node and the hub, command allowlist (45 of 45 cases). 11 review findings fixed before deploy | On the AI nodes |
| Hardening backlog | Remaining lab hardening items, tracked one by one | Open |
6Status and limits
Deployed and running. The queue engine passed 5 of 5 live tests before go-live (empty values, a 3-agent race, writes and hand-offs, lease expiry, a ticket smoke test); the token tests passed separately. Each of the three agents then claimed and worked a test ticket. A race between the agents themselves has no recorded result yet. The agents do no real work in daily use yet, and they never change a live system for a ticket.
7What I learned
Messages between agents need the same suspicion as web content. A second vendor's agents relayed instructions to each other as "Agent X here. Jesse asked that ...". That is authority spoofing. My answer: per-agent identities, untrusted-output labels, and approvals that agents can't grant themselves.