FAQ & Glossary

A deep stack, read bottom-up — the agents are the easy front-end to power that was already there:

• Foundation — spatial primitives + scalable query tools. A zero-dependency spatial core (rtls-core, 140+ pure functions) runs the geometry that location data needs at scale: ~6.6 million distance, ~4 million point-in-polygon and ~10 million area operations per second, and searches 10,000 zones in under 5ms — with six route-optimization algorithms and A* with four heuristics. Over it, a scalable querying and manipulation layer (rtls-api) exposes 130 REST endpoints across 20 modules, a query language with 20+ operators, real-time WebSocket streaming and Redis multi-instance scaling — fusing 8 positioning technologies and processing 100,000+ positions per second.
• Harness — a scalable, secured, model-agnostic agentic harness. It runs on that foundation: isolated per-user sessions, JWT + API key + namespace scoping, governed tool access (the model only sees what your LLM-Enabled toggles allow), human-in-the-loop confirmation and a full audit trail. It runs on any LLM — cloud frontier or open-weight on-premise — and swapping the model is a configuration change.
• Agents + governed interface on top. Three agents — Rule Agent, Script Agent and Dashboard Copilot — perceive → reason → act, in production since 2025. They reach the foundation through a governed interface of 44 tools across the three agents — the open connector, not the product.

The moat is the depth — spatial primitives, real-time scale, and a secured model-agnostic harness — not a chatbot or a tool count.

At the interface level: 44 governed agent tools, a 130-endpoint REST API, and WebSocket streaming.

• 44 governed tools across three agents — the Dashboard Copilot, the Script Agent and the RTLS discovery toolset each have their own governed tool surface, exposed through a Model Context Protocol interface.
• 130 REST endpoints across 20 modules — live positions, spatial queries, navigation, ETL, documents and AI sessions, with a query language of 20+ operators.
• WebSocket streaming — live position and zone-event channels for real-time views.

These are the connectors the agentic harness uses to reach your floor — supporting detail, not the headline. The headline is the harness itself: scalable, secured and model-agnostic.

Agents run on live RTLS data — shipped, not slideware — each pairing a plain-language front-end with a real engine, ordered here by how broadly they help end users:

• RTLS AI Assistant: the broadest entry point — just ask about your floor in plain language for analytics, navigation, value stream mapping and physical actions. Ask "show me every container stuck more than 2 hours" and get an answer with an interactive map and clickable deep links.
• Rule Agent ↔ NLP rule engine: describe a monitoring rule in plain language. The agent converts it to a validated json-rules-engine rule and tests it through up to five automatic refine-and-retest passes before you publish.
• Dashboard Copilot ↔ analytics: describe a chart or variable in plain language; the agent proposes it, you preview and confirm before it is applied.
• Script Agent ↔ safe real-time script engine: the deepest, most technical layer — a safe, sandboxed scripting engine for processing RTLS events in real time, with a specialized coding agent that writes and tests the scripts for you. Every change is validated, fixture-tested, and only goes live after you approve it.

All run on your existing Ubudu RTLS infrastructure — no hardware changes if you already run Ubudu BLE/UWB tags. See the Agents page for each agent in depth.

The Rule Agent lets an operations team author monitoring rules without writing JSON:

1. Describe: type the rule in natural language, e.g. "Alert maintenance if a forklift battery drops below 20% in the charging zone."
2. Generate: the agent writes a validated json-rules-engine rule with the right facts, operators and action handlers.
3. Test: it auto-generates test scenarios covering edge cases (battery exactly 20%, forklift leaving the zone).
4. Deploy: one-click activation pushes the rule to production with full audit logging.

Impact: rule creation drops from hours to seconds, with fewer configuration errors because the agent handles syntax and validation. In internal testing this is roughly 90% faster than authoring rules by hand.

Yes. The Rule Agent turns a plain-language description into a validated, executable geofence or zone rule — no JSON or SQL.

Describe it the way you'd say it: “alert maintenance if a forklift battery drops below 20% in the charging zone,” or “notify me when a pallet leaves the cold zone for more than 10 minutes.” The agent watches zone entry and exit and dwell thresholds, auto-generates test scenarios, refines through up to five retest passes, and deploys with one click and full audit logging.

Geofences that used to be integrator work become something an operations team sets up in plain language in under a minute.

These are two of the four shipped agents, each pairing a plain-language front-end with a real engine:

• Script Agent — safe, sandboxed real-time scripting. The deepest, most technical layer: a sandboxed script engine for processing RTLS events in real time, with a coding agent that writes and tests the scripts for you. Every change is validated, fixture-tested, and only goes live after you approve it — so nothing untested reaches production.
• Dashboard Copilot — conversational analytics. Describe a chart or variable in plain language; the copilot proposes it, you preview it, and nothing is applied until you confirm.

Both run under the same human-in-the-loop, audit-trailed governance as the other agents. See the Agents page for each in depth.

The AI Assistant gives conversational access to your RTLS data through the governed tool interface — part of 44 tools across three agents — covering several categories:

• Discovery & search: "How many assets do we have?" "Find all wheelchairs on floor 3."
• Analytics & patterns: "Show dwell-time patterns this week." "Which zones are bottlenecks?"
• Route optimization: "Fastest route to pick up these 5 containers" — multi-stop solving with accessible-path options.
• Value stream mapping: "Generate a VSM for assembly line B over 30 days" produces flow, cycle-time and bottleneck analysis as a dashboard artifact.
• Value-at-stake scenarios: "If each container is worth €20,000, what's the exposure from current bottlenecks?" frames a financial scenario from real dwell data.
• Actions: results include clickable deep links that drive the RTLS UI — highlight assets, apply filters, trigger pick-to-light.

Data-grounded: every number comes from live RTLS through the MCP tools, with field-name validation — not from the model's memory.

Value stream mapping visualises how materials and information flow through a process, exposing waste and bottlenecks. Done by hand it takes weeks of observation. Ask the AI Assistant instead:

