Flagship · AI/ML · In progress
Headless Intent-to-Execution Bridge
A zero-trust middleware (Zero-API Action Agent) that turns natural-language requests into deterministic, cryptographically signed actions against legacy and on-premise systems — an LLM only reasons and proposes, a no-LLM policy layer validates, a human approves anything high-risk, and a DMZ-isolated executor is the only thing that ever touches the target system.
- Timeline
- 2026-08 – Present
- Status
- In progress
Stack
Built with
The problem
Enterprises want AI automation but most internal tools — ERPs, on-prem databases, legacy mainframes, custom internal software — were never built with modern, accessible APIs, so every integration has historically meant a bespoke connector that costs millions and takes years to build. Skipping straight to giving an AI agent direct write-access to a production system is worse: an LLM can hallucinate a destructive command, and there's nothing deterministic standing between that hallucination and the database.
Constraints
- The LLM is never the thing that touches the target system — it only parses intent (target system, action, data payload) and proposes; validation against security policy runs as plain Python, not another model call, so the trust boundary has no LLM on the execution side of it
- High-risk actions cannot proceed unattended: LangGraph pauses the state machine and the frontend renders a temporary Approve/Reject card for a human, rather than queuing the action to fire automatically
- Every payload has to be HMAC-signed before it leaves the reasoning layer and re-verified by the executor before anything runs, so a spoofed or tampered request between LangGraph and the execution layer is rejected outright
- Execution against legacy/on-prem systems has to happen without any modern API surface — parameterized queries and secure connectors, reached only through a WireGuard/Cloudflare tunnel into a DMZ-isolated n8n instance, since the target systems were never designed to be called from outside their network
Architecture
How it's built
The pipeline runs in three stages. A React/Lovable frontend takes a natural-language command (e.g. 'update the shipping address for customer X in our legacy SAP system and credit their account $50') and, when the request is flagged high-risk, dynamically renders a temporary Approve/Reject card for a manager instead of executing anything itself. That request enters a LangGraph state machine — the reasoning and guardrail layer. An LLM node parses the command into a target system, an action, and a data payload; a separate no-LLM Validate node runs that payload through hardcoded Python policy checks (permissions, whether the operation is safe); if the computed risk score is high, LangGraph pauses the whole run and waits on the human approval step from the frontend; once approved (or if risk was already low), a Sign node HMAC-signs the payload so it can't be altered in transit. The signed payload then reaches the headless execution layer: a self-hosted n8n instance sitting in a DMZ, reachable only over WireGuard/Cloudflare tunnels. n8n re-verifies the HMAC signature to confirm the request actually came from LangGraph, then executes it against the legacy or on-prem system using secure connectors and parameterized queries to rule out injection, before reporting a success/failure log back to LangGraph to close the loop.
Decisions
Alternatives considered
Give the AI agent direct write-access to the production database/ERP
An LLM can hallucinate a destructive command with nothing deterministic in the path to stop it — the entire point of the bridge is to keep the model strictly on the reasoning side of an airlock it can never cross by itself.
Build custom, hardcoded API integrations for every internal legacy tool
Wrapping or migrating old ERPs, mainframes, and custom internal software with modern APIs is the standard path, but it costs millions and takes years per system — the bridge exists specifically to make that unnecessary by executing through a generic, policy-gated connector layer instead.
Decisions
Tradeoffs
- Chose a deterministic, no-LLM validation step (hand-written Python policy checks) over asking a second model to police the first — new policies have to be coded by hand rather than described in a prompt, but it removes the LLM entirely from the trust boundary around execution.
- Chose to pause and wait on a human-approval card for high-risk actions instead of a fully autonomous pipeline — adds latency and requires a manager to be available, but a hallucinated or incorrectly-parsed high-risk action never reaches execution unseen.