AI Agents in LoT
Your broker already moves sensor data, drives PLCs, and stores history. AI agents add something new: specialists that reason over that world — in plain language, on the same machine, with the same MQTT and Routes you already defined. In Coreflux, each agent is a LoT Route withTYPE AGENT. One block gives you the model, the persona, the tools, and the guardrails. Spin up an operator that answers shift questions. Add a classifier that never sees a chat window. Run five agents on one broker, each with its own brain and boundaries — no sidecar service, no copy-paste into a separate chatbot.
Defining the Route is only half the story. The other half is who gets to knock on the door: operators on MQTT topics the Route owns, or LoT Actions that dial the agent when something happens on the plant floor. Same agent definition — two front doors. Use one, use both, mix them across a team of Routes.
When to use AI Routes
- One agent, one job — chat helper, classifier, or scheduled production/maintenance/solar report; each gets its own Route
- Multi-agent teams — split models, prompts, and permissions by role (Multi-Agent Deployments)
- Ask the plant, don’t only dashboard it — “how many sensors are reporting?” before you wire another panel
- MQTT-facing chat —
INTERACTION_TOPICon the Route, plus MQTT ask/reply topics (your Action or custom app) - Hands-off automation —
CALL AGENTwhen a topic fires, a timer ticks, or a pipeline needs a verdict
First time? Build both patterns in ten minutes: Creating Agents in Coreflux. Then come back here for providers, tools, and production detail.
Complete Example (Copy & Deploy)
Pick one tab to ship something fast, or deploy both on the same broker. Each example is self-contained — you do not need to read the rest of this page first.Prerequisites (both tabs): Broker running and an OpenAI API key stored on the broker as a secret (once):The examples below reference it with
GET SECRET "OPENAI_KEY". Prefer local inference? Swap to PROVIDER "ollama" — see Picking a Provider.- Talk with your data
- Automatic report
Pattern: Route interaction topics — the AGENT Route owns the model and
INTERACTION_TOPIC; a thin Action exposes ask/reply MQTT topics you can hit from MQTT Explorer or the HUB Data Viewer.The HUB AI Assistant (Coreflux icon in the dock) is a separate built-in agent installed by the AI Setup wizard — it is not wired to
PlantAssistant or your custom INTERACTION_TOPIC.Deploy Route and Action
Paste both blocks into Coreflux HUB (LoT Editor → Routes, then Actions), a LoT Notebook, or your usual deploy path. Confirm PlantAssistant (AGENT) and AskPlantAssistant (Action) are healthy.
Send a question over MQTT
In MQTT Explorer or HUB Data Viewer (MQTT app), publish your question to
Try another live-data prompt, for example:
plant/assistant/ask and subscribe to plant/assistant/reply:| Direction | Topic | Example payload |
|---|---|---|
| Publish | plant/assistant/ask | Which MQTT topics are active right now? |
| Subscribe | plant/assistant/reply | Agent answer (plain text) |
What is the latest payload on sensors/zone1/temperature?You can talk with your data over MQTT — the agent uses broker tools, not a static chat transcript.
Two Ways to Interact
You write the agent once in LoT. How the world talks to it splits two ways — pick the door that fits, or run both on the same broker.| Pattern | Where it lives | Best for |
|---|---|---|
| Route interaction topics | INTERACTION_TOPIC on the AGENT Route (+ MQTT topics your Action or app uses) | People, custom chat UIs, MQTT Explorer, HUB Data Viewer |
CALL AGENT in Actions | LoT CALL AGENT "RouteName.execute" inside an Action | Sensor pipelines, timers, branching logic, structured jobs with no public chat surface |
INTERACTION_TOPIC for shift handover chat, plus a Classifier Route that only ever runs via CALL AGENT from a sensor Action.
Minimal Example
The shortest possible AI Route points at a local Ollama model and nothing else. It has no tools yet — it simply answers questions using the LLM:This default assumes Ollama is running locally at
http://localhost:11434. Pull the model first with ollama pull llama3.2 if you haven’t already.Picking a Provider
AI Routes support four providers out of the box. Pick the one that matches where your model lives — local or cloud. Cloud providers need an API key, which you should store as a secret rather than pasting into the Route.- Ollama (local)
- OpenAI
- Anthropic
- Mistral
Runs entirely on your machine — no API key, no cloud dependency. Good for getting started and for privacy-sensitive workloads. The broker default is
llama3.2; for stronger local quality in 2026, many teams use qwen3:8b or qwen3:4b on the same Ollama endpoint.Core Configuration
These are the parameters most users will touch. TheAGENT route has more advanced knobs (history pruning, tracing, token limits, confirmation flows), but you don’t need them on day one.
| Parameter | Type | Default | What it does |
|---|---|---|---|
PROVIDER | string | ollama | Which LLM backend to use: ollama, openai, anthropic, mistral |
MODEL | string | llama3.2 | Model name for the chosen provider |
API_KEY | string | — | API key for cloud providers (use GET SECRET) |
TEMPERATURE | number | 0.7 | Creativity: 0.0 is deterministic, 1.0+ is more creative |
SYSTEM_PROMPT | string | (built-in) | Sets the agent’s persona and rules |
BROKER_TOOLS | boolean | false | Give the agent built-in tools to read/write MQTT and Routes |
MCP_ROUTES | string | — | Comma-separated names of MCP Routes the agent can call |
INTERACTION_MODE | string | autonomous | autonomous runs to completion, interactive can ask you questions |
INTERACTION_TOPIC | string | (auto) | Base MQTT topic for interaction messages |
AGENT_MODE | string | agent | agent (full control) or insight (read-only exploration) |
More options exist for production deployments — conversation history pruning, execution tracing, tool confirmation, max iteration limits. Start with the basics above, then add them as you need them.
What Tools Can the Agent Use?
A fresh agent only knows how to chat. To make it actually do things, you give it tools. There are three sources, and you can mix all three.Broker Tools
SettingBROKER_TOOLS true unlocks built-in tools so the agent can interact with your broker directly — no extra configuration required.
- List MQTT topics and peek at their latest payloads
- Read a specific topic on demand
- Publish messages to any topic
- List your Routes to see what’s connected
MCP Tools
MCP (Model Context Protocol) servers expose tools like file systems, Slack, Google Drive, or custom integrations. Any MCP Route you’ve defined can be wired into an AI Route withMCP_ROUTES:
SlackMcp offers a send-message tool, the agent can call it when appropriate.
Your Other Routes
The agent also sees every other Route you’ve already defined. If you have a PostgreSQL Route with anInsertReading event, the agent automatically gets a tool named SensorDB.trigger_InsertReading. Same for Modbus, REST, MongoDB, and so on — you don’t need to re-declare anything.
Insight vs. Agent Mode
Not every AI Route should be able to publish messages or trigger equipment. UseAGENT_MODE to control how much power the agent has:
| Mode | What it can do | Good for |
|---|---|---|
insight | Read-only: list topics, read payloads, explore Routes | Exploring a broker, answering “what’s connected?” |
agent (default) | Full: read and write, trigger Routes, modify configuration | Automation, chat assistants, hands-on operators |
Pattern 1: Route Interaction Topics
SetINTERACTION_TOPIC on the AGENT Route and the broker wires interaction traffic under that prefix (for example follow-up questions on {prefix}/ask and replies on {prefix}/reply/{request_id} in interactive mode).
To start a conversation from MQTT Explorer or the HUB Data Viewer, add a thin Action that listens on your ask topic, runs CALL AGENT "YourRoute.execute", and publishes the answer — as in the Complete Example chat tab. Custom apps can implement the same prefix without that Action if they speak the broker’s interaction protocol.
The HUB AI Assistant is not your custom AGENT Route — it is the dock chat installed via AI Setup (
BrokerAgent). Use it to build dashboards and LoT; use INTERACTION_TOPIC + MQTT (or your UI) for agents you define in LoT.| Setting | Role |
|---|---|
INTERACTION_TOPIC | Base MQTT prefix for this Route’s chat (here: plant/operator) |
INTERACTION_MODE | interactive lets the agent pause and ask follow-ups; autonomous runs each task to completion |
INTERACTION_TIMEOUT | Seconds to wait for a human reply in interactive mode before continuing |
| Direction | Topic | What happens |
|---|---|---|
| Agent → client | {INTERACTION_TOPIC}/ask | Agent publishes a follow-up question |
| Client → agent | {INTERACTION_TOPIC}/reply/{request_id} | Your UI or MQTT client answers; work continues |
INTERACTION_TOPIC "plant/operator": subscribe to plant/operator/ask, publish replies to plant/operator/reply/{request_id}.
Pattern 2: CALL AGENT in LoT Actions
Keep the AGENT Route as the brain, but invoke it from LoT with CALL AGENT "RouteName.execute". The Action’s trigger (ON TOPIC, ON EVERY, and so on) decides when the agent runs; the task argument carries what to do. The result lands in a variable you can branch on or publish anywhere.
| Argument | Typical use |
|---|---|
task | Instruction or payload text (required) |
session_id | Same id on the next call continues one thread (per device, ticket, or line) |
use_history | "false" for one-off labels; "true" when follow-up calls should remember earlier steps |
INTERACTION_TOPIC so nothing listens on a public chat prefix — they only run when an Action calls them.
You can bridge CALL AGENT to custom MQTT topics if you want a bespoke ask/reply pair, but those topics belong to your Action, not the Route’s built-in interaction surface:
assistant/ask and assistant/reply are Action-defined topics; the agent still runs via CALL AGENT, not via INTERACTION_TOPIC.
Running several AI Routes? Pass
session_id and use_history on each CALL AGENT so parallel automation jobs do not share the wrong memory. See Multi-Agent Deployments.How It All Fits Together
The diagram below shows both patterns on one broker: MQTT clients use the Route’sINTERACTION_TOPIC; LoT Actions use CALL AGENT. Optional tool sources are the same in either case.
Every tool box is optional. A minimal agent with only MODEL still answers — it just cannot read your broker until you enable tools.
Multi-Agent Deployments
You are not limited to a single AI Route. The same Coreflux broker can run several agents at once — each one a normal Route with its own name, model, system prompt, and permissions. That matters whether you are learning the product or sizing it for production: you can give operators a conversational helper, give automation a fast classifier that never sees a chat window, and keep guests on a read-only view — without buying extra middleware or spinning up separate services for each role. From a buyer’s perspective, multi-agent is how you match cost to workload (local models for high-volume tasks, cloud models where quality matters most) and match risk to audience (full control for trusted staff, insight-only for everyone else). From a newcomer’s perspective, it is simply “define anotherDEFINE ROUTE … WITH TYPE AGENT block with a different name” — the broker runs them side by side.
Think of it like staffing a control room with specialists instead of one generalist — a friendly voice for the team at the desk, a quiet expert that only labels sensor readings, and a scheduled check-in that writes a health summary. They share the same broker, not the same job description.
Why give the broker more than one agent?
One catch-all assistant is hard to tune and expensive to run everywhere. Splitting the work pays off because:- Personalities differ. A chat assistant should be warm and conversational; a data classifier should be terse and deterministic.
- Access levels differ. The Route that can trigger equipment should not be the same one you hand to a visitor.
- Models and costs differ. A premium cloud model is a poor fit for every sensor reading — a local model can handle volume for free while heavier reasoning stays on the model you pay for.
- Memory should stay isolated. The person at shift handover should not inherit someone else’s half-finished conversation by accident.
How people and software reach each agent
Map each Route to Pattern 1 or Pattern 2 — or use both patterns on different Routes in the same project:| Entry | Pattern | Typical setup |
|---|---|---|
| Operators, chat apps, MQTT clients | Route topics | INTERACTION_TOPIC + ask/reply Action or custom UI; often INTERACTION_MODE "interactive" |
| Sensor pipelines, timers, batch jobs | CALL AGENT | ON TOPIC / ON EVERY Action, no INTERACTION_TOPIC on the Route |
| Background-only specialists | CALL AGENT only | autonomous mode, omit INTERACTION_TOPIC — no public chat prefix |
Conversations and memory
Each named AI Route keeps its own conversation state. Two different Routes never share the same chat history — they are separate assistants. Within one Route, a session id (from your MQTT topic path when using interactive chat, or fromsession_id on CALL AGENT) keeps parallel conversations apart: two operators, two browser tabs, or two machines can talk to the same Route without their threads colliding. If you omit session_id, the broker still runs the task using its default session behaviour for that call — pass an explicit session_id when you need a reliable multi-step thread (for example one id per device or per ticket).
How multi-agent traffic can look
Four agent archetypes
Most teams mix a few of these patterns — use one on a small setup, combine several when roles split. How to read the tabs: Operator and Reader are usually MQTT-facing (people or HUB). Specialist is typically LoT-only (no chat topic). Watchdog is triggered on a schedule from LoT but does not need its own chat line.- Operator
- Specialist
- Watchdog
- Reader
The staff-facing assistant. Lives on a chat topic, has broker tools, and runs in interactive mode so it can ask follow-up questions. This is the agent your team talks to.Entry: MQTT under your Best for: chat UIs, control-room copilots, customer-facing assistants.
INTERACTION_TOPIC prefix (via a thin ask/reply Action or a custom UI).Mixing providers across agents
PROVIDER and MODEL are set per Route, so every agent in the team can run on a different brain. Swap any of them by redeploying a single Route definition — no broker restart, no infrastructure change.
| Use case | Suggested model | Why |
|---|---|---|
| High-stakes operator chat | OpenAI gpt-5.5 or Anthropic claude-opus-4-7 | Frontier reasoning, handles ambiguity and multi-step tool use |
| Balanced production chat | OpenAI gpt-5.4 or Anthropic claude-sonnet-4-6 | Strong quality at lower cost than top-tier models |
| Low-latency classifiers | Ollama qwen3:8b (local) | Fast, private, good tool-following for structured labels |
| Scheduled operations reports | OpenAI gpt-5.4-mini | Production, maintenance, or solar digests on a timer |
| Management read portal | OpenAI gpt-5.4-mini | Cost-effective for low-volume read queries |
Smart habits when you run several agents
- Name Routes by role —
Line3ClassifierorVisitorGuide, notAgent2, so your team and your LoT Actions stay readable. - Give each worker only the tools it needs — A classifier rarely needs broker-wide publish access or MCP; fewer tools mean faster runs and fewer surprises.
- Remember that cost adds up — Each Route can call a cloud model on its own schedule. More agents and more
CALL AGENTtraffic multiply tokens and rate limits. - Match power to trust — Use Insight vs. Agent Mode for read-only audiences; reserve full
agentmode for staff Routes that must act. - Add confirmation where mistakes hurt —
TOOL_EXECUTION_MODE "confirm"on any Route that should pause before a destructive tool runs.
Per-agent safety rails
Safety settings apply per Route, so a strict assistant and a powerful one can live on the same broker. Pair the ideas in Insight vs. Agent Mode with the habits above: lock read-only audiences toinsight, keep trusted operators in full agent mode, and use TOOL_EXECUTION_MODE "confirm" only where you need a human gate before risky tools. Trace topics, iteration limits, and history pruning are also per agent — turn tracing on for the Route you are debugging so the rest of the team stays quiet.
Best Practices
Store API keys as secrets
Store API keys as secrets
Never paste API keys directly into a Route definition. Use
KEEP SECRET "MY_KEY" WITH "sk-..." once, then reference it with WITH API_KEY GET SECRET "MY_KEY". Secrets are never logged or exposed in stored definitions.Start in insight mode
Start in insight mode
When you’re still shaping the system prompt or picking a model, run the agent with
WITH AGENT_MODE "insight". It can still read topics and explore Routes, but it can’t publish or trigger anything — so a bad prompt won’t affect production data.Write a focused system prompt
Write a focused system prompt
The default prompt is generic. Tell the agent who it is and what it should refuse to do:
Keep iteration limits sane
Keep iteration limits sane
MAX_ITERATIONS caps how many tool calls the agent can make per task. The default (10) is fine for most questions. Lift it only if you have complex multi-step workflows — runaway loops are both slow and expensive on cloud providers.Troubleshooting
Ollama not reachable
Ollama not reachable
- Make sure Ollama is running:
ollama listshould respond without errors - Confirm the model is pulled:
ollama pull llama3.2 - If Ollama is on a different machine, set
WITH BASE_URL "http://host:11434"explicitly - Check firewall rules between the broker and the Ollama host
The agent never calls any tool
The agent never calls any tool
- Confirm
BROKER_TOOLS "true"is set (or thatMCP_ROUTESlists valid Routes) - Smaller local models sometimes ignore tools — try a more capable pull (e.g.
qwen3:8boverllama3.2, or switch to a cloud model such asgpt-5.4-miniorclaude-sonnet-4-6) - Sharpen the
SYSTEM_PROMPTso the agent knows it should use tools for data questions
Cloud provider returns 401 or 403
Cloud provider returns 401 or 403
- Verify the secret actually exists: publishing
LIST SECRETSvia the command console should show its name - Check you’re using the right
PROVIDER— Anthropic keys don’t work for OpenAI and vice versa - For Anthropic, make sure your key has access to the specific model you set in
MODEL
The reply is empty or gets cut off
The reply is empty or gets cut off
- Raise
MAX_TOKENS— long answers need more room (default is4096) - Check the model actually supports the request (some smaller models struggle with long context)
- If you chained several tool calls, the agent may have hit
MAX_ITERATIONS— increase it and retry
Next Steps
Creating Agents in Coreflux
Hands-on tutorial — chat over MQTT, automatic reports, broker tools, and multi-agent layouts in minutes.
MCP Routes
Plug external tools — Slack, file systems, Google Drive, custom servers — into your agent.