• "Do a complete VSM for our container flow, highlighting bottlenecks over the last 20 days."

The Assistant reads your RTLS history through the MCP tools and assembles a dashboard artifact with:

• Flow diagrams — material movement between zones;
• Cycle-time analysis — average, min and max time per zone;
• Bottleneck identification — zones where assets dwell disproportionately;
• Throughput trends — daily and weekly peaks and troughs;
• Worst-day analysis — anomalous days flagged for root-cause review.

The VSM is produced as an agent-generated analysis artifact, grounded in your live data — minutes instead of weeks.

Deep links close the gap between an insight and an action. When the agent finds an issue, it returns a shareable, user-confirmed link that drives the RTLS UI:

• Map selection: "45 containers stuck in zone B3" → "View on map" zooms to B3 with those containers highlighted.
• Pick-to-light: "Container #4521 needs attention" → "Locate" turns that tag's LED on to guide an operator.
• Filter application: "Show low-battery assets" applies the filter automatically.
• Navigation: "Route to container" launches turn-by-turn indoor navigation.

Each link is auditable, so "knowing" becomes "doing" in one confirmed click.

The Assistant auto-routes each query to one of three thinking modes by complexity:

• Quick: simple lookups — "How many forklifts do we have?" "Where is asset #1234?"
• Standard: analysis — "Show zone-occupancy trends." "Which assets haven't moved in 4 hours?"
• Deep: multi-step reasoning — VSM generation, value-at-stake scenarios, multi-stop route optimization.

Most everyday queries resolve in Quick or Standard, with Deep reserved for multi-step reasoning — balancing cost against response time. These are routing tiers, not contractual latency guarantees.

Every answer is traceable back to its source, so you never have to take a figure on trust:

• Show the query — tool-transparency chips in the UI reveal exactly which governed tools the agent called and what live data came back.
• Cross-check the numbers — because outputs are data-grounded, you can reconcile any reported figure against the raw RTLS data and the REST API directly.
• Audit the trail — every step, action and acknowledgement is written to an append-only audit trail.

This is the verification path: the agent doesn't just give an answer, it shows its working — what it read and how it got there.

No system is infallible, so the design assumes the model can err and keeps a human in control of anything physical:

• Confirmation before action — under human-in-the-loop, an ESL, lock or pick-to-light change is a proposal the operator must Apply or Skip; it never fires unattended.
• Reversibility — a confirmed physical action can be reversed by issuing the inverse action down the same governed path (restore the previous ESL content, unlock, turn the LED off), each logged in turn.
• Failure handling — the write-path uses correlation IDs, acknowledgement, retry and timeout, so a failed or unacknowledged action is visible rather than silently lost.

A reasoning mistake is caught at the confirmation step before it reaches the floor — the agent proposes, a human decides.

The RTLS interface and the conversational AI Assistant are web-based and responsive, so operators reach them from a phone or tablet browser on the shop floor without installing anything. Deep links — "View on map", "Locate", "Trigger pick-to-light" — are shareable URLs that open directly on a handheld.

There is no separate native mobile app today; access is through the responsive web UI and the underlying REST/MCP surfaces, which integrators can also embed in their own handheld tools.

RTLS alone gives you location data — and data isn't insight. You get coordinates, zone events and timestamps, and making sense of them takes:

• SQL queries or BI dashboards (technical barrier);
• domain expertise to read the patterns (knowledge barrier);
• someone watching the dashboard (attention barrier);
• custom development to automate a response (cost barrier).

A general AI alone can reason and write, but it is blind to your floor — it cannot tell you where your forklifts are or why zone B3 is a bottleneck.

Together they produce spatial AI: an agent that perceives verified position, reasons over it through governed MCP tools, and acts in physical space. Most RTLS platforms see the floor; this one acts on it.

You can connect any of those models — but a bare model hits four walls without our tools:

• No data access: a bare LLM can't query your RTLS database; pasting data into prompts is manual and doesn't scale.
• No real time: "Where is forklift FL-07 right now?" needs a live position read, not a static chat.
• No actions: a model can suggest "alert maintenance" but can't send the alert, turn a pick-to-light LED, or update your WMS.
• No grounding: without governed tools, figures can drift from reality.

What Ubudu adds: 44 governed tools across three agents that give the model real-time, read-only access to verified position and a controlled set of actions. The model orchestrates; the data and the write-path stay governed.

Location data is high-volume, high-velocity and spatially complex:

• Volume: a busy facility generates a continuous stream of position updates; raw scans are impractical, so the platform pre-computes aggregations.
• Velocity: positions update every few seconds, so analysis works over streaming data, not just snapshots.
• Spatial semantics: "in zone B3" differs from "3 m from the B3 boundary"; containment, proximity and pathing need geometric reasoning. Ubudu's spatial core runs 6.6M distance operations and 4M point-in-polygon operations per second.
• Temporal context: a forklift parked overnight is fine; the same dwell at 10 a.m. is a problem.

The MCP tools absorb this complexity, so "which zones are bottlenecks?" queries pre-computed dwell statistics rather than raw coordinates.

The "last mile" problem: RTLS infrastructure is a real investment — anchors, tags, calibration — and value often stalls at "we can see dots on a map." The gap has three parts: extracting insight needs technical skill; acting on it means switching systems; automating it means custom development.

Spatial AI closes it on three fronts:

• Natural-language access — ask questions, get grounded answers, no SQL.
• Deep links and closed-loop action — responses carry confirmed actions: "View on map," "Trigger pick-to-light."
• Rule generation in plain language — describe the automation; the agent builds, tests and deploys it.

That turns the RTLS investment from infrastructure you watch into a system that acts.

Operations teams — author monitoring rules without an IT cycle; generate value stream maps in minutes; surface bottlenecks and missing assets on demand.

Developers & integrators — 44 governed tools across three agents plus a typed SDK; build custom agents that combine RTLS with your business logic; expose your own systems as MCP tools.

Technical buyers — a deployment spectrum from cloud to on-premise, multi-technology BLE/UWB/GNSS positioning, and EU data sovereignty.

