DEV Community: Yash Bansal

Designing an Industrial AIoT Pipeline: Identify, Sense, Decide, Act

Yash Bansal — Tue, 29 Sep 2026 15:47:16 +0000

When developers hear "AIoT," it can be tempting to think of overlaying an AI model on IoT data

Real industrial systems are more complicated,

and an effective architecture has to be able to identify data ownership, the physical context, the information content, and what, if any, action is authorized.

Aperture Venture Studio lays out four layers of capabilities:


IDENTIFY

↓

SENSE

↓

DECIDE

↓

ACT

↓

VERIFY ↺

The first three define the AIoT foundation, while the action layer extends out into the domain of Physical AI.

1. Identify: Understanding Context

An isolated measurement without an identity can be challenging to work with.

If a sensor picks up an abnormal temperature, the system needs to be able to associate that with the asset, the location, and the relevant processes and operating context.

Identification technologies can include:

RFID

BLE

UWB

GPS/GNSS

Barcodes

RTLS technologies

By establishing the identity, location, or movement, the identification layer provides the groundwork for connecting physical observations with operational records

2. Sense: Understanding the Physical State

The next layer is concerned with capturing the physical state.

Depending on the domain, this may include:

Temperature

Pressure

Vibration

Acoustics

Electrical parameters

Flow

Level

Position

Environmental conditions

Structural measurements

The important thing is to recognize that, while we should seek to capture relevant data, the engineering question is not "How much can we measure?" but "What do we need to measure for the decisions we are trying to make?"

A well-designed sensing layer should give us valuable context rather than an overwhelming number of disconnected measurements.

3. Decide: Introducing Intelligence

The decision layer takes the parameters of the physical world and adds enterprise and operational context.

This layer might undertake tasks such as:

Anomaly detection

Forecasting

Diagnosis

Optimization

Risk prioritization

Recommendation

Aperture's AI Decision Engine works inside bounded systems, and depending on the domain and application the decisions may remain advisory, require human approval, or have rules-based pathways to an action layer.

That distinction is critically important to industrial developers since a prediction is not the same thing as a command.

4. Act: Bringing Software and Operations Together

Physical AI really begins when decisions can connect with the physical world.

An action layer could be used for:

Inform - alerts, explanations, or recommendations

Coordinate - tasks, work orders, escalations, or process changes

Assist - guidance for operators or technicians

Control - commands approved by the AIoT system

Automate - bounded physical activity within defined constraints

Coordinate autonomous systems - tasks for robots, AMRs/AGVs, drones, or other systems

This does not mean that every AI decision should have control of equipment, but industrial systems need authorization, constraints, command validation, monitoring, human override, and other measures that are appropriate to the application.

5. Verify: Closing the Loop

It's common for an architecture to stop at executing an action, but once a change has been made the system should be able to observe the new physical state.

For example:


Asset identified

↓

Condition sensed

↓

AI detects abnormal state

↓

Response approved

↓

Action executed

↓

New state measured

↓

Result verified

The verification can then feed back into the system for subsequent decisions.

Why the Layers Matter

Industrial AIoT is not a monolithic technology, but can involve:

Identification systems

Sensors

Edge layer

Enterprise layer

AI models

Industrial controls

Robotics

Operational systems

Aperture's architecture is explicitly technology-agnostic and can work with RFID, BLE, UWB, GPS, sensors, vision systems, PLCs, SCADA, edge computing, AI, robotics, and other elements in the application.

For developers, the important thing is to ground AIoT design in the physical world, and the most effective approach is to think in terms of the operational loop.

Ask:

What needs to be identified?
What needs to be measured?
What decision needs support?
What action is actually authorized?
How will the result be verified?

That gives developers a practical way to approach AIoT and Physical AI systems.

A full reference architecture is available in Aperture Venture Studio's Physical AI and AIoT architecture.

Designing an Industrial AIoT Event Pipeline for In-Plant Logistics

Yash Bansal — Tue, 29 Sep 2026 14:39:41 +0000

Industrial IoT becomes significantly more challenging when the data represents physical movement.

A web application can generally assume that an API request comes in with a reasonably consistent structure.

A factory cannot assume the same about the physical world.

An RFID reader may produce an event

A BLE beacon may report proximity

A UWB system may generate location information

A forklift may produce telemetry

An MES may report a production-state change

An ERP may include business context

The engineering challenge is to normalize these heterogeneous events into something operational systems can consume.

Let's explore the architecture.

1. Start With an Event, Not a Dashboard

A reasonably useful event model might have fields like


source

device_id

event_type

timestamp

location

asset_id

material_id

production_context

confidence

metadata

The schema would certainly vary based on the implementation, but the point is that raw device signals should generally not be directly interpretable as business events.

A reader seeing a tag is a technical event.

"Container 482 arrived at Assembly Zone B" is an operational event.

The latter includes contextual information that is generally more useful to downstream systems.

2. Normalize Heterogeneous Signals

RFID may produce reads.

BLE may produce proximity information.

UWB may produce location information.

Sensors may produce measurements.

Vehicle systems may produce telemetry.

If every application consuming these signals has to understand every protocol, that generally creates a problematic architecture.

A normalization layer can help to expose a common operational event model that can also be extended as new device types are added.

3. Add Manufacturing Context

Location is rarely sufficient.

For example,


Container → Zone 4

This is useful information, but it could be much more.

For example:


Container → Zone 4

Material → Component A

Production Order → 3817

Required Station → Assembly 07

Inventory Status → Replenishment

Timestamp → 10:42

The latter is a much more valuable event for an operations application.

This is where ERP, MES, WMS, EAM, and other systems come into play.

PlantLog AI documents the integration of these types of manufacturing systems with RFID, RTLS, UWB, BLE, edge infrastructure, and operational analytics.

4. Treat Location as a Data Dimension

Location should not necessarily be a visualization layer.

It can instead become a data dimension attached to operational events.

For example:

inventory → moved

asset → entered_zone

WIP → arrived

forklift → available

container → waiting

material → replenishment_required

All of these events can include spatial and temporal information.

This then enables analysis of patterns, dwell time, congestion, and material flow.

5. Put AI Above a Reliable Data Layer

Machine learning algorithms cannot overcome fundamentally unreliable event data.

If timestamps are wrong, device identities are duplicated, location information is missing, or events are out of order, the model will learn from this garbage.

Instead, a pragmatic architecture should include:

Event validation

Timestamp consistency

Device identity

Duplicate detection

Missing signals

Confidence

Location normalization

Data lineage

Once the event layer is reasonably reliable, it becomes significantly more valuable to introduce advanced analytics.

This is generally where the real "value add" occurs, but only if the data is trustworthy.

6. Edge Processing Can Matter

There may be a large number of devices distributed throughout a facility.

An edge layer can help process relevant events closer to the source.

This can enable both near-real-time processing and analytics.

A plant could process a location event immediately at the edge while aggregating information for an analytical layer.

The architecture (cloud, private, hybrid, or on-premise) should be chosen based on the facility's specific requirements.

7. Design for the Operational Consumer

The final output should not be a stream of events, although that can be part of the pipeline.

Various stakeholders will want different information.

A logistics supervisor may want replenishment information.

A production planner may want WIP movement.

A warehouse manager may want inventory location.

An industrial engineer may want congestion analysis.

Maintenance may want mobile equipment utilization.

All of these can originate from the same event pipeline.

The Architecture in One View

It could look something like this:


Physical World

↓

RFID / BLE / UWB / RTLS / Sensors / Telemetry

↓

Device & Edge Layer

↓

Event Normalization

↓

Operational Context

