Building AI Agents That Ship: OKF, n8n, and Langfuse

There is a gap between an agent that works in my terminal and an agent I can sell to a client. I spent the last month closing it.

Here is the stack that emerged: OKF for the agent's portable definition, n8n as the build and execution runtime, and Langfuse for measurable output. Three pieces. Each one solves a specific failure mode I kept hitting.

The problem the format solves

Every time I built an agent, the same thing happened. The agent worked fine in its original context. Then I wanted to move it, adapt it, or explain what it does to someone else. And all the context was in my head. The agent's purpose, its inputs, what tools it calls, how it should behave - none of it was written down in a way an agent or a human could read.

I needed a portable agent definition. Something both a human and an AI could parse. Something that traveled with the agent, not in a separate README that would go stale.

Google's Open Knowledge Format (OKF) landed at the right time. It is a simple spec: markdown files with YAML frontmatter, a required type field, reserved index.md and log.md, and cross-links. Apache 2.0. Vendor-neutral. Google Cloud published it with the premise that knowledge written by different producers should be consumable by different agents without translation.

For agents specifically, we defined a type called NxtNodeAgent. Its frontmatter declares everything about the agent: its name, its tier on the Autonomy Ladder (0 for suggest-only, 3 for fully autonomous), its runtime, its flow file, and its Langfuse trace contract. The whole thing lives in git beside the agent's definition. One directory, versioned, portable.

This matters because the format is the operating system. When an agent's definition is locked in a structured document instead of scattered across notes and chat history, I can actually build systems around it - validators, scaffolders, drift detectors. Those systems read the same files I do.

The build runtime

n8n is the single door for building and running agents. The AI Agent nodes run on LangChain, so you get the full agent loop - memory, tools, model routing - inside the same visual builder that handles webhooks, scheduling, branching, and SaaS integrations. The Tools Agent explicitly implements LangChain's tool calling interface.

We played with Langflow as a dedicated agent designer. What we found was that n8n's AI Agent layer covers the same ground and eliminates the impedance mismatch. In Langflow you design the agent's reasoning loop, then you figure out how to wire it into a production pipeline. In n8n you design the agent and wire the pipeline in the same canvas. The agent's flow, its triggers, its outputs, its error handling - all in one place, all in one runtime.

I've been running n8n as my marketing automation engine for months. The SEO agent was the first proof that the same infrastructure handles agentic workflows just as well as scheduled automations. It runs on schedule, calls the model through a locally hosted LLM, routes output to the next step. No separate tools, no glue code between them. The same pattern scales to any agent: build the reasoning loop, wrap it with the integration layer, deploy it.

The measurement layer

An agent you cannot measure is an agent you cannot improve. This was the third failure mode: agents running in production with no signal on whether they were actually good.

Langfuse is the observability instrument. Every agent run produces a trace with token cost, latency, and quality scores. The trace is tagged with the same identifiers the agent's OKF bundle declares - agent name, function, venture, client. That shared vocabulary is the join: production telemetry reports how each function is actually performing, which is the feedback loop for the Autonomy Ladder.

There are three interop paths between n8n and Langfuse. The simplest: n8n's AI Agent nodes run on LangChain, which has first-class Langfuse callback support - wire credentials once and traces flow automatically. The most flexible: an n8n HTTP Request node POSTs to Langfuse's ingestion API using the same shapes the Python client already emits. The third is a packaged community Langfuse node.

The architecture has a portable core that never imports a concrete runtime producer. The taxonomy lives in a declarative JSON schema. Each runtime has a producer behind a registry. n8n is one of six named runtimes in the taxonomy alongside Claude Code, Hermes, qwen-code, pi, and cron.

For clients, the same pattern scales per tenant. A per-client config file sets the model override and branding. The harness builds the tweaks from it. Base behavior (no client) is unchanged. Each run is tagged with a client slug in Langfuse. One deployment, many clients, clean traces.

What it adds up to

Three pieces. OKF for the contract. n8n for the build and execution. Langfuse for the instrument.

The Autonomy Ladder gives each function a current tier and a target tier. T0 is tribal - nothing written. T1 is operationalized - documented, but a human drives it. T2 is assisted - the system drafts, a human approves. T3 is autonomous - runs unattended, exceptions surface. The agent's bundle declares where it is today and where it should reach. The build that closes the gap is the thing you build in n8n.

The gap between what runs today and what should run automatically is the map of every build decision you need to make. And that map lives in the same format as the agents themselves.

Three layers. Contract. Runtime. Instrument. Together they turn a one-off agent into something you can actually ship.

If you are self-hosting your own automation stack, you might also be interested in how I set up Cloudflare Tunnels for Docker or my guide to running AI agents on open-source infrastructure.