AI specialists — a model-agnostic stack, governed agentic patterns, and a custom-agent path over the MCP server.

Most "AI in software" is a chat box confined to the digital realm. Spatial AI connects the model to the physical world:

• Physical awareness — the agent knows where things are right now from multi-technology positioning, not just what's in a table.
• Closed-loop action — a response can update an ESL label, turn a pick-to-light LED, or drive a lock, then log the acknowledgement.
• Physical context — "stuck" means different things in a warehouse, a hospital and a factory; domain semantics matter.

This is the perceive → reason → act loop, deployed as code with version numbers and audit trails.

The MCP server connects with any MCP-compatible client or tool-calling framework, including:

Assistants & copilots:

• Claude (Anthropic) — Claude Desktop, Claude Code, Claude API;
• GPT-5 (OpenAI) — via function calling, one option in the model menu;
• Gemini (Google) — via function declarations;
• Cursor and Windsurf — MCP-capable editors.

Agent frameworks:

• LangChain / LangGraph — via MCP adapters;
• CrewAI — multi-agent orchestration;
• AutoGen — conversational agents;
• LlamaIndex — data framework for LLM apps.

Workflow automation: n8n and other MCP-aware tools.

Why MCP matters: connect once and work across clients, because MCP is a universal protocol — not a per-vendor integration. See the Developer page for setup details.

Dashboards inform; agents act. The difference:

Example: a forklift battery falls to 15%. Dashboard world: maybe someone notices on the next refresh. Agent world: the rule fires, the nearest replacement's pick-to-light LED turns on, and the action is logged with its transmission time.

No. Agents complement your stack rather than replacing it:

• Power BI / Tableau: keep your executive dashboards; agents feed them pre-analysed data.
• MES / WMS / ERP: agents read and trigger workflows through your existing APIs.
• Slack / Teams / email: agents post alerts and digests where your team already works.
• Data warehouses: agents can populate marts for historical reporting.

Think of agents as the first-responder layer for live operations, while BI tools keep providing strategic oversight.

A plain rule is if-then: "If battery < 20%, alert." Deterministic and reliable — and exactly what the Rule Agent generates and the engine executes.

The agent layer adds reasoning on top, within bounded autonomy:

• Context: "Battery is low, but it's 6 p.m. and this forklift isn't scheduled until tomorrow."
• Pattern recognition: "Three low-battery events this week — flag for maintenance review."
• Natural language: operators can ask "why did this alert fire?" and get an explanation.

The agent reasons over and configures the rules; the deterministic engine still does the firing.

Model Context Protocol (MCP) is an open standard — now under the Linux Foundation — for connecting AI agents to data and tools. Think of it as a universal plug: the model calls pre-defined tools that execute server-side, rather than touching your database directly.

Why MCP over hand-wiring each model to a REST API:

• Unified interface: resources, tools and prompts share one specification.
• Governed access: the model only ever sees the question, the tool descriptions and the tool results — execution stays under your control.
• Discovery: an agent can ask "what can you do?" and get structured capability descriptions.
• Portability: connect once, work across MCP-compatible clients.

Ubudu's MCP interface exposes 44 governed tools across three agents, so any MCP-compatible agent can reason over verified location.

There are 44 governed tools across three agents (the Dashboard Copilot, the Script Agent and the RTLS discovery toolset). The RTLS discovery tools fall into several categories — for example:

• Discovery: rtls_discover_system, rtls_get_data_model, rtls_get_field_info.
• Venue: rtls_get_venue_geometries, rtls_find_zone_at_point.
• Asset: rtls_list_assets, rtls_search_assets, rtls_get_asset.
• Zone: rtls_get_zone_presence, rtls_get_zone_history.
• Navigation: rtls_navigate_shortest, rtls_navigate_accessible, rtls_optimize_multi_stop.
• Real-time: rtls_get_current_positions, rtls_find_nearest_assets_realtime.
• Spatial: rtls_analyze_custom_zones, rtls_find_pois_in_radius, rtls_calculate_zone_distances.

Each tool ships with a schema, examples and error handling. Per-property LLM-Enabled toggles let you control exactly which fields a tool can expose to the model.

The architecture makes outputs data-grounded rather than relying on the model's memory:

• Numbers are read, not guessed: every figure the agent reports comes back from a governed MCP tool that queried live RTLS.
• Field-name validation: references are matched against your real data model with confidence thresholds before a tool runs, catching typos and invented fields.
• Scoped access: each query is bounded by API key, namespace and the per-property LLM-Enabled toggles you configure.
• Tested generators: rule generation is tested and validated (66/66 generation tests pass).

No system is infallible — reasoning can still err — which is why actions run with human-in-the-loop confirmation and a full audit trail rather than as unattended autonomy.

This is the rare RTLS write-path: most platforms stop at the dashboard. When a condition fires, the same located tag acts:

• ESL displays: update an electronic shelf label's content — price, instruction or status.
• Pick-to-light: turn a tag's LED a chosen colour for a set duration (1–3,600 seconds) to guide an operator.
• Locks & access: drive electronic locks from the same governed action path.

The ESL Synchronizer sends each action with an externalEventId, waits for acknowledgement, and logs the full lifecycle to a tamper-evident store — e.g. Update SUCCESS — transmission 354 ms, elapsed 13.2 s — with retry and timeout handling. Every action is correlated, acknowledged and audited.

BLE 5.4 PAwR (Periodic Advertising with Responses) is the bidirectional RF mechanism that makes located tags natively actionable — efficient one-to-many broadcast with a response channel, at low power.

BLE 5.4 PAwR powers bidirectional, actionable tags across our UWB/BLE product line. Our multi-technology tags use BLE 5.4 PAwR to drive the closed-loop write-path:

• ESL displays: update an electronic shelf label's price, instruction or status.
• Pick-to-light: turn a tag's LED a chosen colour to guide an operator.
• Locks & access: drive electronic locks from the same governed action path.

