Tln is a language; OpenTalon is where it runs at enterprise scale. OpenTalon is an open-source, Go-built AI-orchestration platform for organizations that need AI in production — predictable behaviour, auditable boundaries, deterministic business rules, and expert-defined guardrails. Tln is its decision core.

The division of labour

The core idea is Expert-in-the-Loop (EITL): the LLM handles conversation and intent; Tln handles knowledge and inference. Two ways Tln shows up:

  • The LLM writes Tln, not raw tool calls. Following the same insight as Cloudflare’s Code Mode for MCP, OpenTalon has the model emit Tln scenarios in a deliberately restricted DSL rather than orchestrating tool calls directly. The grammar physically cannot express unsafe operations, so the sandbox is structural — not a policy you hope the model follows.
  • Domain experts write Tln rules and workflows. The gates, policies, and review steps that govern a decision are authored once by the people who own them, and the runtime enforces them deterministically — the same rules you’ve seen throughout these docs.

So a request flows: user → core/LLM (intent) → Tln (facts, rules, decision) → plugins (act), with people reserved for the rare case that genuinely needs them.

Humanonly exceptionsChanneluser messageLLMintent · languageTlnfacts · rules · decisionPluginstools · actoutcome to the user
Expert-in-the-Loop — the LLM handles intent, Tln makes the deterministic decision, and a human is called only for the rare exception.

Every IO edge is a plugin

Tln’s core is a pure language + planner with transport-free IO: it decides what should happen and returns it as data. OpenTalon provides the edges as isolated plugins, each running as a separate OS process over gRPC — a compromised or buggy plugin can never read the core’s memory, and plugins can’t call each other; only the core/LLM decides what runs next.

  • Tools — tln-mcp resolves tool calls over the Model Context Protocol. See MCP & workflows.
  • Storage — tln-db, the Go-native fact store behind the FactStore interface (bbolt + roaring-bitmap index + HNSW vectors).
  • Channels — Slack, HTTP, MS Teams, WebSocket, console.
  • Security & retrieval — guard-llm (LLM guardrails), weaviate (RAG / vector search).

The same shape as the language: a deterministic core, with tln-mcp on the tool side and tln-db on the storage side, and OpenTalon composing the rest into a production system.

Because OpenTalon is the host, its plugin bindings win over any connector a program declares — so the very same rules run standalone (tln run with in-source connectors) or hosted, unchanged. And since OpenTalon runs LLM-authored Tln, it sandboxes that source: env is cut and io restricted, so a generated scenario can’t reach secrets or the filesystem. See the two run modes.

The loop

  1. A message arrives on a channel (Slack, HTTP, …).
  2. The core/LLM interprets intent and — where a decision is needed — emits a Tln scenario.
  3. Tln reasons over facts (pulled from tln-db, RAG, or collect/enrich via MCP), applies the experts’ rules, and produces a deterministic, explainable decision.
  4. Approved actions dispatch through plugins (tln-mcp tools, channels), each isolated.

The result is an AI system whose decisions are reproducible, auditable, and governed by the people accountable for them — with Tln as the deterministic brain at the center.

Explore