Agent Examples

Preview

DEFINE AGENT is a preview feature. It ships in broker 2.22. The syntax and behaviour may still change.

Why build with Agents

Whether you operate a production line, a solar substation, a city sensor network, or a cold-chain fleet, raw MQTT telemetry only tells you what changed — not what to do next. With a LoT Agent, you pair a language model (TYPE LLM connector) with explicit, scoped tool grants (ADD TOOL) so people and LoT Actions can ask questions, classify events, summarize operations, and trigger approved workflows right inside the broker.

Like hiring a specialist with a keycard. The TYPE LLM connector is the brain, and each DEFINE AGENT is a specialist whose keycard (ADD TOOL) only opens the exact topics, actions, and connectors needed for that job.

When to use these patterns

Example	Pattern	Best for
Core agent patterns	`read_mqtt`, `write_mqtt` + `INTERACTION_TOPIC`	Chatting with live telemetry and publishing scoped reports
Supervisor with specialists	Multi-agent delegation (`WITH AGENTS`)	Coordinating domain specialists under one shared token budget
Manufacturing use cases	`CALL AGENT` + `execute_routes`	Classifying floor notes and logging quality checks to a database
Energy use cases	Scoped advisories + fault triage	Advising solar farm dispatch and triaging EV charger faults
Smart cities use cases	Scheduled `CALL AGENT` + `execute_actions`	Publishing air quality bulletins and coordinating street lighting
Smart buildings and logistics	Guardrails + cold-chain excursion alerts	Running an HVAC comfort desk and protecting refrigerated cargo
Intelligent Things (Things with Agents)	`DEFINE THING` + `WITH AGENT`	Stamping out equipment templates where every asset has its own scoped agent

The examples below are complete and ready to deploy. Create each DEFAULT_USER with -addUser, deploy connectors with -addConnector, deploy agents with -addAgent, and deploy actions with -addAction (or validate first with -validateLot).

Core agent patterns

Start with the two most common building blocks: a read-only chat agent running on a local Ollama model, and a reporting agent that is allowed to publish summaries to a single topic tree.

Chat with a local agent
Publish a shift report

Run a tools-capable Ollama model on the broker host and grant it read access to one topic tree. Create the user line-viewer with -addUser before deploying the agent:

DEFINE CONNECTOR LocalLlama WITH TYPE LLM
    ADD LLM_CONFIG
        WITH PROVIDER "ollama"
        WITH BASE_URL "http://localhost:11434"
        WITH MODEL "llama3.2"

DEFINE AGENT LineWatcher
    USES LLM CONNECTOR LocalLlama
    WITH DESCRIPTION "Answers questions about line telemetry"
    WITH DEFAULT_USER "line-viewer"
    WITH INTERACTION_TOPIC "plant/watcher"
    ADD TOOL "read_mqtt"
        WITH TOPICS "lines/+/telemetry/#"

Publish Is line 2 running hot? to plant/watcher/s1/ask. The answer arrives on plant/watcher/s1/response, and each tool call appears on $SYS/Coreflux/Agents/LineWatcher/task/s1/stream.

Grant write_mqtt with WITH LEVEL "write" so the agent can publish under reports/shift/# and nowhere else:

DEFINE CONNECTOR Claude WITH TYPE LLM
    ADD LLM_CONFIG
        WITH PROVIDER "anthropic"
        WITH MODEL "claude-sonnet-5-5"
        WITH API_KEY GET SECRET "ANTHROPIC_API_KEY"

DEFINE AGENT ShiftReporter
    USES LLM CONNECTOR Claude
    WITH DESCRIPTION "Writes the end-of-shift report"
    WITH DEFAULT_USER "report-writer"
    WITH INTERACTION_TOPIC "plant/reporter"
    ADD TOOL "read_mqtt"
        WITH TOPICS "alarms/#, lines/+/counters/#"
    ADD TOOL "write_mqtt"
        WITH TOPICS "reports/shift/#"
        WITH LEVEL "write"