↓

ERP / MES / WMS / EAM Integration

↓

Analytics + AI

↓

Operational Applications

This reframes the question from "Which tracking device should we buy?"

to a more interesting engineering problem:

How should physical events be transformed into reliable operational information?

For a more thorough examination of this architecture, [PlantLog AI] documents how multiple industrial location and IoT technologies can be combined for in-plant logistics and enterprise integration.

In industrial environments, the real challenge is rarely to collect another signal: it is to make all of the signals understandable together.

Designing an AIoT Pipeline: From Physical Events to Decisions

Yash Bansal — Mon, 28 Sep 2026 15:10:19 +0000

Artificial intelligence and the Internet of Things are often conflated as “AI + IoT,” but the description begs an engineering question: How do you turn physical-world data into an operational decision? The architecture of such a system can be conceptualized as a pipeline:


Physical World

↓

Identification

↓

Sensing & Data Collection

↓

Data Integration

↓

AI / Analytics

↓

Decision Support

↓

Authorized Action

↓

Verification & Feedback

Each stage in the pipeline serves a specific function.

1. Identification

Before any analysis can begin, it is necessary to determine what the event or physical-world data means.

For example, there may be a need to identify what machine, vehicle, person, container, inventory item, or some other object is associated with the data.

The location and identity of an item or person often add needed context to raw sensor data.

2. Sensing

The next step seeks to answer the question: What is happening?

Depending on the application, location, movement, temperature, pressure, equipment status, and other sensor data may be involved.

The key is to capture relevant data — not the most data possible.

There is a difference between what can be captured and what has practical value for an operational purpose.

3. Data Integration

Most industrial Internet of Things applications involve more than one data source.

These could include sensors, identification data, enterprise resource planning systems, equipment databases, operational technology systems, or other sources of information.

It is therefore necessary to bring that data together and create a useable dataset for the AI or analytics model.

The data integration layer exists to ensure that the information fed into the next layer is valuable and actionable.

4. AI Decision Layer

Once the AI has the data it needs, it can begin to answer progressively more difficult questions, such as:

What is happening?
What is abnormal?
What will happen next?
What should we consider?

An example might be to ingest equipment location, operating conditions, and enterprise data to trigger an alert about an evolving situation.

The AI decision layer should be designed to make decisions, not models.

Decisions will depend on the application and the acceptable degree of automation.

5. Authorized Action

The output of most AI models is not an action, but a suggestion.

In some cases, suggestions can be automated, but industrial applications usually require constraints such as defined limits, authorization, human review, auditing, cybersecurity protection, escalation, and fail-safes.

Physical-world systems usually require a carefully considered degree of automation and control.

6. Verification

The pipeline is not complete without verification and feedback.

Ingesting data about a past condition or event enables the system to determine whether an action had the intended effect.

Did the world change as expected? Did the action make a difference? What did the physical world look like before and after the change?

This information can then be used toupdate the rules, processes, or the models themselves.

The overall pattern can be summarized in a phrase: Identify → Sense → Decide → Act → Verify.

It is a useful contrast to the common but much less precise description of AIoT as simply an AI model that sits atop an IoT pipeline.

The pattern creates a more useful set of guardrails for designing an architecture that links physical-world events and decisions with rules, processes, and AI.

Aperture Venture Studio has one approach to this architecture that it calls the four-engine system, which includes Identification, Sensing, AI Decision, and Physical AI Action with verification and improvement built into the process.

[Here is the link to their detailed discussion of the architecture.]

For engineers and enterprise software architects, the takeaway is that effective AIoT solutions are not simply about the model at the center of the system, but about the overall pipeline from the physical world to verifiable action.

Building a data pipeline for pharmaceutical AIoT: from sensors to manufacturing intelligence

Yash Bansal — Mon, 28 Sep 2026 14:43:45 +0000

When people talk about AIoT in pharmaceutical manufacturing, the discussion often focuses on AI models

But before any analytics can generate useful insights, there is an engineering problem that must be addressed:

how to get data from physical devices to systems that can actually use it

The environment of pharmaceutical manufacturing can involve RFID readers, BLE devices, environmental sensors, production equipment, laboratory systems, warehouse applications, MES, ERP, LIMS, QMS and serialization infrastructure

This creates a distributed data challenge

A simple AIoT architecture

A good way to approach the architecture is to visualize a path from:

Physical environment -> Edge layer -> Data integration -> Analytics -> Operational systems

1. Physical environment

The first layer consists of the devices that generate events. Examples of devices include:

RFID readers

RFID tags

BLE beacons

Personnel identification devices

Temperature sensors

Humidity sensors

Differential-pressure sensors

Equipment sensors

Industrial gateways

These devices generate different types of information at different intervals

2. Edge layer

Not every raw event is best sent directly to a centralized application. An edge layer can help with aggregation, normalization, processing and synchronization of information closer to the operational environment. For pharmaceutical facilities, edge computing can be particularly valuable when systems require local processing, reliable connectivity, or controlled data flow.

3. Integration layer

Next, the challenge is to facilitate interoperability. A facility may already have established systems for:

Manufacturing execution

Enterprise resource planning

Laboratory information

Quality management

Warehouse operations

Serialization

Asset management

Replacing all of these systems just to implement AIoT is unlikely to be realistic. An integration layer can be focused on connecting new data sources to existing systems. PharmaFlux AI describes pharmaceutical edge integration across MES, ERP, LIMS, QMS, RFID, BLE, environmental monitoring, serialization, and AIoT infrastructure.

Why event processing matters

Different events require different responses. Imagine three events:

Event A: An RFID reader detects movement of a material container

Event B: An environmental sensor detects a condition outside of an established threshold

Event C: A BLE system detects personnel movement into a controlled zone

These events contain different operational significance. A useful data pipeline requires more than just collection - it needs:

Event identification

Timestamping

Source identification

Context

Validation

Routing

Storage

Analytics

The same raw event can become much more valuable once it is associated with business context.

Data lineage is particularly important

Pharmaceutical manufacturing often involves traceability. A production event may be associated with a batch, material, equipment, location, process stage, and personnel activities. This means that an AIoT architecture should consider relationships between data objects, rather than treating every sensor reading as an isolated record. For instance:

Material -> batch -> production stage -> equipment -> location -> event timestamp

This relationship can be more valuable than a collection of unrelated sensor readings.

AI comes after the data foundation

Once data is structured, analytics can become more valuable. Applications can include:

Process bottleneck analysis

Asset utilization analysis

Inventory visibility

Workforce analytics

Environmental monitoring

Anomaly detection

Maintenance intelligence

Batch traceability

PharmaFlux AI describes applications spanning asset intelligence, inventory monitoring, process intelligence, workforce visibility, and electronic traceability. The lesson for engineers is to recognize that they should not design the AI layer independently from the data architecture. The quality of the output depends on how valuable the underlying events are in terms of context, timing, and reliability.

A practical implementation sequence

A pharmaceutical AIoT project can be broken into manageable stages, such as:

Stage 1 - Identify the operational problem

Focus on what is a real business need rather than on a technology

Stage 2 - Map existing data sources

Document devices, applications, databases, and integration points

Stage 3 - Define the event model

Define what constitutes an important event and what metadata it should have

Stage 4 - Establish edge connectivity

Connect relevant devices and systems, considering local operational requirements

Stage 5 - Integrate enterprise systems

Enable reliable information flow between operational and business applications

Stage 6 - Add analytics

Apply rules, dashboards, statistical analysis, or AI models where they target a specific requirement in decision-making

Stage 7 - Measure outcomes

