Governed AI agents inside n8n workflows — Kohala
Import one prebuilt step and every n8n execution becomes a governed Kohala run — status, duration, node-level traces, and token spend under charters and caps. Kohala accepts n8n's own payload; retries never bill twice.
Explore Kohala
Frequently Asked Questions
- How does Kohala fit into an n8n workflow?
- Add the prebuilt Kohala step to your workflow (import examples/framework-agents/n8n-governed-run/workflow.json), point it at your agent with a pk_ API key, and every execution appears in Kohala as a governed run — status, duration, node-level trace entries, and token spend — recorded under the same charter and held to the same caps and validators as any other run. You can also go the other way and call a governed Kohala agent from an HTTP Request node.
- Can I import an AI agent I built in n8n?
- No — an n8n workflow is an orchestration graph, not a code artifact Kohala can host, so there is nothing to paste into the import wizard. Keep the workflow in n8n and report its executions as governed runs instead, or build the agent itself on Kohala and call it from an HTTP Request node.
- What stops a replayed or retried execution from billing twice?
- Kohala derives the run's identity from n8n's own execution ID, so an n8n retry of a failed HTTP step, or a manual re-send of the same payload, resolves to the original run and returns idempotent: true. One execution is one governed run, metered once.
- What happens when the wallet or a cap blocks the run?
- The endpoint refuses with a message field n8n shows in the node's error panel: 402 with denied: wallet or member_quota, 429 with per_run_cap or per_day_cap, 401 for a missing or wrong signature. An admission refusal records nothing and bills nothing. A per-run cap tripped by usage the delivery itself reported is different: that spend already happened, so the run is kept and marked failed at the cap.