When we initially created flespi 10 years ago, the only thing we really understood about integration was that we needed to provide a good REST API. And the one we created back then wasn’t bad at all. Over the next decade, we barely had to change any of its API entities, and we have no plans to do so in the future.
As time went by, we mostly introduced new API entities as the platform evolved and gained new features. Changing an API is too painful for users, so we have always tried to stick to what we already have and minimize changes.
Later, to simplify data ingestion into integrations, we created streams in 2017. Within just a few months, we realized that streams pushing data to 3rd-party infrastructure were not flexible enough. So, in 2018, we opened public access to our MQTT Broker, allowing users to define through MQTT subscriptions exactly what kind of information they wanted to receive in their integrations.
These three methods for consuming telematics data from flespi in a 3rd-party application – REST, streams, and MQTT – are still fully relevant and up to date today. In 2023, Jan Bartnitsky gave a great overview of all three at the flespi conference.
For a long time, what we delivered was a stable, simple, and efficient REST API, and whenever our users needed some customization, the answer was clear – develop your own integration, host it in your cloud infrastructure, consume data from flespi, and do whatever you need with it.
However, the demand for integrated data customization while avoiding any additional integration was quickly growing. More and more, our users wanted the flexibility to preprocess telematics data on the flespi side, offloading various customizations to the platform instead of handling them in their own integrations.
In response to this demand, in 2020 we released plugins, allowing users to perform rule-based preprocessing of device messages even before they were stored in the flespi database or published to MQTT. The demand for flexibility was so strong that just a year later, in 2021, we released PVM-code plugins – essentially giving users the ability to perform any kind of preprocessing with custom code. By the way, if you missed it, I suggest watching this video from our conference, where Nadzeya Mikhailava gives a great overview of how plugins work with the core flespi entities.
But it was not enough. Once we provided the possibility to preprocess the data, our users started to demand more. Now they wanted automation – combining everything together. If this, then that, you know? And this or that can be anything – device created, connected, disconnected, new message received, command executed or failed, stream buffer grown too much, and so on.
Internally, we had a lot of talks about how to do this efficiently. We were already engineers with 20 years of experience in product development and mostly the authors of what you see in today’s Wialon Hosting; e.g., look at its reports. We know that demand will be complex, and the simple solution will eventually become the crocodile.
For example, let’s take the simplest one – automatically creating devices when they connect to the channel for the first time. It sounds like just a checkbox, doesn’t it?
OK, going further, the only thing we may need on top of that checkbox is device type selection when it cannot be detected automatically. Well, then maybe you will need a template for device configuration – a name, message rotation and retention, settings polling configuration? You see, it’s already not a checkbox.
Let’s continue. Check user roles in realms, and you will see the trend – you may want to specify a subaccount where the device should be created, automatically provision access to certain users, and so on. So it is not a checkbox. It is a really complex configuration for each channel, designed to serve the distinct needs of each particular user.
And it was just one simple need. We had dozens of other automations requested, so we took another route. In 2023, we created webhooks, where users could create their own automations. Later, we added chained request processing to enable multi-step processing. And here is a great overview of zero-scripting automation by Jan from our conference.
And this is how we lived until now. The last automation we recently talked about was a scheduler for tachographs. Today, it is a simple option – which slots to query and what interval to use. But the demand in the market is not really for simplicity. Each company wants its own flexible configuration of when and which files to retrieve.
And Evgeny Shatilo, who is responsible for tachographs and regularly interacts with users, is the person who knows what the market needs. He kept pushing us to embed one crazy-flexible scheduler into tacho-enabled channel configurations, while the rest of our team kept resisting.
So yesterday I came to him and said:
– The scheduler is solved.
– How? – asked Evgeny.
– A flespi AI agent, – I answered.
– I don't believe you. I know AI. And I know tacho. It's too complex, – Evgeny replied.
– Try it.
So Evgeny didn’t believe me, but he created an AI agent in his flespi account, where a tacho-enabled device was connected, and started hammering it with one task after another.
Two hours later, he came to me and said:
– It somehow works. I still don't trust it, but it works.
And asked about the cost. In his case, the setup cost for this automation was around €5, with an estimated ongoing cost of €10–20/month, depending on the number of reports. If you switch the reports to once a week, or only run them daily when something goes wrong, the cost should be around €5–50/month. And it doesn’t depend on the size of the fleet – 1 vehicle or 1,000 vehicles; it makes no difference to the program. It just works.
This is what I call dark automation, derived from the dark code-factory term. You don’t know what’s inside; you care only about the outcome. And this is exactly what real engineers don’t like and don’t trust. They want to understand what’s going on under the hood. And I feel their pain. I feel the same. I don’t like this feeling as an engineer, but it just works somehow. And it works pretty well.
And if you look back at the history of business software, you may remember – if you are the same dinosaur as we are – that initially, perhaps 50 years ago, companies had engineers who built software to automate their own processes. These engineers were responsible for every line of code and knew exactly how it worked.
Later, in the 1980s, dedicated software companies emerged and started distributing their software. Companies that had previously built their own software began adopting 3rd-party software simply because it was better and cheaper. And that was the moment when they started to lose control over the code. The software became an opaque product. There was documentation, of course, but the code itself was completely opaque to its users.
Fast-forward 30 years, and remember the cloud. Almost everybody moved to the cloud because it was cheaper and better – Software as a Service, Platform as a Service, and so on. And with that move, we lost even more control.
Now, it was a 3rd-party company operating our services. We still had control sticks, but the actual operation was already hidden from us. Which CPUs, storage, and networking were being used was no longer something we controlled.
Later, in 2026, I think the term dark software factory emerged. It means that there is software that is produced and operated somehow, mostly by AI. It does whatever you need from software, but you do not have direct control over what’s inside.
As an engineer who grew up with the idea that you should understand what’s going on inside, I don’t particularly like it. But it looks like this is the world we’re moving toward. And honestly, once you come to terms with the concept, life becomes easier – and even more interesting. You just need to play with it, experiment, and build trust.
The use cases for such dark automation are not limited to tachograph schedulers. Here are a few cases picked from our support chat – each one takes around €5 to set up, with ongoing costs of roughly €0–10/month:
- Reboot each device every two hours (CPU reset), or send commands at an exact time.
- Turn a channel on and off according to a schedule.
- Request positions from an entire fleet every hour.
- Automatically delete devices that have been inactive for 30 days.
- Generate and send monthly or daily reports to clients.
- Automatically sync devices between flespi and Wialon.
- Auto-create a device, then configure and provision it with specific commands.
- Send commands once a specific device condition is met.
- Copy devices with their history between Wialon and flespi.
… and much more.
The dark side for you is how it works. But the outcome is not dark. We provide agents and connectors to external systems with full logs, so you can inspect and see every operation triggered by a flespi agent. On top of that, every mutating operation can pass through a human (or another controlling agent) approval gate. So it is also much more secure than other AI agents. What’s inside is still opaque. What’s outside is fully transparent – just like everything else in flespi.
For example, here are the flespi agent logs for this tacho scheduler task:
And this is what the flespi connector logs look like, showing each GET|POST operation executed by the agent:
Under the hood, at least for the flespi team, this automation is not that dark. We have built and maintain the corresponding ecosystem so that automations handled by flespi agents are as stable as native automation – and potentially much more stable than something you might create with vibe-coding agents.
In this particular case, the flespi agent created a handler called tacho_memory_cycle, which runs every minute on a timer event and calls the lib.tacho_cycle_tick function. At the moment I wrote this article, the script had executed 1,221 times and had woken the agent for a reasoning step 6 times – to reconsider what was going on and potentially adjust the script or report back to Evgeny – within a budget of 20 wakes.
The script had also produced 50 device command-queuing operations:
And the code of the lib.tacho_cycle_tick function is pretty simple – just 70 lines of:
Slightly below this screenshot, the code called another function – lib.tacho_cycle_plan – which the agent had created to handle tachograph file download command planning:
So yes, humans probably should not read this code. But the code itself is pretty straightforward, small enough for an agent to operate efficiently, and, most importantly, it relies on the flespi REST API (and other APIs, depending on the connector you provide to the agent).
In the end, the question is: when should you use dark automation provided by a flespi agent, and when should you host your own? I think the answer depends on a few factors:
- Is it a high-load script involving 100+ runs per second? If yes, host your own.
- Is it a demo, test, or just something ephemeral? If yes, use a flespi agent.
- Is it a long-term solution that your software backend architecture depends on? Then make your own decision.
Most systems nowadays start from the frontend, or from the frontend and backend together. At flespi, we are usually especially competent on the backend, so we tend to design systems from the bottom up.
Initially, we designed the AI agentic system to perform our own protocol engineering work, and it has been constantly evolving since the beginning of 2026. By the middle of the year, it had become absolutely clear that the system was amazing and that we should provide something similar to our users. This is how flespi AI agents appeared. And starting this week, they are becoming a quick dark automation system.
And next in line are, of course, more connectors and some frontend design tools, so that you can quickly build efficient telematics applications tailored to your business for just a few EUR.
Finally, a word about the durability of agents. In protocol engineering, we have three types of processes handled by flows (agents): protocol error monitoring, protocol engineering support, and protocol development. Protocol development flows are usually created per task, so they are short-lived. But, for example, our protocol error monitoring flow has already completed 2,007 reasoning steps, with a total working time of 4 days and 5 hours, and has burned through 3.5 billion tokens since February 18. And it is still working efficiently.
Here you can see how it scanned our production system for new solvable errors, detected one with Xexun, created an issue for our engineers, and reported it to Codi to inform the customer about the issue – all passively: 
The same goes for our Protocol Engineering Support flows – we have four of them working in parallel. They handle escalations from Codi whenever a protocol error is detected, assess the situation, and either forward the task to engineers or provide deeper engineering support when needed.
For example, flow #3 has completed 1,088 reasoning steps since May 3, spending more than a day working and burning almost 700M tokens:
So these agentic systems are proving to be rather reliable, and within our team we have already built enough trust in them to delegate most administrative, investigative, and even engineering work to these engineering flows, which we call under the umbrella name Birdy.
Whether you should trust a flespi AI agent with your business is entirely up to you. What we can guarantee is that it will save you time on any telematics-related work, and that it was built to be as reliable and transparent as everything else you can use in flespi. And, of course, it is designed and maintained by engineers with 20+ years of backend engineering experience.
But whether you trust it or not – again, that decision is fully yours.