The acknowledgement channel is correlated and audited, so every physical action issued over PAwR returns a confirmed result with its transmission time.

One platform ingests 8 positioning technologies through a single origin-algorithm map, badged in the UI so you always know the source of truth:

• BLE and BLE Attractor — zone and proximity-grade Bluetooth Low Energy;
• UWB TWR and UWB TDoA — ultra-wideband for precise positioning;
• BLE Presence — presence/contact detection;
• Declared — manually declared locations;
• AoA — angle-of-arrival;
• GPS — outdoor/GNSS positioning.

Tags can be BLE, UWB or hybrid. This multi-technology perception layer, combined with the closed-loop write-path, is the differentiator: the platform both senses and acts. For the accuracy and cost trade-off between these technologies, see how accurate the positioning is.

Yes. GNSS/GPS covers the outdoor yard and the transitions where indoor anchors don't reach, and it is one of the 8 positioning technologies fused in the single ILS solver — so an asset moving from a building into the yard stays tracked under one platform, not two disconnected systems.

Each position is badged in the UI by its origin algorithm, so you always know whether a fix came from indoor UWB/BLE or outdoor GNSS. You mix tiers by zone: the yard on GNSS, precision-critical indoor zones on UWB, dwell and presence zones on BLE.

The ILS engine is the heart of the platform: a C++ multi-hybrid RF RTLS solver — unique in the market for its completeness, and proven at scale across thousands of deployments. It turns raw radio from many technologies into verified, continuous position.

Under the hood it runs advanced positioning math across 100+ tunable parameters:

• Multi-technology RF fusion — combining BLE, UWB and GNSS in a single solver;
• Map-matching — constraining position to the real geometry of your floor;
• Particle filtering and Kalman fusion — for smooth, robust tracking in noisy environments;
• plus filtering and smoothing tuned per zone, per technology and per use case.

This is the depth that makes Spatial AI meaningful here: the AI agents are not a chatbot bolted onto a tracker — they sit on top of a serious positioning engine and an open API. The upcoming ILS Engine Configurator agent will make tuning these parameters conversational, so non-experts get expert-grade configuration. (The engine’s internal algorithms are proprietary; we describe what it does, not how the math works.)

Tuning a multi-technology RF deployment for good accuracy has always taken deep RF expertise — and that expertise barrier is one of the real reasons accurate indoor location is hard to adopt at scale.

Ubudu lowers that barrier in two ways:

• Today, Ubudu engineers tune the ILS engine for your site as part of deployment — the 100+ tunable parameters across map-matching, particle filtering and BLE/UWB/GNSS fusion are configured for you against a site survey.
• Next (H2 2026), the ILS Engine Configurator agent makes that tuning conversational: you describe the deployment goal in plain language and review a proposed configuration, so a non-specialist gets expert-grade tuning of the positioning engine itself.

This is the deepest expression of Spatial AI: the AI acts on the positioning engine, not just on top of it — improving how the floor is sensed, not only how it is queried. (The engine’s algorithms stay proprietary; we describe what the tuning achieves, not how the math works.)

The ILS Engine Configurator is an upcoming agent (H2 2026) that brings the plain-language agent pattern down to the positioning engine itself.

Instead of an RF expert hand-editing 100+ parameters across map-matching, particle filtering, Kalman fusion and multi-technology RF fusion, you describe the deployment goal in plain language (for example, “positions drift in the high-bay aisle”) and review a proposed, tuned configuration before it is applied.

It is the deepest layer of Spatial AI — the AI improves how the floor is sensed, not just how it is queried — and it tunes the same C++ multi-hybrid RF solver proven across deployments. The engine’s internal math remains proprietary; the agent guides what to tune, not how the algorithms work.

Three levers, not one:

• Technology tier per zone — UWB, BLE AoA or zone-grade BLE, chosen where precision earns its place.
• Anchor density — set by a site survey for each zone.
• ILS engine tuning — how the positioning engine is tuned to your specific RF environment, which is what adapts the published accuracy tiers to a real, noisy floor.

Ubudu handles the engine tuning today, and the ILS Engine Configurator will make it conversational. The achievable tiers come from real deployments and are validated by site survey — a per-zone design target, not a contractual guarantee.

Three layers, cleanly separated, all sitting on the spatial foundation:

• Agentic harness — the scalable, secured policy layer: isolated per-user sessions, JWT + API key + namespace scoping, governed tool access, human-in-the-loop and the audit trail. It reaches the foundation through a governed MCP interface. Reused identically across every deployment.
• Inference provider — where the model runs: a managed cloud, a sovereign cloud, or your own infrastructure.
• Model — swappable by configuration, cloud or open-weight.

Because the harness is the constant, swapping the model or moving the inference closer to your data is a config change, not a rebuild. The MCP server is how the harness reaches your floor — a governed connector, not the asset. The model only ever sees the question, the tool descriptions and the tool results — your database stays on your infrastructure.

You choose accuracy per use case across the 8 fused positioning technologies — there is no single right answer, only the right tier for each zone:

• UWB (TWR / TDoA) — roughly 10–50 cm, for high-value or safety-critical tracking where precision matters most.
• BLE AoA — sub-meter angle-of-arrival, a middle tier balancing precision and infrastructure cost.
• BLE zone / proximity — about 1–5 m, the most cost-effective option for dwell, presence and zone analytics.
• GNSS / GPS — outdoor yard and transitions, where indoor anchors don't reach.

Because tags can be BLE, UWB or hybrid, one platform mixes precision tiers by zone rather than forcing a single technology everywhere — you pay for centimetre accuracy only where you need it.

Accuracy is a per-zone design choice, not a single guaranteed number. As a guide: UWB roughly 10–50 cm, BLE AoA sub-meter, BLE zone/proximity about 1–5 m — so you mix tiers by zone and pay for centimetre precision only where it earns its place.

The figure you actually achieve depends on the three levers: technology tier, anchor density, and how the ILS engine is tuned to your RF environment. It's validated by a site survey rather than asserted up front.