A publish to reports/shift/2026-10-22 succeeds when report-writer has publish permission there. Any attempt to publish to lines/3/cmd is refused as out_of_scope on the task stream.

Supervisor with specialists

Instead of giving one agent every topic in the plant, split the work across focused specialists and let a supervisor delegate with WITH AGENTS. All agents share one TYPE LLM connector and one root task token budget:

DEFINE CONNECTOR Gpt6 WITH TYPE LLM
    ADD LLM_CONFIG
        WITH PROVIDER "openai"
        WITH MODEL "gpt-6-luna"
        WITH API_KEY GET SECRET "OPENAI_API_KEY"

DEFINE AGENT AlertAnalyst
    USES LLM CONNECTOR Gpt6
    WITH DESCRIPTION "Explains active alarms from recent history"
    WITH DEFAULT_USER "alarm-viewer"
    WITH MEMORY "none"
    ADD TOOL "read_mqtt"
        WITH TOPICS "alarms/#"

DEFINE AGENT MaintenancePlanner
    USES LLM CONNECTOR Gpt6
    WITH DESCRIPTION "Reads the maintenance schedule and open work orders"
    WITH DEFAULT_USER "maint-viewer"
    ADD TOOL "read_mqtt"
        WITH TOPICS "maintenance/#"

DEFINE AGENT ShiftSupervisor
    USES LLM CONNECTOR Gpt6
    WITH DESCRIPTION "Prepares the shift briefing with specialist input"
    WITH DEFAULT_USER "shift-ops"
    WITH AGENTS "AlertAnalyst, MaintenancePlanner"
    WITH MAX_TOKENS 80000
    WITH INTERACTION_TOPIC "plant/supervisor"
    ADD TOOL "read_lot"

When an operator asks a question on plant/supervisor/s1/ask, ShiftSupervisor can delegate to AlertAnalyst and MaintenancePlanner. Every tool call in the delegation tree still authorizes against the user who started the chain:

Agent	Role	Tool grants	Memory
`AlertAnalyst`	Explains alarm history	`read_mqtt` on `alarms/#`	`none` (stateless)
`MaintenancePlanner`	Checks schedules and work orders	`read_mqtt` on `maintenance/#`	`individual` (default)
`ShiftSupervisor`	Coordinates both specialists	`read_lot` + delegates to both peers	`individual` (default)

Manufacturing use cases

On the shop floor, agents can classify unstructured operator notes automatically from LoT Actions or log structured quality checks through a database connector.

Classify operator notes
Log quality inspections

Use a stateless agent (WITH MEMORY "none") and CALL AGENT inside an Action to label every floor note as safety, quality, or maintenance:

DEFINE CONNECTOR LocalLlama WITH TYPE LLM
    ADD LLM_CONFIG
        WITH PROVIDER "ollama"
        WITH BASE_URL "http://localhost:11434"
        WITH MODEL "llama3.2"

DEFINE AGENT NoteClassifier
    USES LLM CONNECTOR LocalLlama
    WITH DESCRIPTION "Labels operator shift notes by category"
    WITH DEFAULT_USER "agent-svc"
    WITH SYSTEM_PROMPT "Classify the operator note with one word: safety, quality, or maintenance."
    WITH MEMORY "none"

DEFINE ACTION ClassifyFloorNote
ON TOPIC "factory/notes/raw" DO
    CALL AGENT "NoteClassifier.execute"
        WITH (task = PAYLOAD)
        RETURN AS {category}
    PUBLISH TOPIC "factory/notes/labeled" WITH {category}

Publishing "Guard door sensor on press 2 is loose" to factory/notes/raw runs NoteClassifier without storing conversation history and publishes "safety" to factory/notes/labeled.

Grant execute_routes on a single connector event (QualityDB.InsertCheck) so an inspector can ask the agent to check live batch tolerances and record the result in PostgreSQL:

DEFINE CONNECTOR QualityDB WITH TYPE POSTGRESQL
    ADD SQL_CONFIG
        WITH SERVER GET ENV "PG_HOST"
        WITH PORT 5432
        WITH DATABASE "manufacturing"
        WITH USERNAME GET ENV "PG_USER"
        WITH PASSWORD GET SECRET "PG_PASSWORD"
    ADD EVENT InsertCheck
        WITH SOURCE_TOPIC "factory/quality/db/insert"
        WITH DESTINATION_TOPIC "factory/quality/db/result"
        WITH QUERY "INSERT INTO quality_checks (notes, created_at) VALUES ('{payload}', NOW())"

DEFINE CONNECTOR Claude WITH TYPE LLM
    ADD LLM_CONFIG
        WITH PROVIDER "anthropic"
        WITH MODEL "claude-sonnet-5-5"
        WITH API_KEY GET SECRET "ANTHROPIC_API_KEY"

DEFINE AGENT QualityInspector
    USES LLM CONNECTOR Claude
    WITH DESCRIPTION "Reviews batch measurements and logs quality checks"
    WITH DEFAULT_USER "quality-ops"
    WITH INTERACTION_TOPIC "factory/quality/assistant"
    ADD TOOL "read_mqtt"
        WITH TOPICS "factory/quality/batches/#"
    ADD TOOL "execute_routes"
        WITH TARGET "QualityDB.InsertCheck"
        WITH LEVEL "write"

QualityInspector can trigger QualityDB.InsertCheck, while any other event on QualityDB (such as a delete or schema query) remains out_of_scope.

Energy use cases

Power generation sites and EV charging hubs use agents to summarize inverter telemetry for dispatchers and translate raw charger fault codes into field instructions.

Solar farm advisor
EV charging fault triage

Let grid operators query live solar inverter output and grid frequency under grid/solar/#, and allow the agent to publish curtailment advisories under grid/solar/advisories/#:

DEFINE CONNECTOR Gpt6 WITH TYPE LLM
    ADD LLM_CONFIG
        WITH PROVIDER "openai"
        WITH MODEL "gpt-6-luna"
        WITH API_KEY GET SECRET "OPENAI_API_KEY"

DEFINE AGENT SolarAdvisor
    USES LLM CONNECTOR Gpt6
    WITH DESCRIPTION "Monitors solar inverters and publishes dispatch advisories"
    WITH DEFAULT_USER "grid-ops"
    WITH SYSTEM_PROMPT "Check inverter power_kw and frequency_hz topics. Flag any inverter below 49.8 Hz or underperforming its peers."
    WITH INTERACTION_TOPIC "grid/solar/advisor"
    ADD TOOL "read_mqtt"
        WITH TOPICS "grid/solar/+/telemetry/#, grid/solar/+/alarm"
    ADD TOOL "write_mqtt"
        WITH TOPICS "grid/solar/advisories/#"
        WITH LEVEL "write"

Topic pattern	Access	Purpose
`grid/solar/advisor/<session>/ask`	Inbound chat	Grid operators ask about site generation or alarms
`grid/solar/+/telemetry/#`	`read_mqtt`	Agent reads live power and frequency per inverter
`grid/solar/advisories/#`	`write_mqtt` (`write`)	Agent publishes dispatch or curtailment notes

When an EV charging bay reports a fault on chargers/+/fault, an Action calls a stateless technician agent to read the bay’s session telemetry and publish a three-step troubleshooting note:

DEFINE CONNECTOR Claude WITH TYPE LLM
    ADD LLM_CONFIG
        WITH PROVIDER "anthropic"
        WITH MODEL "claude-sonnet-5-5"
        WITH API_KEY GET SECRET "ANTHROPIC_API_KEY"

DEFINE AGENT ChargerTech
    USES LLM CONNECTOR Claude
    WITH DESCRIPTION "Triages EV charger faults with live bay telemetry"
    WITH DEFAULT_USER "charger-ops"
    WITH SYSTEM_PROMPT "Read the bay session topic and explain the fault in 3 short steps: cause, remote check, and whether to dispatch a technician."
    WITH MEMORY "none"
    ADD TOOL "read_mqtt"
        WITH TOPICS "chargers/+/session, chargers/+/alarm"