Assess whether the system actually improves visibility, response time, traceability, utilization, or another defined metric

The engineering takeaway

AIoT in pharmaceutical manufacturing is not only an AI challenge but also a systems-engineering one that involves devices, networks, data models, integration, edge computing, analytics, and operational workflows. A well-designed architecture can enable connections between physical events and manufacturing context, which ultimately transforms sensor data into manufacturing intelligence. For an example of this connected architecture, PharmaFlux AI describes an approach that combines industrial IoT, RFID, BLE, edge intelligence, and enterprise integration for pharmaceutical manufacturing.

Designing an AIoT Pipeline: From Physical Signals to Intelligent Decisions

Yash Bansal — Thu, 24 Sep 2026 17:14:33 +0000

Plugging a sensor into the internet is pretty simple.

Designing an architecture that can understand signals from the physical world, analyze them, make decisions and support operations is very hard.

This is what AIoT (Artificial Intelligence of Things) is all about.

AIoT brings together IoT infrastructure with artificial intelligence capabilities - and the focus is on creating systems that can not only observe signals from the physical world, but analyze and understand, and even act upon them.

I like to think about an AIoT system as a pipeline:

Physical Environment
↓
Identification & Sensing
↓
Data Collection
↓
Data Processing
↓
AI / Analytics
↓
Decision Layer
↓
Human or Machine Action

Let's examine what goes on in each layer.

1. Physical Environment

It's easy to forget that AIoT always starts with something that has nothing to do with python.
There might be machines, cars, inventory, people, tools, production lines or some other physical objects you need to account for.
Before deciding what type of AI you may need, it's critical to understand the domain.
We need to answer questions such as:
What objects do I need to identify?
What variables do I need to measure?
How often will events occur?
What constitutes important information?
What are current decision points?
These considerations will shape our system requirements.

2. Identification and Sensing

In this layer our goal is basically to gather information about the physical world.
We can utilize a range of varying technologies:
RFID tags help identify objects
Cameras collect visual imagery
GPS provides location information
Temperature sensors register body heat
Vibration sensors help us understand pressure and impact
And of course a wide range of industrial IoT sensors collect data related to process variables
The point is that not every physical application needs RFID. So the sensing architecture must be tailored to the operational needs.

3. The Data Pipeline

A sensor reading is not useful unless we know how to interpret it.
A production-quality architecture should have elements like:

Ingesting data streams
Timestamping events
Identification / tag parsing
Validation and filtration
Data normalization
Storage and retention
Data integration
Event triggers
Access control Take the example of a machine that is producing thousands of measurements in a given period of time. How will we decide what information is worth keeping? How will this sensor data integrate with additional operating parameters? This is why data engineering is so critically important in an AIoT architecture.

4. Contextual Intelligence

A single sensor measurement might not be valuable in isolation.
Let's say we have a temperature reading that's fluctuating unexpectedly.
In order to determine if it is an outlier, we might want to take into consideration a set of factors:

The type of machine
Operating conditions
Overall production timeline
Ambient environment
Maintenance history
Other sensor readings A great deal of industrial environments are multivariate - and contextual variables help separate noise from actionable information. Which is why we tend to see multi-sensor architectures rather than an isolated measurement stream. ## 5. The AI Layer At this point we can start thinking about the different ways an AIoT architecture can leverage artificial intelligence. This could potentially be:
Anomaly detection
Classification
Forecasting
Vision recognition
Predictive modeling
Optimization
Pattern recognition
Decision support Again, this will be dictated by the problem we're trying to solve. We don't have to implement the latest and greatest machine learning algorithm for every AIoT system. Sometimes an older, less complex but well-documented model might be more appropriate and easier to implement for an industrial architecture. The important thing is to let the model choose its inputs based on our defined problem statement. ## 6. Cloud vs Edge Processing Where do we want to process our information? We can choose between using edge processing capabilities close to the sensor, or push workloads to the cloud. ### Edge Processing Using local computational resources can help with:
Latency
Bandwidth constraints
Speed of execution
Ability to function offline ### Cloud Processing Cloud solutions allow for:
Large-scale data retention
Wide-area analytic aggregation
Model management
General enterprise integration A good architecture will decide on the tradeoffs between these two based on a number of criteria such as latency, security, computing power, bandwidth and others. ## 7. Decision Layer An AIoT architecture with a functioning data pipeline and a working AI model is not enough. We need a decision engine to connect the two. Let me give you an example:

Sensor detects change
↓
Data pipeline validates signal
↓
AI identifies unusual pattern
↓
System evaluates context
↓
Decision rule determines response
↓
Operator receives alert

In a more automated system the bottom of this chain might look like a call to another software program or perhaps an automated machine.
This layer is critically important - because it tells us how AI fits into the overall system.

8. Human-in-the-loop Systems

An AIoT architecture can also support human-in-the-loop systems.
By that I mean, the AI model might support the process, but people still make strategic decisions.
It could be implemented something like this:
AI: "This equipment behavior is different compared to its history."
Operator: Considers the recommendation and decides whether to recommend maintenance.
This gives the best of both worlds - statistical analysis from AI and contextual awareness from people.
The more strategic aspects of the system should be considered based on the application, risk profile and potential cost of mistake.

9. Physical AI Design

At this point our system likely falls into the category of what people call Physical AI.
We need to recognize that a conventional software architecture is very different than a Physical AI system.
A software application runs primarily in a virtual space.
An AIoT architecture must interact with the physical world, which means taking into account:

Sensor capability
Environmental factors
System limitations
Safety protocols
Latency issues
Failover procedures
Human operators
Mechanization It's no longer just a question of what might happen. Some architectures ultimately take action in the physical world as a result of the insights derived. ## 10. Evaluation Criteria Another common pitfall is to evaluate an AIoT architecture based solely on model performance. We want to define a set of metrics that will help us evaluate the system as a whole. Depending on the application we might look at metrics like:
Accuracy
False positive rate
Detection speed
System reliability
Data quality
Overall operational impact
Rate of human intervention
Cost savings
System efficiency In some cases a well-documented model that failed to impact system performance may not represent a significant improvement. ## A Practical Architecture Putting it all together we get something like this:

┌─────────────────────┐
│ Physical Environment│
└──────────┬──────────┘
↓
┌─────────────────────┐
│ Sensors / Devices  │
└──────────┬──────────┘
↓
┌─────────────────────┐
│ Data Infrastructure │
└──────────┬──────────┘
↓
┌─────────────────────┐
│ AI / Analytics    │
└──────────┬──────────┘
↓
┌─────────────────────┐
│ Decision Engine   │
└──────────┬──────────┘
↓
┌─────────────────────┐
│ Human / Machine   │
│ Action       │
└─────────────────────┘

We can apply this basic architecture to manufacturing, logistics, energy, mining, building construction and many other application areas.
For anyone looking deeper into how such an architecture could be implemented in practice, Aperture Venture Studio's AIoT and Physical AI work provides additional context and reference material.

Final Takeaway

Designing an AIoT architecture is not about tacking on an AI model to an existing IoT pipeline.
We want to build a complete system that encompasses:
physical signals → reliable data → contextual intelligence → decisions → actions.

In my experience the process starts with the domain and works backward to the technology stack.

As AI systems continue to operate in the physical world, a comprehensive understanding of the architecture will be as valuable as the AI models inside it.

What Does a Modern Inventory Management Tech Stack Look Like?

Yash Bansal — Thu, 24 Sep 2026 16:44:09 +0000

Inventory management can be a complex business problem. Yet many modern inventory systems are underpinned by a deep technical infrastructure.