These are achievable tiers from real deployments, not a contractual guarantee — the per-zone target is agreed during design, the same way update rate is.

Anchor density is set by a site survey, not a fixed rule of thumb. The main drivers are:

• Coverage — the area and the obstacles (racking, walls, mezzanines) that block RF.
• Accuracy tier — centimetre UWB needs at least three to four anchors in view for trilateration; zone-grade BLE needs far fewer.
• Use case — safety-critical tracking warrants denser placement than presence detection.

If Ubudu positioning infrastructure already exists at your site, there is no rip-and-replace — the agents and actions run on it as-is.

Steel racking, forklifts, concrete and dense Wi-Fi all create multipath and interference. The platform handles them on two fronts:

• Technology choice — UWB time-based ranging is inherently more resilient to multipath than signal-strength methods, which is why it is used where the RF environment is harsh.
• Site survey & placement — anchor positioning is tuned to the physical layout so high-bay and metal-heavy areas keep enough anchors in line of sight.

The origin-algorithm badge in the UI always shows which technology produced a given position, so the source of truth stays visible in difficult areas.

The position refresh rate is configurable per tag and use case: a fast-moving forklift can report more frequently than a slowly moving pallet, trading battery life against freshness. Live positions and zone events stream over WebSocket for real-time views, and the API layer is built to handle 100,000+ positions per second. These are engineering capabilities, not contractual latency guarantees.

BLE 5.4 PAwR drives the actionable tags, ESL displays, pick-to-light LEDs and electronic locks across Ubudu's own UWB/BLE product line — that closed-loop write-path is a native capability of the Ubudu multi-technology tags, available today.

Third-party device support is scoped per project rather than claimed as a blanket compatibility list: if a device exposes an API, it can typically be driven through the same governed action path, but we describe Ubudu's own hardware capability and validate specific third-party SKUs during scoping rather than asserting them up front.

Battery life depends on the technology and the configured update rate. BLE coin-cell tags running at moderate refresh rates last for years, while active UWB tags and high-frequency reporting draw more power and need more frequent replacement. The configurable update rate is the main lever: slower reporting on rarely-moving assets extends life.

At scale, replacement is a logistics exercise — battery-level is itself a tracked field, so a plain-language Rule Agent rule can flag low-battery tags before they go dark. This battery profile is a real factor in total cost of ownership.

If you already run Ubudu BLE or UWB tags and anchors, the agents and physical actions run on that same infrastructure — no rip-and-replace. New sites need the positioning layer deployed first, and that choice is really an accuracy-and-coverage decision:

• Accuracy tier — pick the precision per zone; see BLE vs UWB vs GNSS accuracy.
• Anchor density — a site survey sets how many anchors and where; see anchors and spacing.
• Actionable tags — BLE 5.4 PAwR powers the bidirectional tags across our UWB/BLE product line, driving ESL, pick-to-light and locks with acknowledgement.

Four well-defined surfaces over the same governed RTLS data:

• REST API: language-agnostic HTTP access across 130 endpoints in 20 modules, with universal filtering (20+ operators, nested fields, ranges). An OpenAPI spec is published for code generation.
• TypeScript/JavaScript SDK: ubudu-rtls-sdk (v0.1.1) — 8 resource classes (assets, positions, zones, venues, spatial, alerts, dashboards, navigation), a fluent filter DSL, async iterators and a typed error hierarchy. Node 18+.
• MCP interface: 44 governed tools across three agents for any MCP-compatible agent — the surface for AI assistants and custom agents.
• WebSocket: a single shared connection streams live positions and zone events for real-time views.

The SDK is TypeScript/JavaScript today; any other language integrates over the REST API. No rip-and-replace of your MES, WMS or EHR.

Because MCP is a two-way standard, you can expose your own systems as tools an agent can call alongside Ubudu's. A minimal MCP resource looks like this:

@mcp.resource("erp://orders/{order_id}")
async def get_order(order_id: str):
    return await your_erp.fetch_order(order_id)

Once registered, agents discover it through the capability handshake — no hard-coded endpoints. Common integrations: ERP order status, MES work orders, WMS inventory, CMMS maintenance history. If it has an API, it can become an MCP tool that composes with Ubudu's governed RTLS tools.

Yes — the stack is model-agnostic, and the menu is deliberately broad:

• Cloud / frontier: Claude, GPT-5, Gemini, or any OpenAI-compatible endpoint.
• Open-weight / on-premise: Mistral, Llama, Qwen, DeepSeek, Kimi, MiniMax — ideal for EU data sovereignty, since data and inference stay local.

Switching providers is a configuration change, not a redeploy — the harness stays the same. We never run on only one model.

Yes. The build-your-own-agent path composes two production surfaces:

• the governed MCP interface (44 tools across three agents) for perception and governed actions, and
• the natural-language rule generator for monitoring logic.

Connect from any MCP-compatible client — Claude Desktop, Claude Code, Cursor, Windsurf, n8n, LangChain, LangGraph, CrewAI, AutoGen or LlamaIndex — or call the REST API and SDK directly. A drag-and-drop visual Agent Builder for composing custom agents is next on the roadmap; today you compose agents through rule generation plus direct MCP/SDK integration.

Through your data model and rules, not code:

• Custom taxonomy: define asset types — forklifts, wheelchairs, containers — with your own properties.
• Zone semantics: mark zones as production, storage or restricted with industry-specific meaning.
• Business rules: "Cold-chain assets must not leave the chilled zone for more than 15 minutes."

The Rule Agent reads your custom fields automatically: say "alert if a wheelchair's battery is below 30%" and it resolves "wheelchair" from your taxonomy.

The same agent harness runs across a deployment spectrum of six options, so you choose by your sovereignty and latency needs rather than rewriting anything:

1. Managed cloud API — fastest to start.
2. AWS Bedrock — within your AWS account.
3. Google Vertex AI — within your Google Cloud.
4. Azure — within your Azure tenant.
5. EU sovereign cloud — data and inference kept in-region.
6. On-premise / air-gapped — open-weight model on your own infrastructure; nothing leaves your network.

