Daizy CTO Richard Norris on why the value of AI in IoT turns less on the model and more on the context behind every reading — and how the platform was built, from day one, to supply it.
Richard Norris — Chief Technology Officer, Daizy · 31 min read
Introduction
Richard, for readers who may not know you, can you tell us a little about your background and your journey into IoT?
I’ve been a software engineer for over twenty years. I spent the early part of my career at Status Computers as principal architect, and in that job I did pretty much everything: business networks, datacentre hardware, PC and software rollouts, bespoke systems for SMEs and local government. It was a very broad grounding. You learn quickly that the clever part of a system is rarely the part that fails. It’s the boring operational detail that gets you.
As virtualisation turned into cloud, I moved further into software, but I kept hold of the infrastructure side, designing and running the environments as well as the code on top of them. Around the middle of the last decade, I set up a partnership to bring technical innovation to businesses locally, and I ended up co-running a seed funding programme called Seedhub, alongside a Google Startup Grind event that was hosted at our co-working space. The idea was to put entrepreneurs and independent technical people in the same room so ideas could actually get built and funded. I spent a few years helping founders take things from a sketch to an MVP — a lot of blockchain and machine learning at the time, a lot of proofs of concept.
Daizy was born inside that programme. It wasn’t a company I joined; it was an idea I helped shape from the first conversations. I supported it independently at first, then it became obvious to me that I’d found an industry I actually cared about, and I joined full time in 2020 as VP of Engineering. I’ve been CTO since 2022, and I’ve been responsible for the architecture of the platform from its inception through to what it is now.
You’ve spent many years building technology businesses and solving real-world data and connectivity challenges. What originally attracted you to the IoT sector, and what lessons have shaped your view of where the market is heading?
It started with tinkering, and it wasn’t especially strategic. We had kits all over the desks — Raspberry Pis, Arduinos, ESP32 modules, a pile of different connectivity kits and all sorts of tooling. We were building things for our own workspace, mostly because we could. An automated door entry system so members could get into the building. A connected music system running on Raspberry Pis. People counting. At one point we were scanning Wi-Fi MAC addresses to work out who was in the room, which was a perfectly reasonable thing to be doing at the time and would get you into a great deal of trouble now.
None of it was product work. It was us finding out what the technology could actually do, and what we found was that LPWAN hardware had crossed a threshold in terms of accessibility. Devices had suddenly become genuinely capable and genuinely cheap at the same time, and every network service had tools and a portal. You could take a sensor out of a box in the morning and have it reporting real readings by the afternoon. That is a very seductive experience for an engineer, and it made the whole sector look solved. On paper the barrier had gone.
The barriers only appeared when we pushed further, and they appeared one at a time. The onboarding process was lengthy and error prone. When adding a different type of device, it described the world completely differently, so now we were writing a mess of code and codecs. We wanted to put something somewhere real, rather than on a desk, and coverage turned into a question we couldn’t answer from the office. Multiple devices became a headache, registering them one at a time. Somebody asked which sensor was in which room, and the honest answer was that it was in a spreadsheet, and the spreadsheet was already wrong. Then one stopped reporting, and we had no quick way of telling whether that was the device, the battery, the network or something at our end.
None of those are hard problems individually. That’s exactly why they’re dangerous. Each one looks like an afternoon’s work, so you solve it and move on, and you don’t notice that you’ve quietly started building a platform instead of building a product.
So the barrier hadn’t gone. It had only moved. It was easy to prototype, and anyone could get a handful of devices reporting into a dashboard in a fortnight. What nobody had solved was everything after that. There was nothing that made it easy to go from a handful of devices to twenty thousand, or to keep them running for seven years afterwards. You had to build all of it yourself. Deployment was challenging and management was worse.
That’s the lesson that has shaped everything since, and it’s still the thing I’d argue about with most people in this industry. Most of this market optimises for getting devices onto the wall. Installation is the easy ten percent. Almost nobody plans properly for the next seven years of that device’s life, and that is precisely where projects die. There are a lot of very capable solution providers out there who don’t yet recognise how much risk they’re carrying, because they have no tooling for in-life management.
I’m not saying anyone’s being careless. The tooling for installation matured years before the tooling for management did, so the industry quite reasonably built the habits that the available tools allowed. Closing that gap is what I’ve spent the last few years doing.
Setting the scene
1. What is Daizy, and what problem does it solve?
For readers who are new to Daizy, how would you describe the company and its role within the IoT ecosystem?
The short version that I give people is that Daizy helps businesses deploy monitoring solutions of any kind, at scale, with confidence, and with the context that turns readings into insight.
The longer version is that we’re an open enterprise IoT management platform. We sit between the physical estate — meaning the devices, the gateways and the connectivity — and the business systems that actually need the data.
I’d stress that second half, because people tend to hear “IoT management platform” and picture device administration. That’s part of it, but it isn’t the point of it. Nobody deploys sensors because they want an inventory. They deploy sensors because they want to know something about the real world that they couldn’t previously know, and they want that knowledge to arrive somewhere useful, in a form their business can act on. Managing the devices well is simply the price of getting trustworthy data out of them.
So the way I’d describe our role is that we turn a physical estate into a reliable data asset. The device management, the connectivity, the monitoring — all of that exists in service of the data being correct, complete and meaningful when it lands. If the estate is well managed and the data still arrives as an anonymous stream of numbers, we haven’t done our job.
The role we play in the ecosystem is deliberately not a vertical one. We’re not a damp and mould product, or a cold chain product, or an asset tracking product, even though our platform sits underneath all of those. We’re the layer that makes any of them viable at scale, which is why our customers span facilities management, housing, healthcare, logistics, agriculture, smart cities and utilities without us having to rebuild anything for each of them.
Many organisations struggle with device diversity, connectivity management, and data integration. How does Daizy simplify those challenges?
By being genuinely agnostic on both device and connectivity, and by meaning it.
On devices, we normalise across more than five hundred device models and we’re compatible with thousands. On connectivity, we support NB-IoT, LTE-M, LoRaWAN, Sigfox and 4G/5G, and we support bringing your own. We do sell connectivity, but we deliberately don’t lock you into it, and we support a wide range of third-party network services alongside our own. That’s an important distinction. A lot of platforms are really a shop window for one network.
The reason that matters isn’t ideological, it’s economic. The moment you commit to a single device family or a single network, you’ve started building a vertical silo. Then the next use case needs a different sensor, or better coverage, so you build a second silo. Now you’re running two of everything: two management tools, two data formats, two support processes, two sets of people who know how it works. Cost and complexity compound quietly.
But the silo problem that really hurts is the one in your data, and it’s the one people notice last. Each silo feeds your warehouse in its own shape, with its own field names, its own units, its own idea of what a reading means. Your analytics team then spends its life writing reconciliation logic, and every new deployment adds another dialect they have to learn. That’s the tax nobody budgets for, and it’s the reason so many IoT programmes produce dashboards but never produce insight.
What we give you instead is a single window into your entire estate, and more importantly a single vocabulary coming out of it. One place where every device, every network and every site lives, with one common way of describing what they’re telling you, flowing into your own systems and data warehouses in a consistent shape regardless of what generated it. You can mix and match technology freely, because the platform absorbs the difference before it ever reaches your business. That’s the simplification. Not that any individual task becomes easier, but that you stop multiplying the number of things your organisation has to understand.
2. Why is context so important in IoT?
Daizy often talks about contextualised IoT data rather than simply collecting telemetry. Why is context such an important part of delivering value from connected assets?
Because a temperature reading on its own is very nearly worthless. It’s a number with no subject. Before anyone can do anything with it, somebody or something has to answer the question “the temperature of what?”, and if that answer isn’t captured as data, it’s living in somebody’s head or in a spreadsheet, which means it isn’t really captured at all.
Most people key their analysis to the device. That’s the wrong way round, and we spotted it early. The device is important operationally, because you need to know its battery state, its signal and its firmware, but it is not the thing you actually care about. The thing you care about is the fridge, or the room, or the property, or the person. The sensor is just how you find out about it.
So we decoupled the two. We have a tool called Project Composer that lets you build a topology of the assets you’re monitoring: the sites, the locations, the things. Then we introduced the concept of a position, which loosely couples a device, by type, to a place in that topology. The device is attached to the position, and the position is attached to the asset. Alongside that we maintain what we call a shadow, which is the full picture of an asset at a given position, retrievable on the fly — its attributes, its configuration, its location, and any internal or external references the customer needs to tie it back to their own systems. The industry would call that a digital twin.
The point of all this is that context becomes a property of the data itself rather than an act of interpretation performed later. When a reading arrives, it already knows what it’s a reading of, where that thing is, what it belongs to, and what the customer calls it. It’s self-describing at the point of capture. That’s the difference between a data lake and a data asset.
And the payoff is compounding, because context is the part you can’t reconstruct. You can always go back and recalculate an average. You cannot go back and remember which room sensor 4471 was in for the eighteen months before someone moved it.
The most obvious version of that shows up in year three, when a device fails. You swap it out, the position is unchanged, and your history is completely intact, because you’ve been tracking the location and the position all along and it genuinely doesn’t matter that the hardware underneath changed. Key everything to the device instead, and the day it dies you’ve orphaned your data.
This is also, incidentally, why so many IoT pilots mislead people. Prototyping got so easy that it became misleading. The very thing that lets you stand up a proof of concept in a fortnight — meaning twenty devices, one type, one network and a spreadsheet — is exactly what hides how hard year two is going to be. People mistake a working prototype for a working business case.
What information does an AI system need beyond sensor readings to make useful operational decisions?
Effectively everything I’ve just described, and it needs it in a form it can reason about.
If I hand a model a stream of numbers, the best it can do is spot a pattern in the numbers. If I hand it a normalised temperature measurement, attached to a position, attached to a cold storage unit, in a named location, in a named site, belonging to a named project, with the device’s battery level and last seen time alongside it, and the customer’s own asset reference attached — now it can tell me something useful. Now it can say this specific unit in this specific building has been drifting for six days, the sensor is healthy, so it isn’t a data problem, and here are the three other units on the same site showing the same pattern.
That second version isn’t a smarter model. It’s the same model with context.
There’s a hierarchy to it worth spelling out. Identity, meaning what this thing is. Location, meaning where it sits in a structure that a human would recognise. Purpose, meaning what it’s attached to and why anyone is monitoring it. Health, meaning whether the reading can be trusted right now. Relationship, meaning what else sits nearby or serves the same function. And reference, meaning what the customer’s own systems call it, so a conclusion can be acted on rather than admired.
Strip any one of those out and the quality of the answer degrades sharply. Most organisations capture the first and last reasonably well and lose everything in the middle, which is why their data is technically complete and practically unusable.
Why MCP?
3. Why was MCP a natural next step for Daizy?
Daizy has recently introduced Daizy Connect, providing MCP-based access to IoT estates. Why did MCP feel like an obvious extension of the platform?
Because we’d spent the time building the foundations it needs, deliberately, with AI in mind.
We pushed contextualisation from day one and the reason was machine learning. We could see even then that data volume alone wasn’t going to be the differentiator, and that customers would want to run serious analysis over this eventually. Raw telemetry with no context is almost impossible to do anything meaningful with. So we built the asset model, the normalisation and the metadata layer specifically so that customer data would be ready for that when they wanted it.
What we were anticipating was analysis. Better anomaly detection, better prediction, better optimisation, all of it running over datasets that were rich enough to support it.
What we hadn’t anticipated was the other thing. Through 2025 the acceleration in the large language model space became impossible to ignore, and towards the end of the year it became obvious what was actually happening. These tools are becoming a new human interface. Not a feature you bolt onto software, but a replacement for a great deal of the interface we currently build to let people orchestrate tools. That’s a significant thing to realise when your product is a portal.
So MCP opened up an opportunity that sat well beyond the analytical one we’d been building towards. It’s the ability to orchestrate, to report, to alert and to interrogate everything in the platform: the whole inventory, all the context, all the metadata, not just the telemetry. IoT is big data, and AI is fundamentally about extracting value from big data. But big data here was never only the readings. It’s the context and the meta information sitting behind them, which is exactly what we’d been accumulating.
And there’s an operational argument on top of the analytical one. As estates get bigger, running them gets disproportionately harder. Being able to reach operational help through an assistant, rather than through training, documentation and portal navigation, is simply where management and maintenance is going.
4. What challenge does MCP solve that APIs alone do not?
Most enterprise platforms already expose APIs. From a technical perspective, what additional value does MCP bring for customers looking to leverage AI assistants?
Our API is open and it’s well specified. We use OpenAPI standards precisely to make it easy to consume. But an API still has a hard prerequisite: somebody has to learn it. A developer reads the documentation, works out which endpoints matter, writes the integration and maintains it. That’s a project. It has a cost, a queue position and a person attached to it.
MCP removes the prerequisite. The tools are self-describing, so the model discovers what’s available, understands what each one is for, and chains them together without anyone building anything. The integration work that used to sit between a customer and their own data essentially disappears.
The consequence of that is the part I find genuinely interesting, because it isn’t really technical. It means you don’t have to be technical to get value. A business leader, an operations manager, a facilities lead — people who would never have written against our API and would never have raised a ticket asking someone else to — can now just ask. The only technical step is installing the tool in the first place, and that’s straightforward. We support both OAuth2 and API key authentication, and with OAuth2 you log in to Daizy interactively through your preferred assistant, exactly as you would log in to the Daizy portal.
An API opens your platform to developers. MCP opens it to everybody else.
5. Did AI create a new opportunity for IoT?
The industry has talked about connecting physical assets for years. Has the rise of AI created a new urgency or opportunity for organisations to make their IoT environments more accessible?
It’s created urgency, and I’d say it’s created it in an unexpected place.
The opportunity everyone expects is analytical, meaning better anomaly detection, better prediction, better optimisation. That’s real, it’s coming, and it’s the reason we built the platform the way we did.
But the more immediate opportunity is about access. IoT has always had an adoption problem that nobody talks about honestly. You deploy a capable platform, you train people on it, and then a large proportion of the functionality goes unused. Not because it doesn’t work, but because the person who needed it didn’t know it existed, or didn’t have time to go and find it, or wasn’t confident enough to try. We see it in our own support load. We’ve built good network diagnostic tools, and we still spend time educating customers to use them rather than asking us.
What MCP does is remove the need for the user to take the initiative. They don’t have to know the tool exists. They ask the assistant whether a device is healthy, and the assistant finds and uses the right tool through self-discovery. The customer gets the benefit of capability they never learned. That saves an enormous amount of training, and more importantly it saves an enormous amount of cultural change. Cultural change is the expensive part of any platform rollout.
How do you see AI and IoT evolving together over the next few years?
They’re a natural fit, and I think the relationship becomes symbiotic fairly quickly. IoT generates exactly the kind of high volume, high context, real world data that these models are hungry for, and models provide exactly the interface layer that IoT has always struggled to make accessible.
What I’d expect to see first is the assistant becoming the default way people interrogate their estate, displacing a good deal of dashboard use. After that it moves from asking to doing, and that transition is the significant one. That’s where the governance conversation gets serious, and it’s why we’ve approached the whole thing the way we have.
Technical deep dive
6. How does Daizy Connect expose IoT estate information to AI?
Can you explain how Daizy Connect enables AI assistants to discover, understand, and interact with devices, assets, and operational information across an IoT deployment?
Daizy Connect is an MCP server that exposes the platform as a set of discrete, described tools. You connect it to whichever assistant you use — whether that’s Claude, ChatGPT, Gemini or Cursor — you authenticate with OAuth2 or an API key, and from that point the assistant can see what’s available and reason about it.
The surface deliberately mirrors how the platform models the world rather than how our database is arranged. So there are tools for device inventory: listing devices, retrieving an individual device, pulling its shadow, its version, its audit history, and the catalogue entry that describes what that model is and what it’s capable of. There are tools for gateways and gateway status. There’s the geospatial and structural layer, covering sites, the devices at a site, locations and positions. There are projects and project summaries, and organisation level summaries above those. There’s the connectivity and commercial side, covering SIMs, subscriptions, usage and subscription audit. There are configuration profiles. And there’s an access tool that tells the assistant precisely what this user is entitled to see.
The important design point is that these aren’t thin wrappers over database tables. Each one is a considered operation that returns something an assistant can actually reason about, because it comes back in the platform’s own vocabulary — normalised metrics, positions, assets, sites, rather than device specific dialect.
The first release was focused on inventory and estate health, and that alone changes the experience considerably. Our portal, alerts and integrations have always given customers current information about their estate. What this adds is the ability to pull it instantly, in whatever shape you happen to need at that moment, and to have something reason about what it’s seeing and suggest what might be going on operationally. You’re no longer limited to the questions someone anticipated when they designed the screen.
The next major push is onboarding, making it dramatically simpler to bring inventory into the platform at scale and to attach rich context as you do it, using MCP and AI to carry the load. That’s what we’ll be showing at the Alliot event. After that comes deep data insight, with queryable telemetry and full history through the same interface.
7. What architectural foundations made MCP integration possible?
Looking at the Daizy platform itself, which architectural principles made it relatively straightforward to support MCP?
We built with AI in mind. We just built for the AI we expected.
From very early on we were pushing customers to contextualise, because we knew that machine learning was coming and that datasets without context would be worthless to it. So the foundations were laid deliberately for AI consumption. What we were designing for was analysis. What arrived instead — or rather what arrived as well — was automation of inventory and operations, and a conversational interface on top. That part nobody predicted. The satisfying thing is that the foundations turned out to serve both, because good context is good context regardless of what consumes it.
Six things carried the weight, and they’re all load-bearing for the platform in their own right. MCP simply makes them far easier to work with.
Device abstraction and the device catalogue mean the platform reasons about a device by its type and capability rather than its make and model. An assistant never needs to know the quirks of a particular manufacturer’s payload, because nothing above the ingest layer does.
Data normalisation gives everything a shared vocabulary. I’d argue this is the single most important one for AI, and I’ll come to why in a moment.
Asset modelling — meaning the project topology and the position concept — is what makes an answer meaningful rather than merely accurate. Without it an assistant can tell you a device is cold. With it, it can tell you a cold storage unit in a named building is failing.
Metadata management and the shadow supply the context: attributes, configuration, and references into the customer’s own systems. That’s what lets an assistant connect what it sees to what the business actually calls it.
Open APIs, built to OpenAPI standards, meant the MCP layer had a properly specified, well behaved foundation to sit on rather than something we’d have had to invent underneath it.
And workflow orchestration is what turns all of the above from a reporting exercise into something that can act.
If any one of those had been missing this would have been a rebuild rather than an extension. The one that would have stopped us dead is the asset model, because you cannot retrofit it. If you’ve spent five years keying customer data to device identifiers, there is no clever layer you can add on top that recovers meaning you never captured. That’s the argument I’d make to anyone building an IoT estate today, whatever platform they’re on. Get the context right now, because the analysis you’ll want in three years can be added later, and the context can’t.
8. Why is data normalisation important for AI consumption?
Daizy supports a wide range of device types and communication technologies. How important is data normalisation when making IoT information useful for AI-powered workflows?
It’s foundational, and I’d put it at the top of the list.
We have a concept called Daizy metrics. They normalise telemetry across different device types, so whatever hardware you’re using, the data arrives in a consistent form. Temperature is temperature, in the same units, with the same semantics, whether it came from a LoRaWAN sensor from one manufacturer or an NB-IoT device from another.
For operations that’s already valuable, because it’s what makes swapping a device in life trivial. You’re tracking the location and the positions at that location, so the hardware underneath can change and nothing downstream cares.
For AI it’s the difference between working and not working. Language models are extremely good at language and reasoning, and extremely poor at guessing the meaning of a proprietary schema they’ve never seen. Give an assistant raw payloads from forty device families and you’ve handed it forty puzzles to solve before it can do anything useful, and it will make confident mistakes on some of them. Give it one normalised vocabulary that maps cleanly onto real world concepts, and it can spend all of its effort on the actual question.
Normalisation is what turns a large, messy estate into something that can be reasoned about as a single system. Without it, being agnostic is a marketing claim. With it, it’s an operational fact.
9. How does Daizy maintain trust in the data provided to AI?
Enterprise customers will naturally ask about accuracy and governance. How does Daizy ensure that the data and contextual information presented through MCP remains trustworthy, consistent, and operationally relevant?
We’ve approached MCP on a zero-trust basis and treated it as its own security boundary from the start.
The first thing to say is that the MCP layer is not a passthrough to our API. Every tool is deliberately designed. We decide what it does, what it returns, and exactly which API access it uses. That’s a conscious constraint rather than a convenience, and it means there’s no path where a capability leaks out simply because an endpoint happened to exist.
Second, the MCP server reaches the platform only through our API. It has no direct access to the infrastructure or the data underneath. That’s a core architectural restriction and it isn’t negotiable.
Third, our API recognises an MCP user as a distinct kind of caller. Because we treat it as a non-standard access path, we can constrain it further and independently of normal API access. The permissions model is customisable, and it’s separated rather than inherited.
Fourth, we audit at the MCP layer. Every action and behaviour is tracked, so we can analyse what’s actually being asked and done. That matters for security, and it also matters for building the next set of tools properly.
And the first release was deliberately read only. That wasn’t a limitation we ran out of time to fix. It was the right place to start.
On the accuracy side, the answer is really everything we’ve already discussed. The reason an assistant gives a trustworthy answer about a Daizy estate is that it isn’t inferring anything. It’s reading a normalised, contextualised model that the platform maintains as a matter of course. It doesn’t have to guess what a device is, what it’s attached to, or what its readings mean, because all of that is explicit. Most AI accuracy problems in this space aren’t model problems. They’re context problems.
Enterprise customer perspective
10. What are the most compelling use cases for enterprise customers today?
If you’re speaking to a facilities management company, healthcare provider, logistics business, or large enterprise estate operator, where do you see the biggest opportunities to use MCP-enabled AI?
The most compelling ones today are the unglamorous ones, and I’d group them into three.
The first is estate awareness. Any operator running thousands of devices across hundreds of sites has a standing question they can never quite answer: what have I actually got, where is it, and is it working? Today that’s a portal session, an export, and often a spreadsheet. With an assistant it’s a question. And it’s not a fixed question, because you can ask it in whatever shape the situation demands. That’s exactly what a dashboard can’t do, since a dashboard can only answer what was anticipated when it was designed.
The second is diagnostics. When something stops reporting, the work is a chain of small checks. Is the device alive, is the battery flat, is it a coverage problem, is the gateway healthy, when did it last check in, has anything changed. Every one of those is a discrete lookup, and the skill is knowing the order to do them in. That’s precisely the kind of reasoning chain an assistant handles well.
The third is onboarding at scale, which is where we’re heading next. Bringing a large batch of devices into a platform and attaching meaningful context to every one of them is currently the most tedious job in this industry, and it’s the point at which people cut corners. That’s exactly how you end up with an estate you can’t manage in year three.
Let me give you the shape of the problem with a real example. We had an early customer who’d deployed thousands of LoRaWAN devices into people’s homes, so physical access was severely limited. They were managing the inventory on spreadsheets, and the spreadsheets were out of date. They couldn’t identify faulty devices with the tools they had. Deployments were taking far too long. They were, frankly, in chaos.
We migrated their devices into the platform to establish a baseline, because a full re-audit simply wasn’t possible given how they’d been managing it. Once that was done, they could finally see where their inventory was, what state it was in, and what coverage they had.
But they’d engaged too late, and the company didn’t survive. We kept the engagement alive and brokered a transfer to another customer who took the relationship on. The point I take from it is this. The technology hadn’t failed them. They’d failed to recognise the complexity of managing IoT at scale early enough. That’s the failure mode I’d want every enterprise operator to have in mind.
11. How can AI reduce operational effort?
Today many IoT teams spend significant time managing devices, troubleshooting issues, and maintaining inventories. How does MCP change the daily operational experience for those teams?
Let me start with what the platform already does, because MCP is a multiplier on it rather than a replacement for it.
Onboarding and network registration is the first big cost, and Daizy lets you do it in bulk rather than device by device. There are validation rules in the process, so you save time and you avoid the errors that individual manual operations introduce. If you need rigour instead of speed, you can install device by device with rules and gates enforcing your process. Both are supported, because different customers genuinely need different things.
In-life monitoring is on by default, so you have oversight of estate health from the moment devices land rather than as something you configure later. Network mapping tools let you diagnose and review radio issues. And you can mix and match telemetry and events in the integrations feeding your own systems and data warehouses.
What MCP changes is who can reach all of that, and how much they need to know first. Today, using a diagnostic tool requires knowing it exists, knowing where it is, and being confident enough to use it. That’s three barriers, and in practice a lot of people fall at one of them and raise a ticket instead, which lands on us or on the partner.
With MCP the user just asks. The assistant discovers the right tool and uses it. The person gets an answer without ever having learned the platform. That’s a substantial reduction in effort, but more than that it’s a reduction in required expertise, which is the harder constraint for most teams to solve.
12. What measurable time and cost savings could customers expect?
Without giving away confidential numbers, where do you see customers creating value?
I’d point at four areas, and I’d be honest that the shape of the saving has changed over time.
Deployment speed is the most immediate. Bulk onboarding and registration versus individual operations is not a marginal improvement, it’s a different order of work, and the validation rules mean you’re not paying for it later in rework. iOpt are a good published example. They migrated two thousand live LoRaWAN devices onto the platform with zero downtime, which gives you a sense of the scale these operations run at and of what has to be true underneath for that to be possible.
Support overhead is the second, and this is where it gets interesting. Onboarding genuinely isn’t the main burden any more. Connectivity questions are. Our network diagnostic tools have reduced that load considerably, but we’re still educating users to self-serve rather than ask. What we expect from MCP is that they no longer need to take the initiative at all. If someone asks their assistant to check a device instead of asking us, they’re using tooling we already built without ever having to discover it. That removes a support cost, and it removes a training and cultural cost that’s much harder to quantify but is often larger.
Engineer productivity is the third. If your specialists are answering “is this device working?” all day, they aren’t doing the work you actually hired them for.
And the fourth, which I’d argue is the biggest and the least visible, is avoided failure. The customer I described earlier didn’t lose money on inefficiency. They lost the business. Nobody puts “didn’t collapse in year three” on a savings slide, but it’s the number that matters most.
VAR & channel partner perspective
13. Why should VARs and channel partners be excited about MCP?
Many partners are looking for ways to differentiate their solutions. How does AI-enabled access to IoT estates create new service opportunities for the channel?
Our partners generally make money in three places: the hardware, the installation, and the resale of the platform and connectivity underneath. The service wrapper around that is where the margin and the stickiness live. VARs typically give the customer direct access to the platform, whereas MSPs more often hold it themselves and sell the outcome as a managed service. Both models work, and both benefit here.
What MCP adds is a differentiator that’s genuinely hard for a competitor to match, because it isn’t a feature. It’s a property of the platform underneath. A partner can now hand a customer an estate that their own non-technical staff can interrogate in plain language on day one. No training programme, no portal onboarding, no session showing the team how to use the dashboard that half of them miss.
There’s also a straightforward new service line in it. Helping customers connect their assistants, scoping what their teams should be able to reach, and building the operational habits around it. That’s advisory work with recurring value attached.
But I’d give partners a warning alongside the opportunity, and I’d rather say it plainly. Growing device counts ought to frighten you, not excite you. Until you’ve solved in-life management, every device you add is a liability with a support ticket attached to it. The partners who understand that are the ones who’ll still be profitable at scale.
14. How does MCP help partners scale deployments?
One of the biggest challenges for partners is growing device counts without growing support costs at the same rate. How can MCP-enabled automation help partners manage larger estates more efficiently?
That challenge is the one I’d put at the centre of this whole conversation, because it’s where the economics of the channel are decided.
The blunt reality is that engineer to device ratios don’t scale on their own. Without a management platform underneath, support cost tracks device count almost linearly. Every additional device is another thing that can stop reporting, another thing someone has to go and look at. Add more customers and more sites on top and it gets worse than linear, because you’ve also multiplied the number of contexts your engineers have to hold in their heads.
Two things break that curve. The first is the platform itself: bulk operations, monitoring on by default, and diagnostics that work the same way across every device type and every network. That’s what stops a partner needing a specialist per technology.
The second is handover, which I think is underrated. Because we make onboarding straightforward for the partner, we also make the handover to the customer straightforward. Once devices are in the platform, the customer can manage the inventory directly. The partner isn’t stuck as a permanent intermediary for routine questions they were never really adding value to.
MCP accelerates both. Onboarding at scale with rich context is where we’re taking it next. And on the support side, the questions that reach a partner’s helpdesk are overwhelmingly the ones the platform can already answer. Is it online, is the battery flat, is it a coverage problem. If the customer’s own assistant answers those, the partner’s helpdesk stops absorbing them. That’s how you grow device counts without growing headcount in step.
15. Looking ahead, what’s your vision for AI-driven IoT operations?
If we revisit this conversation in two or three years’ time, what do you think will have changed? Do you believe we’ll see a future where AI agents are routinely assisting with device onboarding, diagnostics, lifecycle management, and operational optimisation across entire IoT estates?
In two or three years I think agents could be doing most of it. Onboarding, monitoring, responding, proactively fixing what can be fixed remotely, and automating escalation for what can’t. The full tool suite should give extensive access to the platform. In terms of what’s technically possible the sky is the limit, and I’d rather not pretend to know exactly where it lands. Time will tell.
What I’m more confident about is the shape of how we get there, and it isn’t a single leap. The obvious sequence is asking, then suggesting, then acting under supervision, then acting autonomously within tightly scoped boundaries. Each of those steps requires more trust than the one before it, and trust is earned operationally rather than granted architecturally.
Which is why our position on destructive operations is deliberate. As we extend beyond read only, we’ll be making customers explicitly aware of which operations are scoped as potentially destructive, so agents are not automatically granted the ability to do harm. That’s a design principle, not a feature we’ll add later. The interesting engineering problem over the next few years isn’t giving agents more capability, because that part is comparatively easy. It’s giving them the right capability, with the right boundaries, in a way an enterprise can actually govern and audit.
Closing
If you could give one piece of advice to enterprises considering how AI and IoT fit together, what would it be?
The fit between the two is simpler than people tend to make it sound. AI is only ever as good as the context it’s given, and IoT is the largest source of real-world context most businesses will ever have. Your estate already knows things about your buildings, your assets and your operations that nobody in your organisation could tell you. The problem has never been that the data isn’t there. It’s that it arrives without meaning attached, and an assistant can’t reason about a number any better than a person can.
So my advice comes in two halves, and the first half isn’t really about AI at all.
Get your context in order, and do it now, whatever you eventually decide about any of this. Decouple the thing you’re monitoring from the device that monitors it. Normalise your telemetry so a reading means the same thing regardless of what produced it. Capture the metadata: the asset, the location, the configuration, the reference your own business systems already use. None of that is AI work. It’s data discipline, and it earns its keep in day-to-day operations long before a model ever touches it. But it is exactly the difference between an estate an assistant can reason about and one it can only guess at. And it’s the one part you cannot retrofit. You can add analysis in three years. You cannot go back and recover context you never captured.
The second half is to embrace AI with IoT, learn it, and be pragmatic about it. Don’t ignore this. These tools are going to change the way we work and the way we engage with systems, and I don’t think that’s seriously in doubt any more. But I don’t expect anyone to fully automate everything from day one, and I think trying would be a mistake. We’re early. The tooling will be ready before the culture and the management practices around it are, and that gap is where organisations get hurt.
So don’t put all your eggs in one basket, and don’t commit your entire strategy to AI. Start where the risk is low and the tedium is high, which in IoT means visibility and diagnostics rather than control. Put guards and measures in place. Make sure human oversight genuinely exists rather than existing on a slide. Then extend it as the trust is earned, because it is earned rather than assumed.
There are very large productivity gains available here and you should go and get them. Just go and get them deliberately.
And if there’s one line to take away from all of this, it’s that the businesses that win with AI won’t be the ones that adopted it first. They’ll be the ones whose data was ready when they did.
About Daizy
Daizy is an open enterprise IoT management platform that turns a physical estate into a reliable, contextualised data asset — agnostic across devices and connectivity, and built so that data is ready for AI. daizy.io