An inventory event, the receipt or the movement of stock, can comprise a spectrum of scanners, sensors, databases, API, business applications and reporting tools.

What may seem like a simple business event, a product going on or off the warehouse floor, is a deep technical implementation.

Modern inventory management systems deal simultaneously with an enormous variety of inventory events. There are product arrivals, movements and exits in various forms.

The key to inventory technology lies in being able to reflect the inventory information accurately in the face of these events.

Let’s Start with the Event

Perhaps the primary consideration in inventory is the event.

A warehouse receives 100 units of product X. There is presumably some sort of inventory event here. A database, an application, or even an API may need to be notified of said event.

So perhaps some information needs to be captured or stored.

This record might take the shape of various pieces of data:


Product ID:

Quantity:

Location:

Timestamp:

Transaction Type:

Source:

Now the event may update some inventory information:


Received: +100

Available Inventory: 500 → 600

Now imagine those 100 units of product X are being dispersed to various locations within the warehouse.

The inventory management system must appropriately reflect both the product, quantity, and location information.

Inventory management becomes a data architecture problem at this point.

Where Does the Data Come From?

There are several possible sources of information for an inventory system.

Barcode scanners

A barcode scanner can be used to pick up information about a product during receipt, picking, packing or shipping.

An application can learn what product has been scanned and apply the transaction to the inventory.

RFID

RFID is another way to identify an object through radio frequency technology.

Depending on the nature of the RFID infrastructure deployed, it can obviate the need for manual scanning in certain situations.

IoT devices

There are a variety of IoT devices that can be used to capture inventory information from the physical world.

A generalized IoT architecture could resemble the following:


Sensor

↓

Gateway

↓

Network

↓

Data Platform

↓

Inventory Application

↓

Dashboard / Business Process

The architecture will undoubtedly differ depending on the context and needs of the operation.

Humans

The human factor should not be discounted in an inventory system. There will undoubtedly be some situations where an employee needs to create or verify an inventory event.

There may be a web application, some sort of mobile interface, a warehouse management system or any number of other tools at the disposal of an employee.

Any effective inventory system should account for a variety of situations: automated and human-generated inventory events.

The Application Layer

Software is needed to take the inventory information and do something with it. A generalized architecture for an inventory application may resemble the following:


Physical Inventory

↓

Barcode / RFID /IoT

↓

Integration Layer

↓

Inventory Management System

↓

Database

↓

APIs / Business Applications

↓

Dashboards & Reports

The inventory management application, therefore, should encapsulate various business logic:


IF available_stock < reorder_threshold THEN

create_replenishment_signal

The actual realization will obviously differ depending on a company’s needs, but the basic idea is that the data about inventory should be valuable and usable information that can create meaningful decisions or actions.

APIs Become an Important Part of the Conversation

Modern businesses do not tend to use only one application. It is more likely that an organization uses an ecosystem of different business applications.

These applications might include an ERP system, a warehouse management system (WMS), a point of sale (POS) system, an e-commerce platform, transportation systems, inventory platforms, etc.

An effective technical architecture enables these various tools to communicate through API.

API enable these business applications to share information with each other.

An API-enabled architecture might resemble the following:


E-commerce Platform

↓

API

↓

Inventory System

↓

WMS

↓

Warehouse Operation

If proper inventory system integration does not occur, workers may need to perform the same actions in different applications.

This obviously opens the door to errors and duplication of efforts.

The Database Is only Part of the Puzzle

It is easy to assume that an inventory management application is simply a database about quantity on hand for various products.

The truth is, while the database does contain this valuable information, this is only a small piece of what an inventory application requires.

A functioning inventory application also requires: Transaction history, locations, product information, permissions, integration, data validation, data reporting, forecasting, and exceptions, among other things.

So in order to understand what 500 means in an inventory system: 500 what? 500 where? 500 as of when? 500 available or reserved? There are several crucial pieces of accompanying information that make up an inventory application beyond the raw quantity itself.

Real-Time Does Not Always Mean Right Now

It is also easy to believe that all inventory systems are fully integrated and are real-time.

The truth is, inventory systems do not always require real-time updating or adjustments. This depends on a company’s operational needs.

A retail business will have different inventory needs than a manufacturing facility. The former will require more emphasis on demand forecasting while the latter may focus more on supply chain management.

In any case, there are inventory applications that operate in real-time; however, this is not appropriate for all companies.

This is why architecture decisions should be based on operational needs as opposed to choosing an infrastructure based on a buzzword.

Where Does AI and Analytics Fit In?

Once a company has amassed a good amount of historical and inventory data, AI and analytics can become valuable parts of an inventory system.

Some operations that an inventory management system could use AI for:

Forecasting demand
Inventory optimization
Spotting patterns and outliers
Inventory planning and replenishment
General operational analysis

This is not to say that AI is a silver bullet. As with all data, the quality of AI models depends on the quality of the data inputted into it. Inventory systems with poor data management practices will not be able to rely on AI to help make their operations better.

One rule of thumb to remember is: Better models still depend on better data.

Security and Reliability Are Also a Concern

Inventory systems can house valuable pieces of information for an operation. As such, there may be a need for proper security, authentication, encryption, authorization, availability, auditing, and reliability. A company may have reliable operational data, but an application outage or breach can nevertheless inflict serious problems on an operation.

The Architecture Should Reflect the Workflow

A good inventory architecture is one that fits a business’s needs. There is no “one-size-fits-all” approach to choosing an inventory system.

It is always worthwhile to analyze where inventory events take place in an operation.

How are these inventory events currently captured? Where is the information currently captured or stored? Where does the information need to go? Where are bottlenecks or problem areas in the inventory process? Where might technology be useful in inventory processes?

Such a workflow-based approach will ensure that technology solves an inventory problem as opposed to technology being used simply for its own sake.

Companies that are looking to understand the kinds of components involved in a modern inventory system, inventory management software and technology solutions offer a useful insight as to how various technologies and processes combine to form a comprehensive system.

Final Thoughts

A modern inventory system is essentially an amalgamation of processes and technologies that work in tandem to create a digital representation of the physical world. Product X goes on and off the warehouse floor: sensors and scanners capture this event and software is needed to process this event and store this information in a database. There are various API tools that help different business applications communicate with each other. Historical information about inventory can be analyzed by analytics tools and AI to create more accurate demand forecasts and make other operational suggestions. A whole host of technologies come into play in modern inventory systems. The purpose of all of this technology, however, is a singular goal: creating a digital representation of physical inventory that is reliable and repeatable in order to create accurate analysis, inventory forecasts or automation in inventory processes, among other things.

AIoT Architecture: Connecting IoT, AI and Operations

Yash Bansal — Wed, 23 Sep 2026 15:58:48 +0000

IoT has transformed our capabilities around collecting information from the physical world.

Sensors can monitor equipment, connected devices can provide their location, machines can capture operational events and tracking systems can provide visibility into an organization's assets and activities.

However, capturing data is only the beginning.

The far more interesting challenge lies in utilizing it to derive value.

The question of how to process sensor events, interpret them in the context of an AI system's decision and link them into a physical workflow is at the center how AIoT can be interesting to developers and system architects.

A Look at the Components of an AIoT Pipeline

A simple view of an AIoT architecture can be thought of in terms of a pipeline:


Physical Environment

↓

Sensors / Devices

↓

Connectivity

↓

Data Processing

↓

AI / ML Layer

↓

Decision

↓

Physical or Digital Action

↓

Verification

Each of the items in this pipeline represent a distinct responsibility.

The sensors observe what is occuring, connectivity provides the means to transmit the information, data infrastructure processes it, AI interprets patterns or events and the decision layer takes what happened so far, determines what should happen next, then operates on the world.

