A warehouse runs on many systems at once: a warehouse management system, an ERP, a fleet of equipment reporting telemetry, safety records, demand signals and a constant flow of documents. An operator who wants a straight answer — is that forklift due for service, what should we reorder, where did the incident happen — has to cross several of them by hand.
We designed the intelligent warehouse to close that gap. It is a system that runs warehouse operations through specialized agents, real-time monitoring and a natural-language interface. This paper describes the architecture: a central orchestrator coordinating five agents, the data and integration layers underneath, and the enterprise concerns that make it safe to run in production.
1. Architecture
At the centre is the Warehouse Operational Assistant, an orchestrator. It does not answer domain questions itself. It reads the request, decides which agent or agents can serve it, routes the work, and composes the results into one reply.
Coordination runs on a workflow-orchestration graph. Each agent is a node with a clear contract; the graph carries state between nodes and lets the orchestrator fan a request out to several agents and merge their answers. Agents discover and call their tools through the Model Context Protocol, so a tool is registered once and any agent that needs it can use it without bespoke wiring.
The model layer is described by role, not by product. A primary reasoning model handles planning and multi-step queries. A smaller, faster model handles routine classification and short responses at lower cost. An embedding model powers semantic retrieval. OCR and document-extraction models turn scanned paperwork into structured data. This separation lets us send each task to the cheapest model that can do it well.
2. The five agents
Splitting the work by domain keeps each agent's tools, data access and prompts narrow. An agent that only knows equipment reasons better about equipment than a single model asked to know everything.
| Agent | Owns | Typical request |
|---|---|---|
| Equipment & Asset Operations | Assets, assignments, maintenance schedules, live telemetry | "Which forklifts are overdue for service?" |
| Operations Coordination | Task planning, workflow management, sequencing | "Plan today's picking and staffing." |
| Safety & Compliance | Safety monitoring, incident response, compliance tracking | "Log this incident and check we're compliant." |
| Forecasting | Demand forecasting, reorder recommendations, model-performance monitoring | "What do we reorder this week?" |
| Document Processing | OCR, structured extraction, document management | "Pull the line items off this delivery note." |
2.1 Equipment & Asset Operations
Tracks every asset and its assignment, holds the maintenance schedule, and reads live telemetry from the equipment. It answers status questions and flags assets that are due for service or reporting out-of-range readings.
2.2 Operations Coordination
Plans and manages work. It turns a goal into an ordered set of tasks, assigns them, and tracks the workflow to completion, taking equipment availability and staffing into account.
2.3 Safety & Compliance
Monitors safety conditions, records incidents and drives the response, and tracks compliance against the rules the site operates under. It keeps the audit trail an inspection needs.
2.4 Forecasting
Forecasts demand and turns those forecasts into concrete reorder recommendations. It also watches its own accuracy — monitoring model performance so a drifting forecast is caught rather than trusted blindly.
2.5 Document Processing
Ingests scanned and photographed paperwork, extracts structured fields with OCR and extraction models, and manages the resulting documents so their data is queryable by the other agents.
3. Conversational interface
Operators work through a natural-language interface. They ask in plain language; the orchestrator handles routing. Conversation memory carries context across turns, so a follow-up like "and the one next to it" resolves against the previous answer instead of starting over.
4. Real-time monitoring
Alongside the conversation, the system exposes live operational state: equipment status and telemetry, operational metrics, and dashboards for the floor. System-health signals sit next to the operational ones, so a stale reading is visible as a reading problem rather than mistaken for a floor problem. A metrics and observability stack collects and serves these views.
5. Enterprise security
- Authentication and role-based access. Every request is authenticated and scoped by role. Multiple roles — from floor operator to administrator — see and do only what their role allows.
- Content-safety guardrails. Inputs and generated responses pass through guardrails, so the assistant stays inside operational bounds.
- User management. Accounts, roles and access are administered in one place.
6. System integrations
The architecture assumes it lives beside existing systems, not in place of them.
| Integration | Purpose |
|---|---|
| Warehouse management system (WMS) | The system of record for inventory and movement |
| ERP | Financial and business-process data |
| IoT sensors | Live equipment and environmental telemetry |
| RFID / barcode | Item and location identity on the floor |
| Time & attendance | Staffing and labour availability for planning |
Each integration is reached through a standardized interface rather than hard-wired into an agent, so a WMS or ERP can be swapped without rewriting the agents that depend on it.
7. Data and services
An API services layer sits between the agents and everything below, exposing standardized interfaces for business logic and data access. Agents call those interfaces; they do not reach into databases directly.
Retrieval is handled by three complementary retrievers, chosen per question:
- SQL for exact operational facts — counts, schedules, assignments.
- Vector for semantic search over documents and past interactions.
- Knowledge-graph for relationships — which asset serves which zone, which part fits which machine.
Results carry an evidence score so the orchestrator can weigh how well a source actually supports the answer, and an intelligent query classifier routes each request to the right retriever and the right model in the first place.
8. Key capabilities
- Intelligent automation — agents resolve complex operational queries and drive multi-step workflows end to end.
- Real-time visibility — equipment, tasks, telemetry and safety incidents are monitored live.
- Natural-language operation — the floor is run by asking, not by navigating five consoles.
- Automated reordering — forecasts become concrete reorder recommendations.
- Caching and memory — an in-memory cache and conversation memory cut latency and keep context across a session.
- Evidence scoring and query classification — answers are grounded and routed deliberately.
- BI dashboards — operational metrics roll up for decisions above the floor.
9. Why five agents, not one
A single monolithic assistant would have to hold every tool, every data source and every rule at once. That makes it harder to reason well about any one domain, harder to secure, and harder to change: touching the forecasting logic risks the safety logic.
Splitting the work draws clean lines. Each agent owns a narrow domain, a small set of tools and a focused prompt, so it answers its own questions more accurately. Each can be tested, secured and improved on its own. And the orchestrator can still combine them — routing a single question across several agents when it needs to — without any one agent having to know everything. For operations, where correctness and auditability matter more than cleverness, that separation is the point.