Community Preface
I’m sharing this as an early architecture pattern, not a finished platform.
The core idea is simple: local LLMs should interpret intent, but deterministic workflow systems like n8n should enforce schemas, routing, approvals, and execution boundaries before anything touches the OS.
I’d especially appreciate feedback on validation patterns, approval gates, and local‑first workflow safety.
This is meant to be collaborative — I’m interested in how others are approaching similar problems with self‑hosted n8n and local models.
ECHO: A Local‑First Pattern for Safe Intent Orchestration
Executive Summary
Modern local-first AI systems expose a structural gap between what users intend and what traditional operating systems are designed to execute.
LLMs can interpret goals, context, and multi-step workflows — but they remain non-deterministic and should not directly execute local system actions.
The ECHO architecture explores a safer pattern:
-
The LLM interprets intent
-
n8n enforces execution safety
The LLM never runs shell commands or touches the OS.
It only produces structured intent.
n8n validates schemas, routes by risk level, enforces approval gates, and logs outcomes.
ECHO is not a replacement OS — it’s a local-first intent orchestration pattern.
1. Introduction: Why This Pattern Exists
Users increasingly issue intent-level requests:
-
“Organize this project.”
-
“Prepare a summary for tomorrow.”
-
“Find the latest version of this file.”
-
“Create the folder structure and draft the next step.”
Operating systems execute instructions, not intent.
LLMs understand intent, but should not be trusted with direct execution.
This creates the need for a coordination layer:
Human intent → LLM interpretation → deterministic workflow execution → local system action
ECHO defines one possible pattern for that layer.
2. The Core Problem
Operating systems excel at:
-
process scheduling
-
memory management
-
permissions
-
file operations
-
device management
-
I/O handling
But they do not understand:
-
user goals
-
workflow context
-
semantic privacy boundaries
-
multi-agent coordination
-
risk levels
-
approval requirements
LLMs understand these things — but should not decide what touches the filesystem.
ECHO addresses this gap.
3. The Basic Architecture
ECHO separates reasoning from execution.
Code
Human Operator
↓
Intent Layer / Local LLM
↓
Structured JSON Proposal
↓
n8n Deterministic Execution Spine
↓
Validated Workflow
↓
Hardened Local Tool or Script
↓
Logged Result
The model proposes.
The workflow layer disposes.
4. Why n8n Fits the Deterministic Spine Role
n8n provides a visible, inspectable, deterministic workflow layer.
It enforces:
-
schema validation
-
allowed values
-
required fields
-
risk-tier routing
-
human approval gates
-
execution logging
-
workflow versioning
-
deterministic routing
The LLM only gets access to approved workflow entry points.
5. Example Payload
Code
{
"action": "create_project_workspace",
"mode": "dry_run",
"risk_tier": "low",
"target": "local_workflow_node",
"parameters": {
"project_name": "example_project",
"template": "standard"
}
}
n8n would:
-
validate the schema
-
confirm the action is allowlisted
-
check the risk tier
-
route to the correct workflow
-
execute in dry-run mode if required
-
log the outcome
The LLM never directly runs the script.
6. Risk-Tier Routing
Avoid both extremes:
-
AI executes everything
-
Human approval for everything
Instead, route by risk.
Low-Risk
Examples: create folders, notes, dry-runs, internal logs
Behavior: auto-execute
Ambiguous
Examples: unclear names, missing destinations
Behavior: ask for clarification
Medium-Risk
Examples: moving files, updating records
Behavior: preview or dry-run
High-Risk
Examples: sending emails, deleting files, external sharing
Behavior: require explicit approval
Forbidden
Examples: unsafe scripts, cross-boundary data movement
Behavior: refuse and log
7. Trust Boundaries / Trust Zones
OS permissions are structural.
Human privacy is semantic.
Trust zones determine:
-
indexing
-
workflow access
-
external sharing
-
approval requirements
-
refusal conditions
Semantic privacy boundaries must be enforced by deterministic workflow logic.
(Your table renders cleanly in Discord — keep it as-is.)
8. The Maturity Ladder
Capabilities should mature:
Script → Tool → Workflow → Command
-
Script: experimental, manual
-
Tool: hardened, validated
-
Workflow: deterministic, versioned
-
Command: safely exposed to the LLM
The LLM should only see commands, never raw scripts.
9. Why This Matters for Local-First AI
Local-first systems sit near:
-
personal files
-
business records
-
legal documents
-
private archives
-
production workflows
This proximity increases risk.
Deterministic mediation is essential.
10. Multi-Node and Agent Coordination
Future setups may include:
-
laptop
-
workstation
-
NAS
-
GPU node
-
model server
-
background agents
The system must know:
-
which node handles what
-
which tools exist
-
what data is allowed
-
whether a job is running
-
whether approval is required
n8n can coordinate this via schemas, webhooks, and permissions.
11. Limitations and Open Questions
Open areas include:
-
JSON validation
-
malformed output repair
-
workflow locking
-
multi-node state
-
stale index detection
-
trust-zone indexing
-
audit logging
-
approval fatigue
-
over-trust in confident AI
The goal is to define where these problems belong.
12. Questions for the n8n Community
Looking for feedback from people working with:
-
self-hosted n8n
-
local LLMs
-
Ollama
-
webhook control
-
schema validation
-
approval gates
-
multi-node workflows
Specific questions:
-
How do you sanitize malformed JSON from local models?
-
Any clean patterns for schema validation before execution?
-
Lightweight locking/mutex patterns for multi-node setups?
-
How do you avoid approval fatigue?
-
Any existing workflows that follow “LLM proposes / workflow disposes”?
13. Conclusion: The Substrate Before the System
Intent-oriented computing needs a layer between human goals and system execution.
LLMs interpret meaning.
OSes execute instructions.
Neither handles the middle layer.
ECHO proposes:
-
local-first
-
intent-driven
-
schema-validated
-
workflow-mediated
-
trust-boundary-aware
-
human-approved
-
deterministic execution
Let the LLM reason.
Let n8n enforce.
Let the human remain in authority.
Feedback and critique welcome — this is an evolving architecture.