Moving along the spectrum is a configuration change — the MCP harness, tools and audit trail are identical at every point.

The architecture is built so European operations can keep data and inference local, and is aligned with GDPR and the EU AI Act:

• Data stays local: with an open-weight model on-premise or in an EU sovereign cloud, RTLS data and inference both stay in-region. The model only sees the question, the tool descriptions and the tool results — your database remains on your infrastructure.
• GDPR: EU regions and on-premise deployment support data-residency and minimisation requirements; access is scoped and audited.
• EU AI Act: operational analytics agents of this kind are not high-risk systems under the Act. We design to align with it; we don't claim certification, and we don't publish a hard enforcement date here because the regulatory schedule is still settling.

For regulated industries, the on-premise open-weight path gives full control with no external data transfer. A Data Processing Agreement is available, defined per contract — see certifications and DPA — and for staff-identifiable tracking, see worker privacy and works-council concerns.

In transit: REST, WebSocket and MCP connections are encrypted with modern TLS. At rest: position history, asset metadata and audit logs are encrypted in storage.

Access: each agent session is isolated and scoped by API key, namespace and role. Sessions are cleaned up after use, and by default the AI keeps no persistent storage of your data. The per-property LLM-Enabled toggles let you decide exactly which fields a model may ever see.

Position history, asset metadata and the append-only audit trail are stored on your infrastructure or your chosen region — retention windows are configured per deployment, not fixed by us.

Agent sessions are isolated and ephemeral: by default the AI keeps no persistent copy of your data once a session ends. Because the data lives in your environment — especially on on-premise or EU sovereign cloud deployments — erasure and GDPR data-subject requests stay under your control, and the audit trail documents exactly what was accessed.

Specific retention periods and deletion procedures are agreed in the Data Processing Agreement.

Agents run under bounded autonomy with a human in the loop, and every step is recorded:

• Perceive: which tools the agent called and what live data they returned (tool-transparency chips show this in the UI).
• Reason: which thinking mode resolved the query and the proposed action.
• Act: the physical action, correlated by externalEventId, with its acknowledgement and transmission time appended to an append-only log.

Physical actions are user-confirmed deep links, not unattended commands, so the system never acts beyond the bounds you set — and you can always trace exactly what happened.

The deterministic rule engine and the positioning layer keep running locally, so safety-critical monitoring continues even if the conversational AI is temporarily unreachable:

• Local rule firing — rules execute at the edge on live RTLS, independent of any cloud LLM.
• Buffering & sync — events are buffered while the link is down and, when connectivity returns, sync with history preserved.
• Queued physical actions — an ESL or pick-to-light action issued over BLE 5.4 PAwR is correlated and acknowledged, so it confirms once the link is restored rather than being lost.

The agentic features (natural-language queries, VSM generation) resume when connectivity is back; rule firing never depended on them.

The known MCP threat classes are addressed by design rather than left to the model's good behaviour:

• Tool poisoning — only pre-defined, server-side tools exist; the model cannot register or alter a tool, it can only call what the governed interface exposes.
• Prompt injection — untrusted content is wrapped and escaped, and any mutation is a human-in-the-loop proposal an operator must approve, so an injected instruction can't silently act.
• Over-privileged tools — per-property LLM-Enabled toggles plus namespace and API-key scoping mean each tool sees only the fields and data you allow.
• Credential exposure — tools call back as the user under their own key; the model only ever sees the question, the tool descriptions and the tool results, never your database or credentials.

Every call is recorded in the audit trail, so misuse is traceable.

We state our position honestly rather than over-claim. The architecture is aligned with GDPR and the EU AI Act, and a Data Processing Agreement (DPA) is available, defined per contract.

For formal certifications such as SOC 2, ISO 27001 or HIPAA, current certification status is confirmed per engagement — we don't assert a certification we haven't earned. For the strictest requirements, the on-premise open-weight path keeps data and inference entirely within your own controlled environment, which is often the most direct route to satisfying an internal compliance regime.

Most industrial deployments track assets — forklifts, tools, containers — not people, which sidesteps much of the concern. Where staff-identifiable tracking is in scope in an EU setting, the posture is built for it:

• Data minimisation & scoping — the per-property LLM-Enabled toggles and namespace scoping let you keep person-identifiable fields out of the model's reach entirely.
• Local processing — on-premise or EU sovereign deployment keeps any people data in-region.
• Works-council alignment — GDPR data-residency and minimisation support the consultation and transparency that European works councils expect; the audit trail documents what is accessed.

Specifics are agreed per deployment with your data-protection and works-council stakeholders.

A typical adoption path runs in three phases:

1. Sandbox — access against your RTLS data, with first AI queries working (often days).
2. Pilot — a zone-level pilot covering two or three use cases such as battery alerts and bottleneck detection (commonly a few weeks).
3. Rollout — site-wide rollout, an expanded rule library, and team training (commonly a few months for a full site).

Those ranges are typical rather than contractual — the pace depends on your environment. Prerequisite: an existing Ubudu RTLS installation; a greenfield site needs the positioning layer deployed first, with anchor density set by a site survey. We sequence by milestone, not a fixed calendar.

The agent layer, the closed-loop physical actions and BLE 5.4 PAwR are capabilities of Ubudu's own positioning hardware, so the verified-position and write-path features run on Ubudu BLE/UWB infrastructure rather than a third-party anchor network.

What you do not replace is your business stack: MES, WMS, EHR and BI systems integrate over REST, SDK and MCP with no rip-and-replace.

A typical migration is phased rather than a single cut-over: a sandbox plus a zone-level pilot on a Ubudu-instrumented area, prove the value, then expand site-wide — anchor density and tier set by a site survey per zone. We don't claim drop-in compatibility with another vendor's anchors or tags; the migration replaces the positioning layer where you want Ubudu's accuracy and write-path, on your timeline.