The key is to think about how digital intelligence can be used to improve or alter an operational reality.

1. Understand the Physical Environment First

A key difference between many AI-native application and these AIoT systems is that the latter begins with considering the physical environment.

That might include:

Equipment conditions

Asset movements

Inventory levels

Environmental data

Vehicle information

Production events

Activities of individuals or locations

The initial engineering challenge is to determine what needs to be observed.

A system cannot make decisions based upon information that cannot be reliably captured.

2. IoT Lets You Turn Physical Events Into Data

These sensors and connected devices form the data layer of this architecture.

Depending upon the application there may be continuous streams of records or individual events.

The data may look something like:


{

"asset_id": "A102",

"location": "Zone-4",

"temperature": 31.4,

"status": "active",

"timestamp": "2026-09-23T10:15:00Z"

}

Each item will vary but the overall architecture is focused around turning the physical into something that is machine-readable.

Data quality becomes a critical component of this architecture since false timestamps, missing values, duplicated records, intermittent connectivity issues and inconsistent identifiers will undermine the effectiveness of the system further down the line.

3. Connecting the System Through Data Infrastructure

Once the information has been captured, it is necessary to route it into relevant data infrastructure.

Depending upon the application there may be:

APIs

Event streams

Databases

Message brokers

Edge infrastruce

Cloud systems

Data pipelines

A central consideration is that the architecture reflects the business requirements rather than always aiming to implement the same pattern across all applications.

Latency-sensitive data may benefit from processing closer to the source while other operations may have more flexibility to utilize centralized resources.

The underlying idea is to build a data architecture that reflects the nature of the physical process being measured.

4. Using AI to Interpret Information

While IoT tells you what you can see, AI offers a means to understand what it might imply.

For example, an AI or machine-learning system might analyze historical and current operational data to recognize patterns or abnormal values.

A simple conceptualization would be:


sensor_data = collect_events()

processed_data = preprocess(sensor_data)

prediction = model.predict(processed_data)

if prediction indicates_anomaly:

generate_alert()

The specifics of implementation will of course vary widely based upon the use-case, model, available infrastructure and operational constraints.

The key architecture design point is that this AI layer must be considered in context of the data and physical environment.

5. Decisions Require Looking at Context

A machine learning model's predictions are often not by themselves enough information to take direct actions.

Suppose that the system observes an unusual equipment pattern.

The critical question then becomes:

What should the organization do?

That will often depend upon:

Equipment state

Location

Schedules

Safety requirements

Existing workflows

Business rules

Human workflows

It is part of why industrial systems often require more than just a prediction model.

They must be coupled into a decision layer that can understand the operational context of what happened.

6. Closing the Loop

One of the key characteristics of a Physical AI is tying digital intelligence to physical actions.

A simple loop can be visualized as:


Sense

↓

Understand

↓

Decide

↓

Act

↓

Verify

↓

Sense Again

A feedback loop from operations into the system is necessary for it to evolve its understanding of physical patterns.

The output of Act is not merely to provide a prediction but instead to utilize it to improve the system's ability to operate in the physical world.

Why Digital Twins and Simulation Can Matter

In addition to providing observations, when organizations are operating complex systems they may benefit from also creating digital representations of it.

A digital equivalent provides an opportunity to bring information together about processes, machinery and environments to understand interdependencies.

This can help identify issues that would not previously be evident from individual events.

At the same time, the value of such a model is limited by the quality of data and assumptions that go into it.

The Challenge of Integration

One of the key engineering challenges for AIoT systems is often not the model itself but instead ensuring the infrastructure allows for adequate levels of integration when deployed.

A practical example includes:


Sensors

+

IoT Devices

+

Existing Software

+

Operational Databases

+

AI Models

+

Human Workflows

+

Physical Equipment

Each item may have different protocols, data formats, update frequencies, reliability requirements, jurisdictional responsibilities.

At a fundamental level system architecture becomes critically important.

An Engineering View of Considerations

Rather than thinking in terms of:

Where can AI be added?

A more interesting engineering perspective is to consider:

What physical process are we trying to understand or improve and what information is needed to make more informed decisions?

From there, organizations can determine their approach based upon:

Physical problem to be solved
Physical events that are important to understand
Data available
Data pipeline needs
Opportunities to apply an AI layer for additional insight
Decision requirements
How decisions integrate to existing operational systems
What results are desired from these actions

This approach keeps the technology requirements aligned with operational outcomes.

Looking At Why Venture Building Fits in AIoT

Many AIoT applications have the ability to scale across more than one use-case.

When there is an industrial problem that is common across organizations in similar industry domains there can be an opportunity to build a technology platform or venture that provides a complete set of capabilities across software, data and operational infrastructure.

It often requires moving beyond the role of just the architecture and model, exploring opportunities to think about the problem domain, deployment requirements, data infrastructure, industry-specific workflows, and how the proposed solution can scale.

Aperture Venture Studio is an example of one approach to building ventures focused in the domain of AIoT as well as Physical AI applications for physical-world operations.

Final Thoughts

IoT is not merely a foundation on which to deploy an AI model.

The AIoT paradigm is about how we can leverage connected systems and infrastructure to improve our ability to operate in the physical world.

For developers and architects the most interesting challenges are not limited to model creation.

They can also be found in making sure that the data quality, systems integration, contextual analysis, reliability guarantees, feedback loops and the connection to physical operations takes place simultaneously.

As AI becomes increasingly involved with physical capabilities the ability to design that entire loop may prove equally as valuable as the model creation process.

Designing an AIoT Data Pipeline for Pharmaceutical Manufacturing

Yash Bansal — Wed, 23 Sep 2026 15:32:22 +0000

Many different types of data are produced during pharmaceutical manufacturing, from machines, sensors, RFID readers, environmental monitoring, laboratory platforms, manufacturing applications and enterprise software.

The engineering challenge isn't simply collecting this information.

This is more about designing a pipeline that can take physical-world events and turn them into digital information and analytics signals

Let's talk about a simplified AIoT architecture:

Physical Devices
Sensors / RFID / BLE
Edge Gateway
Data Ingestion
Data Processing
AI / Analytics
Applications & Dashboards
Human Decisions

Each level represents a different aspect of the solution.

Devices observe the physical world, connectivity transports information, edge and cloud infrastructure process it, AI models detect patterns, and applications deliver value to end-users.
Let's examine some of these ideas more closely.

Start With Events Instead of Data

One of the biggest mistakes I see with IoT initiatives is thinking about sensor values:

temperature = 22.4°C
humidity = 45%
machine_status = running

An application, however, might want to think in terms of events:
Environmental condition changed

Equipment operating pattern changed
Material entered a controlled area
Asset moved from location A to location B
By shifting the mindset to events and contextual information, developers can create better abstractions for downstream applications
Instead of having to process thousands of individual sensor values, an application cansubscribe to a stream of relevant events.

The Edge Layer Can Help With Filtering Not all sensor values need to be sent to a central platform. An edge gateway can help with: Protocol conversion

Data filtering
Local validation
Temporary storage
Simple anomaly detection
Device management
For instance, sensors might be pushing out values each second while business applications only care about averages each minute.
With some lightweight processing at the edge, we can reduce bandwidth consumption and enable some level of functionality even if connectivity is temporarily lost.

Data Normalization Is Important Pharmaceutical facilities often contain a variety of devices from different vendors. One system might represent temperature as: { "temperature": 22.4 } While another system might use: { "temp_value": 22.4, "unit": "C" } A centralized data layer would want to standardize this into something more like: { "device_id": "sensor_104", "timestamp": "2026-09-23T10:30:00Z", "metric": "temperature",

"value": 22.4,
"unit": "C",
"location": "production_area_01"
}
This would make downstream analytics and application development much easier.