DEFINE ACTION TriageChargerFault
ON TOPIC "chargers/+/fault" DO
    SET "bay" WITH TOPIC POSITION 2
    CALL AGENT "ChargerTech.execute"
        WITH (task = "Bay " + {bay} + " reported fault: " + PAYLOAD)
        RETURN AS {steps}
    PUBLISH TOPIC "chargers/" + {bay} + "/triage" WITH {steps}

Publishing "OCPP_ERR_OVERCURRENT" to chargers/bay3/fault reads chargers/bay3/session and publishes the triage steps to chargers/bay3/triage.

Smart cities use cases

Municipal teams use agents to turn sensor networks into plain-language public bulletins and to coordinate district infrastructure such as street lighting.

Urban air quality bulletin
District lighting coordinator

Run a scheduled Action every hour that asks AirQualityReporter to read city-wide PM2.5 and NO2 stations and publish a short bulletin for school zones and public dashboards:

DEFINE CONNECTOR Gpt6 WITH TYPE LLM
    ADD LLM_CONFIG
        WITH PROVIDER "openai"
        WITH MODEL "gpt-6-luna"
        WITH API_KEY GET SECRET "OPENAI_API_KEY"

DEFINE AGENT AirQualityReporter
    USES LLM CONNECTOR Gpt6
    WITH DESCRIPTION "Summarizes urban air quality readings into public bulletins"
    WITH DEFAULT_USER "city-env"
    WITH SYSTEM_PROMPT "Read all station readings under city/air/. Summarize PM2.5 and NO2 levels in 3 bullet points, highlighting any school_zone alerts."
    WITH MEMORY "none"
    ADD TOOL "read_mqtt"
        WITH TOPICS "city/air/#"

DEFINE ACTION HourlyAirBulletin
ON EVERY 1 HOURS DO
    CALL AGENT "AirQualityReporter.execute"
        WITH (task = "Write the hourly city air quality bulletin from live station topics.")
        RETURN AS {bulletin}
    PUBLISH TOPIC "city/bulletins/air" WITH {bulletin}

Every hour, HourlyAirBulletin publishes a fresh summary to city/bulletins/air without requiring an open chat session.

Grant execute_actions on a specific fallback action (EnableStormLighting) so a city operations desk can inspect ambient lux sensors and switch an entire district to full brightness during severe weather:

DEFINE ACTION EnableStormLighting
ON TOPIC "city/lights/downtown/storm_override" DO
    PUBLISH TOPIC "city/lights/downtown/main_st/brightness" WITH 100
    PUBLISH TOPIC "city/lights/downtown/park_ave/brightness" WITH 100

DEFINE CONNECTOR LocalLlama WITH TYPE LLM
    ADD LLM_CONFIG
        WITH PROVIDER "ollama"
        WITH BASE_URL "http://localhost:11434"
        WITH MODEL "llama3.2"

DEFINE AGENT LightingCoordinator
    USES LLM CONNECTOR LocalLlama
    WITH DESCRIPTION "Monitors district street lights and triggers storm lighting"
    WITH DEFAULT_USER "lighting-ops"
    WITH GUARDRAILS "Only run EnableStormLighting when ambient lux is below 25 or a weather alert is active."
    WITH INTERACTION_TOPIC "city/lights/desk"
    ADD TOOL "read_mqtt"
        WITH TOPICS "city/lights/downtown/#, city/weather/alerts"
    ADD TOOL "execute_actions"
        WITH TARGET "EnableStormLighting"
        WITH LEVEL "write"

LightingCoordinator can read city/lights/downtown/# and invoke EnableStormLighting, but cannot run any other action on the broker.

Smart buildings and logistics

Facility managers and logistics teams use agents to balance occupant comfort with energy targets and to protect temperature-sensitive cargo in transit.

Building HVAC comfort desk
Cold-chain fleet monitor

Let facility staff ask questions about floor temperatures and CO2 levels, and allow the agent to publish setpoint recommendations within safe guardrails:

DEFINE CONNECTOR Claude WITH TYPE LLM
    ADD LLM_CONFIG
        WITH PROVIDER "anthropic"
        WITH MODEL "claude-sonnet-5-5"
        WITH API_KEY GET SECRET "ANTHROPIC_API_KEY"

DEFINE AGENT ComfortDesk
    USES LLM CONNECTOR Claude
    WITH DESCRIPTION "Advises facility managers on HVAC comfort and CO2 levels"
    WITH DEFAULT_USER "facilities-ops"
    WITH SYSTEM_PROMPT "You assist building operators. Check zone temperature, humidity, and CO2 before recommending a setpoint."
    WITH GUARDRAILS "Never recommend a temperature setpoint below 19 C or above 24 C."
    WITH INTERACTION_TOPIC "building/hvac/desk"
    ADD TOOL "read_mqtt"
        WITH TOPICS "building/zones/+/telemetry/#, building/chillers/#"
    ADD TOOL "write_mqtt"
        WITH TOPICS "building/hvac/recommendations/#"
        WITH LEVEL "write"

Note that WITH GUARDRAILS steers the model’s recommendations, while ADD TOOL "write_mqtt" enforces that the agent can only publish to building/hvac/recommendations/# — never directly to physical damper or chiller command topics.

When a refrigerated truck reports a temperature excursion on fleet/+/excursion, an Action calls ColdChainAnalyst with session_id set to the truck ID so repeated alerts on the same vehicle share conversation context:

DEFINE CONNECTOR Gpt6 WITH TYPE LLM
    ADD LLM_CONFIG
        WITH PROVIDER "openai"
        WITH MODEL "gpt-6-luna"
        WITH API_KEY GET SECRET "OPENAI_API_KEY"

DEFINE AGENT ColdChainAnalyst
    USES LLM CONNECTOR Gpt6
    WITH DESCRIPTION "Assesses cold-chain temperature excursions for refrigerated trucks"
    WITH DEFAULT_USER "fleet-ops"
    WITH SYSTEM_PROMPT "Check the truck reefer temperature, door status, and ETA. State whether cargo is at risk and the next action for dispatch."
    ADD TOOL "read_mqtt"
        WITH TOPICS "fleet/+/telemetry/#"

DEFINE ACTION AssessExcursion
ON TOPIC "fleet/+/excursion" DO
    SET "truckId" WITH TOPIC POSITION 2
    CALL AGENT "ColdChainAnalyst.execute"
        WITH (task = "Excursion on " + {truckId} + ": " + PAYLOAD, session_id = {truckId})
        RETURN AS {assessment}
    PUBLISH TOPIC "fleet/" + {truckId} + "/assessment" WITH {assessment}

Because ColdChainAnalyst uses the default MEMORY "individual" and AssessExcursion passes session_id = {truckId}, each truck gets its own ongoing session history across multiple excursion alerts.

Intelligent Things (Things with Agents)