We frame ROI honestly, as illustrative scenarios from customer deployments rather than guarantees, grouped by benefit category:

• Search time — asset finding around 70% faster in customer deployments; in one scenario a tool search dropped from 18 minutes to about 4.
• Downtime — faster response to battery, bottleneck and dwell breaches via plain-language rules, so problems are caught before they stop a line.
• Shrinkage & loss — faster recovery of misplaced high-value assets shortens the window in which they go missing.
• Rule creation — from hours to seconds, roughly 90% faster in internal testing.

Payback sits in an illustrative 6–16 month range, depending on facility size and use case. Value at stake is often the clearest lens: if a misplaced container is worth €20,000, finding it in minutes instead of hours has an obvious value, and the AI Assistant can model these scenarios from your live dwell data. See total cost of ownership for the cost side. These figures are illustrative, not promised outcomes.

Pricing follows a tailored subscription model — there is no public price list — shaped by these factors:

• Asset count — number of tracked tags (a per-tag dimension);
• Interaction volume — AI queries per month;
• Active rules — concurrent automations;
• Deployment model — cloud, hybrid or on-premise;
• Support tier — response times and coverage.

The agent layer reuses your existing Ubudu RTLS infrastructure, so there's no rip-and-replace cost — see total cost of ownership. We run pilots to demonstrate value first. Contact our team for a tailored quote.

Onboarding: a kickoff workshop covering architecture and first rules, a hands-on sandbox session with your own RTLS data, and a template library for your industry.

Ongoing support: tiered from standard (knowledge base and email) through premium (a named success contact and quarterly reviews) to enterprise (extended coverage and custom integrations).

A traditional RTLS platform gives you location data and dashboards — dots on a map and reports you have to read and act on yourself. The differentiator here is the layer on top:

• Spatial AI, not just positioning — the agents perceive, reason and act, so insight turns into action instead of another dashboard to watch.
• Governed agents — plain-language rules, conversational analytics and a closed-loop write-path, all under bounded autonomy.
• Same infrastructure — it runs on Ubudu positioning you may already have; the AI is the easy front-end to power that was already there.

Most RTLS platforms see the floor; this one acts on it.

Yes. Namespace scoping isolates each site or tenant: tools are called as the user under their own API key and role, so one site's data stays separate from another's, while fleet-wide and central reporting roll up across the whole estate. The same agent harness and governed tools run identically at every site, which makes enterprise multi-site rollout a configuration exercise rather than a rebuild per location.

The platform is built for real industrial scale, and the engineering numbers translate into buyer-facing headroom:

• Positions — the API layer is built to handle 100,000+ positions per second, with Redis multi-instance scaling.
• Zones — the spatial core searches 10,000 zones in under 5 ms, so zone-rich venues stay responsive.
• Sites — namespace scoping extends the same harness across many sites under one estate.

Practical ceilings depend on your deployment and hardware sizing; these figures show the architecture carries large, busy facilities rather than a single-room pilot.

Total cost of ownership over a 3–5 year horizon has the same components as any RTLS deployment — tags, anchors, the site survey, software, batteries and support — and the AI agent layer is added value on top of that, not a separate hardware stack.

Where it changes the equation: the agents reuse your existing Ubudu positioning infrastructure, so there is no rip-and-replace. Mixing precision tiers by zone means you pay for centimetre UWB only where it earns its place. See pricing for the commercial model.

A typical rollout touches a handful of stakeholders:

• IT / OT — network, deployment model and integration with MES, WMS or ERP.
• Security & compliance — sign-off on data residency, scoping and the DPA.
• Operations — the people who will author rules and act on alerts, and whose adoption decides the outcome.

Operator adoption is light because the interface is plain language, not JSON or SQL — which is the point of the AI front-end. We support the rollout with onboarding workshops and a sandbox on your own data.

The conversational agents incur per-query inference cost that scales with how much your team uses them, which is why interaction volume is a pricing factor. Two levers keep it predictable:

• Thinking-mode routing — most queries resolve in the lighter Quick or Standard modes, reserving heavier Deep reasoning for the queries that need it.
• On-prem open-weight models — running a self-hosted open-weight model converts per-token cloud cost into fixed infrastructure cost, and keeps data local for sovereignty.

The deterministic rule engine and positioning layer don't call an LLM at all, so safety-critical monitoring carries no per-query cost.

Warehousing and logistics are the densest fit for spatial AI for warehouse and logistics operations — high asset counts, constant movement, and money tied up in dwell:

• Container & pallet dwell — ask the RTLS AI Assistant "show me every container stuck more than 2 hours" and get an answer with an interactive map and clickable deep links.
• Bottleneck detection — value stream mapping exposes where flow stalls across your zones, from live position history.
• Asset finding — locate a missing forklift or rack in seconds, then trigger pick-to-light to guide an operator straight to it.

A plain-language Rule Agent rule can watch dwell thresholds and fire automatically. See Use Cases for worked scenarios.

On the production floor the agents track work-in-progress, tools and racks, drive line-side replenishment, and tie andon signals to rules:

• WIP & tool tracking — know where every part and tool is, in real time, across the line.
• Plain-language andon — a rule like "alert if WIP exceeds 50 units in the assembly zone" can update a station ESL to HOLD and trigger pick-to-light over BLE 5.4 PAwR.
• Live supervision — the breach shows on the live map, and VSM regenerates in minutes instead of weeks.

The RTLS AI Assistant answers cycle-time and throughput questions on demand. See Use Cases.

In clinical environments the agents shorten equipment hunts and make patient and staff flow visible:

• Equipment finding — ask the RTLS AI Assistant to locate the nearest available infusion pump or wheelchair and get a map answer with turn-by-turn navigation, plus a pick-to-light LED to guide a nurse to it.
• Patient & staff flow — dwell and zone analytics surface congestion and wait points.
• Hand-hygiene & presence — zone-presence rules support hygiene and safety monitoring.

The on-premise open-weight path keeps clinical data local for the regulated environment. See Use Cases.