AI Should Be Built on Reliable Data You can't fix bad data architecture with an AI model. Before developing machine-learning solutions, we need to think about: -Data quality -Data completeness -Timestamp consistency -Sensor calibration -Duplicate records -Outliers -Historical data availability -Quality of labels -Data lineage For instance, an anomaly detection model might indicate that a particular machine is exhibiting unexpected behavior. However, if that machine's sensor frequently loses connection, the model might be reacting to missing data rather than actual device behavior. Before adding AI capabilities, make sure that the data engineering layer is producing high-quality results.
Move From Rules to Machine Learning When It Makes Sense

Sometimes a simple rule-based system is sufficient:
if temperature > threshold:
create_alert()
However, we might want to use a machine learning model if we have a more complicated situation.
For instance, an organization might want to detect unusual equipment behavior:
temperature
+
vibration
+
operating hours
+
motor current
+
historical behavior
...
A model could analyze these variables and produce an anomaly score.
The most interesting engineering questions aren't about where we can use AI, but when AI can provide value beyond a simple rules engine.

Integrating With Other Systems A pharmaceutical AIoT platform rarely exists in isolation. It might need to communicate with:
MES
ERP
LIMS
QMS
Warehouse systems
Maintenance platforms APIs, message brokers, event-driven architectures and common data models can help with this integration. For developers, this means that system interoperability needs to be considered from the very beginning of the architecture design.
Don't Forget About Security and Governance A connected pharmaceutical environment needs more than just a technically sound architecture. We also need to think about: -Authentication -Authorization -Encryption -Device identity -Network segmentation -Audit trails -Data retention -Access control -Monitoring -Change management As more and more physical devices get connected to business systems, the boundary between operational technology and information technology becomes more important.
Build the System in Stages It can be helpful to start with a specific use case. For instance: Problem Identify required data Connect devices Normalize events Build monitoring Validate data quality Add analytics Measure operational value Once we've developed the pipeline for one use case, we might want to re-use some of these components for other purposes. This iterative approach can be much more realistic than trying to connect every device, application and enterprise data lake at once. The Bigger Engineering Challenge Building an AIoT system for pharmaceutical manufacturing isn't simply an AI challenge.

It's really an amalgam of IoT, data engineering, edge computing, software integration, analytics, security and domain knowledge.

The AI model might attract the most attention, but it's really the supporting infrastructure that determines if that model receives high-quality data.

This is why developers need to think about the bigger picture when designing pharmaceutical AIoT solutions.

The true challenge isn't simply what the AI model does, but how we can reliably transform a physical-world event into a digital insight.

For an example of how AIoT technologies can be applied to connected pharmaceutical operations, PharmaFlux AI provides an industry-specific perspective: https://pharmafluxai.com

The most interesting AIoT systems may ultimately be the ones that make complex physical operations easier to understand - for humans, not just computers.

From IoT Data to Intelligence: How AI Changes Connected Systems

Yash Bansal — Tue, 22 Sep 2026 15:35:15 +0000

IoT (Internet of Things) systems are particularly good at collecting data.

Sensors can continuously report temperatures, vibrations, pressures, positions, and other physical world values. When the data starts to arrive, however, another question emerges:

How do we make sense of all these telemetry insights?

This is where Artificial Intelligence can expand the potential of IoT systems.

Combining the two is typically referred to as AIoT (Artificial Intelligence of Things), and the high-level architecture looks like this:

Physical Environment

↓

Sensors / Devices

↓

IoT Connectivity

↓

Data Processing

↓

AI / ML Models

↓

Insights / Decisions

↓

Alerts / Automation / Human Action

Interesting engineering problems arise between each layer. Let's look at a few examples.

IoT Gets Data, But What Do We Do With It?

Suppose you have an industrial machine producing thousands of sensor readings per hour. A typical implementation for an IoT application could be to store and visualize the readings in a dashboard.

Not a bad practice for monitoring, but a dashboard isn't likely to tell you why a value changed and if the change is worth investigating further. That's where an AI layer can help, though.

An AI layer can review historical and current telemetry for patterns, helping to identify if a sensor reading is abnormal.

One potential pipeline can look like this:

Normal operating pattern

↓

New sensor readings

↓

Feature extraction

↓

ML model

↓

Normal / anomalous behavior

The model can then take appropriate action, such as alerting or giving the operators more information to investigate the issue.

How it's implemented will largely depend on the equipment, data, model and operational requirements.

Predictive Maintenance

One obvious application for AIoT is predictive maintenance.

Rather than relying on a fixed schedule for maintaining the equipment, organizations can process the telemetry data of their equipment to find changes in its operating patterns.

For example, imagine vibration sensor data from a machine:

Timestamp | Vibration

10:00 | 2.1

10:01 | 2.2

10:02 | 2.1

10:03 | 2.8

A basic IoT implementation would likely be able to log and visualize the data, but not much else. An AI system, however, can use the telemetry in a larger context, such as looking at other similar patterns and determining if something should be flagged. The context can include additional telemetry, such as the equipment's temperature or other variables. It's unlikely that such a system would be able to predict exactly when the machine will fail (this is a common misconception about AI), but it can look for patterns that may be worth investigating further.

Anomaly Detection

Another common use case for AI + IoT systems is anomaly detection.

IoT solutions can generate an overwhelming amount of data for a human to investigate, so machine-learning techniques can help spot observations that are different in some way than others. For this specific application, techniques such as statistical detection, supervised, unsupervised or time-series learning, classification, neural networks and others may apply.

The important part is not to over-engineer your solution with complicated algorithms, but to pick the right model for your domain, data, latency and operational requirements.

Edge AI vs. Cloud AI

Where to run your inferences is another important architectural decision.

IoT data can be sent to the cloud for processing by AI models. Some of the advantages of doing this can be

centralized computing resources

easier model management

ability to process data at scale

convenient integration with cloud services

However, transmitting all that data may not always be feasible.

Another option is to use edge AI, where some processing can be done closer to the data source.

This is particularly useful when the application has strict requirements on latency, connectivity or data volume. A potential architecture could look something like this:

Sensor

↓

Edge Device

↓

Local AI Inference

↓

Immediate Response

Cloud

↓

Historical Analysis

↓

Model Training / Management

In practice, hybrid approaches are often viable.

The Data Engineering Problem

AIoT isn't only an AI problem, though. It's also a data engineering problem.

A model is only as good as the training and inference data that feeds it, and developers may need to deal with missing sensor readings, noisy data, varying sampling rates, calibration issues and more.

For example, if temperature is being sampled every second, but a pressure sensor is sampled every minute, how do you combine this data for your model? What about data versioning, network outages, feature engineering, and model drift? These are why, in practice, AIoT development involves collaboration between software developers, data engineers, ML engineers and domain specialists.

From AIoT to Physical AI

AIoT is also connected to the rising concept of Physical AI.

The idea is that AI can be integrated into systems where it interacts with the physical world rather than just relying on digital information.

A potential architecture can be thought of as:

Sense → Understand → Decide → Act

IoT devices can provide much of the "sense" and "connect" parts. AI can add "understand" and "decide". Robotics, machines, automation equipment and similar can provide "act". This creates an interesting engineering space between software, AI, IoT and physical systems.

Aperture Venture Studio is interested in this intersection through its work of exploring AIoT and Physical AI.

What Developers Should Think About