When you have repeated physical assets that each need their own AI assistant, embed WITH AGENT inside a DEFINE THING TEMPLATE. Every Thing instance automatically gets an agent scoped to its own topic path ({{path}}/#), and a parent station can delegate to its child assets’ agents using relative paths (p1.Assistant, p2.Assistant):

DEFINE CONNECTOR PlantLLM WITH TYPE LLM
    ADD LLM_CONFIG
        WITH PROVIDER "openai"
        WITH MODEL "gpt-6-luna"
        WITH API_KEY GET SECRET "OPENAI_API_KEY"

DEFINE THING TEMPLATE SmartPump
    WITH PARAM llm AS CONNECTOR
    WITH PARAM agentUser
    WITH AGENT Assistant
        USES LLM CONNECTOR {{llm}}
        WITH DEFAULT_USER "{{agentUser}}"
        WITH INTERACTION_TOPIC "{{path}}/assistant"
        ADD TOOL "read_mqtt"
            WITH TOPICS "{{path}}/#"
    WITH ACTION DiagnoseAlarm
    ON TOPIC "{{path}}/alarm" DO
        CALL AGENT "Assistant.execute"
            WITH (task = "Pump {{thing}} alarm: " + PAYLOAD)
            RETURN AS {advice}
        PUBLISH TOPIC "{{path}}/advice" WITH {advice}

DEFINE THING TEMPLATE SmartStation
    WITH PARAM llm AS CONNECTOR
    WITH PARAM agentUser
    WITH THING p1 OF SmartPump
    WITH THING p2 OF SmartPump
    WITH AGENT Supervisor
        USES LLM CONNECTOR {{llm}}
        WITH DEFAULT_USER "{{agentUser}}"
        WITH AGENTS "p1.Assistant, p2.Assistant"
        WITH INTERACTION_TOPIC "{{path}}/supervisor"
        ADD TOOL "read_mqtt"
            WITH TOPICS "{{path}}/#"

DEFINE THING north OF SmartStation
    WITH PARAM path "plant/north"
    WITH PARAM llm "PlantLLM"
    WITH PARAM agentUser "agent-north"

Deploying PlantLLM with -addConnector and the DEFINE THING blocks with -addThing expands north into two pump assistants (north_p1_Assistant, north_p2_Assistant), two diagnostic actions (north_p1_DiagnoseAlarm, north_p2_DiagnoseAlarm), and a station supervisor (north_Supervisor) that can delegate to both pumps. See Thing Examples for more patterns.

Verify your deployment

Validate the LoT code

Send -validateLot <DEFINE …> to $SYS/Coreflux/Command to check connector, agent, and action syntax before deploying.

Deploy the LLM connector and the agent

Send -addConnector <DEFINE CONNECTOR …> and -addAgent <DEFINE AGENT …> to $SYS/Coreflux/Command. Run -listAgents to confirm the agent status is online.

Watch the live task stream

Use MQTT Explorer or Coreflux HUB to subscribe to $SYS/Coreflux/Agents/<agent>/task/+/stream and {INTERACTION_TOPIC}/+/response while sending a test question to {INTERACTION_TOPIC}/s1/ask.

Best practices

Give each agent a least-privilege DEFAULT_USER

Every tool call checks both ADD TOOL scope and the permissions of the user the task runs as (plus DEFAULT_USER). Never use root as DEFAULT_USER — create a dedicated user with only the topic and command permissions the agent needs.

Use MEMORY none for one-shot classifiers and scheduled jobs

Set WITH MEMORY "none" on agents called by high-volume ON TOPIC or ON EVERY actions so each run is stateless and does not spend tokens resending prior turns.

Use ADD TOOL for hard limits and GUARDRAILS for guidance

WITH GUARDRAILS steers the model’s reasoning, but ADD TOOL and RBAC are what enforce boundaries. Keep critical actuator topics outside write_mqtt grants until a human or deterministic LoT Action validates the output.

Next steps

Agent Syntax

Full reference for DEFINE AGENT clauses, ADD TOOL grants, delegation, and topics.

Agents Overview

Learn how agents pair with TYPE LLM connectors and when to use CALL AGENT.

Quick Start

Coreflux MQTT Broker

LoT Language

Coreflux HUB

VS Code - LoT Notebooks

Coreflux Portal

Using AI with Coreflux

Product Updates

Why build with Agents

When to use these patterns

Core agent patterns

Supervisor with specialists

Manufacturing use cases

Energy use cases

Smart cities use cases

Smart buildings and logistics

Intelligent Things (Things with Agents)

Verify your deployment

Best practices

Next steps

Agent Syntax

Agents Overview

​Why build with Agents

​When to use these patterns

​Core agent patterns

​Supervisor with specialists

​Manufacturing use cases

​Energy use cases

​Smart cities use cases

​Smart buildings and logistics

​Intelligent Things (Things with Agents)

​Verify your deployment

​Best practices

​Next steps

Agent Syntax

Agents Overview

Why build with Agents

When to use these patterns

Core agent patterns

Supervisor with specialists

Manufacturing use cases

Energy use cases

Smart cities use cases

Smart buildings and logistics

Intelligent Things (Things with Agents)

Verify your deployment

Best practices

Next steps