Retail and quick-service rely on the closed-loop write-path and zone analytics:

• ESL & pricing — push price, instruction or status to ESL displays over the governed action path, with acknowledgement.
• Pick-to-light — guide pickers and staff to the right shelf or item via a tag's LED.
• Zone analytics — footfall, dwell and queue questions answered from live position data by the RTLS AI Assistant.

BLE 5.4 PAwR makes the labels and LEDs natively actionable. See Use Cases.

Official SDK — TypeScript/JavaScript only (ubudu-rtls-sdk, v0.1.1). Types are generated from the live OpenAPI spec, with ESM and CommonJS builds, on Node 18+:

• npm: ubudu-rtls-sdk;
• Source: GitHub repository with examples.

npm install ubudu-rtls-sdk

import { createRtlsClient } from 'ubudu-rtls-sdk';

const client = createRtlsClient({
  apiKey: process.env.RTLS_API_KEY,
  namespace: 'my-app',
  venueId: 123,
});

const positions = await client.positions.listCached();

There is no Python, Java or Go SDK — any other language integrates over the language-agnostic REST API, with an OpenAPI spec for code generation.

Connect the MCP server from any MCP-compatible client — connect once, work everywhere:

• Claude Desktop / Claude Code: add the Ubudu MCP server in the client config.
• Cursor / Windsurf: register the server as an MCP source.
• LangChain / LangGraph / CrewAI / AutoGen / LlamaIndex: load the MCP tools through each framework's adapter.
• n8n: drive the tools from MCP-aware workflow nodes.

Because MCP is the integration point, the governed tools appear to each framework as native tools — no per-framework rewrite. See the Developer page for setup.

The SDK ships a fluent filter builder with 14+ operators (equals, contains, between, regex, in, exists…) and memory-efficient async iteration:

import { filters, combineFilters } from 'ubudu-rtls-sdk';

const filter = combineFilters(
  filters.equals('user_type', 'forklift'),
  filters.contains('user_name', 'warehouse')
);
const forklifts = await client.assets.list(filter);

for await (const asset of client.assets.iterate()) {
  console.log(asset.user_name);  // streams page-by-page, break early to save bandwidth
}

A typed error hierarchy (Auth, Validation, NotFound, RateLimit, Timeout, Network…) lets you catch failures granularly.

Yes — an OpenAPI reference for the 130-endpoint REST API, a catalog of the governed MCP tools with schemas and examples, and worked SDK examples in the GitHub repository. Start from the Developer page for the full set of links.

The conversational RTLS AI Assistant is built on multilingual large language models, so operators can ask questions in their own language — useful across a multinational footprint spanning Paris, Warsaw, Hong Kong and Singapore. Because the model interprets the query and the governed tools return structured data, a plain-language question works regardless of the language it's typed in.

The RTLS UI itself supports localization; the specific set of localized interface languages is confirmed per deployment.

We set out this AI roadmap at VivaTech in June 2025 and shipped against it through 2026.

Shipped:

• RTLS AI Assistant — 44 governed tools across three agents, VSM and route optimization.
• Rule Agent — natural-language rule creation, tested and validated.
• Dashboard Copilot — describe a chart in plain language, preview and apply.
• Script Agent — a safe, sandboxed real-time script engine, with the scripts written and tested for you.
• Closed-loop physical actions — ESL, pick-to-light and locks with acknowledgement and audit trail.
• BLE 5.4 PAwR hardware — bidirectional, actionable tags across our UWB/BLE product line, driving ESL, pick-to-light and locks natively.

Next on the roadmap (H2 2026):

• Knowledge Base Agent — conversational access to 10+ years of Ubudu knowledge base and platform documentation, so clients and partners get grounded answers from a decade of deployment know-how.
• ILS Engine Configurator — expert-grade tuning of your hybrid BLE/UWB deployment, made conversational: the agent guides 100+ parameters across our positioning algorithms and filters (map-matching, particle filtering, fusion) in the Ubudu ILS engine — a C++ multi-hybrid RF RTLS solver unique in the market for completeness and proven at scale.
• Visual Agent Builder — drag-and-drop composition of custom agents, no code.

MCP is an open standard, now governed under the Linux Foundation, with a public specification and a large public ecosystem of servers and clients. That openness is the point: you connect through a standard protocol, not a proprietary lock-in.

Ubudu's MCP server is proprietary because it connects to the Ubudu RTLS backend, but you reach it with standard MCP clients and the public REST API and SDK. Swap your model, change your framework, or move from cloud to on-premise — the contract stays standard.

Through the GitHub repository for public requests, your customer-success contact for prioritised input, and roadmap reviews for enterprise customers. Customer feedback shapes priorities directly.

Yes — that's the Knowledge Base Agent, the first of the next wave on the roadmap (H2 2026; the order is Knowledge Base Agent → ILS Engine Configurator → Visual Agent Builder).

It gives conversational, grounded and cited access to 10+ years of Ubudu knowledge base and platform documentation, so clients and partners can ask how to approach a use case or why the system behaves a certain way and get answers drawn from a decade of deployment experience — helping shape and optimize the technical solution rather than guessing.

Yes — integrators and partners are a core audience. Because data sovereignty is a deployment choice rather than a product fork, a partner can serve customer cloud, EU sovereign cloud or air-gapped on-premise from one codebase: the same MCP server, the same 44 governed tools and the same write-path everywhere.

Partners extend the agents into MES, WMS, EHR and SCADA via REST, SDK and MCP, and provide local support and compliance across regions. Program specifics — certification, reseller and co-development arrangements — are set up directly; contact the team to start a conversation.

Uptime targets and support response times are defined per contract and aligned with your chosen deployment model and support tier rather than published as a single blanket figure here.

Two design points are worth knowing regardless of the commercial SLA: the deterministic rule engine and positioning layer keep running locally if the conversational AI is briefly unreachable, so monitoring isn't tied to cloud availability; and an on-premise deployment puts availability under your own operational control. Concrete uptime and response-time commitments are agreed in the service agreement.