Creating an AI-enabled IoT system isn't a matter of connecting a machine-learning API to a sensor. A viable architecture must address considerations such as:

What data truly matters?
Where should data be processed?
How much latency can the application tolerate?
What happens when connectivity is lost?
How will sensor quality be monitored?
How will models be updated?
How will false positives be handled?
Where does human decision-making matter?

These questions can have much more impact on the final product than the choice of an AI model itself.

The Bigger Picture

AI adds value to IoT systems by providing an intelligence layer to the data coming from connected physical systems. IoT can answer "what is happening?", but AI can help investigate "is this happening often?" and a broader intelligent system can help answer "what should happen next?".

That progression from data collection → interpretation → decision-making support → action is why AIoT is interesting from an engineering point of view.

The goal isn't to use AI in every IoT application. The goal is to identify cases where intelligent analysis can make connected physical systems much more powerful.

Building smarter manufacturing with AIoT

Yash Bansal — Tue, 22 Sep 2026 14:21:28 +0000

AIoT — the union of Artificial Intelligence and Internet of Things — is becoming increasingly important to industrial software.

IoT provides the connectivity layer: sensors, RFID, location, machines, and other physical assets generate operational information.

AI provides the intelligence layer: algorithms can analyze the data, find patterns, find outliers, and support decisions.

The interesting question is what happens if these technologies have to work together in a real manufacturing environment.

The basic AIoT architecture

A simplified view of the AIoT architecture can be represented by multiple layers:


Physical Environment

↓

Sensors / RFID / RTLS / Machines

↓

Edge / IoT Connectivity

↓

Data Processing

↓

AI / Analytics

↓

Business & Manufacturing Systems

↓

Operational Decisions

Each layer plays a certain role: sensors and tracking technologies gather data from environment, IoT or edge infrastructure transports and processes the information, AI and analytics turn it to usable knowledge, and the final information becomes useful to operational decisions.

Why manufacturing makes AIoT interesting

A manufacturing facility is, essentially, a distributed physical system.

Materials are transported from location to location, machines are running, work-in-progress passes from one stage to another, forklifts and automated guided vehicles move around, inventory is forming and deforming during the day.

This information comes in large amounts, and, possibly, from many sources and technologies.

For instance, an organization may have:

RFID data

BLE or UWB location data

Machine sensor data

ERP data

MES data

WMS data

EAM data

It is not enough to just collect this information: the system has to make it usable.

From raw events to information

Let us imagine a simple material tracking scenario.

An RFID reader sees an item entering a certain zone.

The event that is sent to the IoT layer may look something like that:


Item detected

Location: Zone A

Timestamp: 10:32:15

What this event means, however, is something that the application needs to determine.

It may want to enrich the event with additional information:


Item location

+

Production order

+

Expected process stage

+

Historical movement

+

Inventory status

The information can then be passed to AI or analytics to identify patterns.

This is when AIoT becomes more interesting than a simple tracking system.

Edge computing reduces distance between data and actions

Industrial facilities can generate a large amount of data.

It may not always be feasible or efficient to send every single event to a remote environment for processing.

Edge computing can help by performing some operations closer to the source.

One example of such a scenario can be represented by the following architecture:


Sensor

↓

Edge Device

↓

Local Processing

↓

Relevant Event

↓

Cloud / Central Platform

Instead of sending every raw event for processing, an edge layer can perform some filtering and only send relevant information for further processing.

The specifics will, of course, depend on the requirements and the environment.

Latency, connectivity, throughput, and security are just a few factors that have to be taken into account when designing such a solution.

AI adds context to IoT

IoT can inform about occurrences.

AI, however, can help determine if and what value these occurrences have.

Some examples may include:

Detecting unusual movement patterns

Finding anomalies

Supporting demand or replenishment analysis

Recognizing recurring delays

Evaluating utilization

Identifying potential bottlenecks

It is important to note, however, that AI should not be mistaken for the underlying data architecture.

Poor quality of sensor data, for instance, will inevitably lead to poor quality of analysis.

One of the interesting integration challenges

One of the interesting questions in industrial AIoT is data integration.

A manufacturing environment rarely uses a single application, but rather a set of interconnected solutions.


IoT Devices

↓

Data / Integration Layer

↓

ERP ↔ MES ↔ WMS ↔ EAM

↓

Analytics / AI

↓

Applications

The goal, in this case, is not to unify everything into a single solution, but rather create a connected layer that will allow using information from various systems along with the data from IoT devices.

This is particularly crucial for in-plant logistics, where physical movements and digital processes are deeply interconnected.

Users need a good presentation of information

Another important note concerns the presentation of information.

AI can identify patterns, but it is people who have to understand them.

A good industrial application, therefore, should be able to provide context and explain what is happening in terms that make sense to an operator.

Instead of hundreds of raw events, a user may want to see something along the lines of:


Potential exception detected

Material: Component-482

Expected zone: Production Line 3

Current zone: Staging Area

Status: Delayed movement

The more information that is understandable to a person, the more value the technology brings to the process.

Security and reliability

AIoT technologies connect software to the physical world, which means that the principles of security and reliability should be designed into the solution from the start.

Some of the areas that need to be considered include:

Device authentication

Data integrity

Access control

Network security

Failure handling

Data validation

System monitoring

Backup and recovery

Industrial systems, in particular, should have well-defined behavior in case of connectivity issues or device failures.

AIoT and in-plant logistics

In-plant logistics is one area where many of the above points come together.

Tracking materials, inventory, WIP, vehicles, and other assets can generate a substantial amount of data.

The challenge, however, is to turn this information into actionable insight.

PlantLog AI focuses specifically on applying AIoT technologies to in-plant logistics, including material tracking, asset visibility, inventory management, WIP, and other areas. Developers and engineers interested in the application can take a closer look at the platform here: PlantLog AI.

What developers should focus on

Creating an AIoT system is not a matter of simply adding an AI layer to an existing IoT solution.

The challenge is, rather, the entire pipeline that leads to patterns:

Physical event → reliable data → connectivity → processing → context → AI/analytics → application

If any of these stages is not handled properly, the entire system will fail to deliver.

As a result, developers working on industrial applications have an opportunity to think beyond AI and consider such factors as data architecture, edge processing, integration, security, physical processes, and users.

AIoT becomes valuable when all of these elements combine to create an environment in which connected activity transforms into information that can then improve operations.

Designing Multi-Agent AI Systems for Industrial IoT

Yash Bansal — Mon, 21 Sep 2026 16:54:26 +0000

When introducing AI into a manufacturing environment, often a single model won't have to solve every problem

A production line can represent information on equipment condition, production status, quality, inventory, workers, energy use, and material flow at the same time, all of which can be challenging to treat as a single problem for a monolithic AI model to solve at once.

A multi-agent approach could solve individual problems while coordinating with other agents through shared data and interfaces

Consider an AI architecture like this:




┌────────────────────┐



│ Production Agent │



└─────────┬──────────┘



│



┌────────────────┐ ┌───▼────────────┐ ┌────────────────┐



│ Quality Agent │──►│ Coordination │◄──│ Maintenance │



└────────────────┘ │ Layer │ │ Agent │



└───┬────────────┘ └────────────────┘



│



┌────────▼─────────┐



│ Physical / IoT │



│ Data & Systems │



└──────────────────┘

The individual agents don't have to be making autonomous physical decisions - they can start with observation, prediction, recommendation, and coordination of these processes.

A maintenance agent could see unusual patterns with sensor data from equipment, while a production agent could decide whether that equipment is a current priority to maintain, and a quality agent could give context on whether the equipment was involved in any quality-affecting processes.

The coordination layer could tie these signals together into a more useful view for an operator.

Why IoT Matters

Multi-agent AI systems are interesting when they involve agents that have access to physical world data

IoT devices can give information on

Equipment condition,

asset location,

temperature and environment,

machine activity,

material movement,

production events,

inventory status,

and other factors.

However, these observations have to be interpreted - raw sensor data isn't useful to a AI system without understanding what it's observing and how it relates to other observations about the same physical asset or process.

This is where IoT, sensing, data integration and AI decision-making comes together.

Aperture Venture Studio's work on Physical AI and AIoT describe a similar four-layer architecture, consisting of Identification, Sensing, AI Decision, and Physical AI Action, with research into multi-agent coordination for industrial operations.

Coordination is Harder Than Creating Agents

The challenge in implementing multi-agent AI systems often isn't in creating the individual agents; it's in

defining what each agent should own,

what data it should have access to,

how agents will communicate,

handle conflicting recommendations,

decide what requires human approval,

and how to verify the physical impact of any given action.

These considerations become important when AI stops being only a software application and begins to interact with the physical world and industrial control systems.

For example:




Sensor data



↓



Identification + Sensing



↓



Agent detects abnormal condition



↓



Maintenance recommendation



↓



Production impact analysis



↓



Human / system authorization



↓



Approved action



↓



Physical result verification

This forms a feedback loop rather than an end result, creating an opportunity for humans or systems to examine and evaluate results before proceeding to the next step.

Start With Bounded Tasks

A multi-agent AI system doesn't require you to build fully autonomous manufacturing systems right away

A company could implement a single identified use case, such as:

Step 1 — Observe

Gather and organize reliable data on a particular equipment or process.

Step 2 — Detect

Apply AI to identify patterns or anomalies in the data.

Step 3 — Recommend

Generate a maintenance, quality, scheduling or workflow recommendation based on those patterns.

Step 4 — Coordinate

Allow other systems or agents to provide additional context.

Step 5 — Act

Connect the AI decision to a physical action if appropriate controls, approvals and safety measures are in place.

Step 6 — Verify

Verify that the expected physical result has been achieved.

This approach helps avoid the risks of autonomous manufacturing automation - since a multi-agent system will begin as an analytical tool that only recommends or suggests actions for human operators to take.

This is particularly important in manufacturing, where processes and physical objects often have lasting consequences that regular software applications don't usually have to deal with.

The Bigger Picture: AIoT and Physical AI

What makes multi-agent manufacturing interesting isn't the ability to create multiple chatbots or models to solve problems in isolation.

It's connecting different distributed intelligence systems with the physical state of the world.

A manufacturing system could bring together identification technology, sensors, enterprise data, AI models, digital workflow tools, industrial control systems, and robotics, to form a coherent view of the physical world and how to interact with it. Aperture's current work in AIoT spans implementations of multi-agent industrial coordination, predictive maintenance, inspection processes, material management, and verifiable AI control systems.

This points to an important principle in designing Physical AI systems:

Don't ask one AI system to understand the entire factory. Instead, give specific responsibilities to different systems and develop reliable methods of coordination between the different views of the physical world

Instead of building smarter and more capable monolithic AI systems, the challenge becomes one of building reliable, verifiable, observable, and bounded systems that can safely co-exist with other manufacturing systems and human operators.

AI Can Build a UI in Seconds. What Happens to UI Development Now?

Yash Bansal — Mon, 21 Sep 2026 14:51:17 +0000

AI Can Build a UI in Seconds. What Happens to UI Development Now?

AI-assisted development is taking the frontend world by storm.

Throw a description of a dashboard, landing page or component at an AI coding tool, and it can churn out a working prototype in seconds. It can produce a variety of UIs - HTML/CSS/JS, React components, layout code, forms, variations of the same component, etc.

The obvious question asked by developers then, is

If AI can generate the interface, what is the job of a frontend developer?

AI is Good at Creating the Starting Point

The creation of repetitive UI code has never been the most exciting part of frontend development.

Buttons, cards, tables, navigation, forms - the whole nine yards. These are all common patterns that AI can be great at generating.

A developer can provide a description like:

"Create a responsive manufacturing dashboard showing equipment status, inventory levels, production activity and alerts."

An AI can potentially produce a decent first version of this.

But a first version is rarely a production-ready interface.

The hard questions come later.

What Information Should the Interface Actually Show?

For an industrial application, there are many sources of data that might be relevant to the interface:

IoT sensors, RFID, BLE, manufacturing equipment, ERP platforms, MES, LIMS, QMS, other applications. You name it.

There is no point is shoehorning all of this information into one dashboard - it's too much for any user to process.

The developer needs to determine what information is relevant to different types of users (operations manager, inventory clerk, quality controller, etc.)

It's all about context.

The interface is an information architecture problem, and not just a UI code problem.

AI Doesn't Know About the User

The generated interface may look nice, but it may fail to serve the real user - it may not help them in their day-to-day activities.

Imagine an AI-generated dashboard with twenty charts, all of which are working fine.

But if it takes the average user five minutes to find the information that indicates a production problem, has the computer really done its job?

The developer needs to determine:

What is the user's main job goal? What information is most relevant? What should be shown in greater detail? What should be highlighted? What to do if information is missing? How to present errors? How to make the interface function well on narrow screens? Is the interface accessible? What information should be visible/not visible based on permissions?

There's a lot that goes into context beyond just the information that needs to be shown.

The Developer's Job Is Changing

Frontend development with AI-assisted development tools may lead to changes in what the developer does. One possibility is that the developer moves towards the following areas in application development:

1. System Architecture

Rather than writing generic UI components, the developer spends more time figuring out how to organize the application - how components, APIs, state management, security, and databases will fit together.

2. Design Systems

While individual UI components can be generated by AI, creating consistent spacing, typography, accessibility, interaction design, responsive behavior and component architecture requires a design system.

3. Data Visualization

Industrial applications can generate a ton of information.

But just throwing it into a chart or table isn't enough to turn that data into information.

The developer needs to determine how best to visualize data as charts, timelines, alerts, tables, or other means that help the user get information from the data.

4. Edge Cases

The generated code may focus on the "main path", but there are always edge cases in production software. What if the user loses connectivity? What if an API returns an error? What if a sensor stops sending information? What if a permission is denied? How should the interface respond to these situations?

5. Domain Knowledge

This can be crucial for certain applications.

A developer who knows the domain of the application can better ask the right questions and see issues that a general-purpose code generator may not.

This is especially the case in specialized fields such as pharma manufacturing.

AIoT platforms in the space can connect asset intelligence, inventory intelligence, process intelligence and manufacturing traceability. PharmaFlux AI

The UI developer for such systems is not just writing UI code, they're helping users understand a complex operational world.

So, Is UI Development Going Away?

Not in the simple sense of "AI writes code, so developers are unneeded".

But the nature of the developer's job is changing.

The developer may need to spend less time on repetitive coding tasks, and more time on reviewing and enhancing the generated code, evaluating architecture, making sure the interface serves the user, testing the code's edge cases, connecting different systems, and determining what information should be shown.

The most important skills for the developer may shift from simply knowing how to write generic UI code, to understanding the application's requirements, making choices about its information architecture, and knowing if the generated code is really fit for purpose.

The developer still needs to understand the problem that the code is supposed to address.

Tell me what you think.

If AI can generate most basic UI components, what should frontend developers be focusing on?

UX design? System architecture? Accessibility? Performance? AI-assisted development? Domain knowledge?

I'd be interested to hear from other developers on how they see this space evolving.