A robot that has to prove it worked
Why I built Maptelo: automation that learns from a demonstration and checks every result in the system instead of trusting the screen.
Anyone who has built an office robot knows the moment. The robot goes through a form, clicks “Save”, a green message appears and the report says “success”. A week later someone asks why a customer was invoiced at the old price. It turns out nothing was saved. The message was true for the screen, not for the system.
Maptelo started from that one sentence: the screen can lie. If automation is going to take over repetitive work, it has to be able to show proof that it did the work. Not a screenshot with a green bar, but a read of the system that says: this price really applies from that day.
Show it once instead of programming
Classic RPA tools make you design the robot first: step by step, selector by selector. Maptelo reverses the order. You do the process as usual, in Edge or Chrome, and the program watches and records what you clicked, what you typed, on which screen and — as it turned out to matter most — which spreadsheet column each value came from.
One demonstration is not enough to understand a process. From a few, Maptelo builds a model: steps, inputs, rules (“this step only when the product has several price versions”), exceptions and a way to check the result. Where demonstrations differ and the reason is not visible, the program does not guess. It asks, and the answer stays in a file next to the model, together with who gave it.
The same model produces the documentation: a step-by-step guide with screenshots, a BPMN diagram and a report that marks the steps that save data. Documentation and automation do not drift apart, because they share one source.
Proof instead of a message
The most important design decision: every run ends with one of seven outcomes, and there is only one success. A row is VERIFIED when an independent read of the system confirms its effect — an API or the database, never the same screen the robot clicked on.
The other outcomes matter just as much, because they say what to do next. HALTED_SAFE means: I stopped before saving and changed nothing. NEEDS_RECONCILIATION: something may have been saved, but the read does not confirm it, so a person checks and the robot does not retry blindly. Then there is idempotency: if a row of the sheet is already in the system, the robot will not type it again. The film shows it on the first row, which I entered by hand during the demonstration: the robot checked the database and skipped it.
When the system changes
Robots usually die after an application update. I tested that on a real ERP: a process built on Odoo 17 ran after the upgrade to Odoo 18, where screen addresses, column names and the very way of adding a price had changed. A table row had become a dialog window.
Maptelo found the moved screens and fields by itself: some by the screens’ landmarks, some with help from a language model. Where the saving flow itself had changed, it stopped without saving instead of guessing. The result of that test matters more to me than any feature: zero false VERIFIED and zero bad writes. Repairs reach a new version of the model only after a run with them has ended in a confirmed result, and only after a person approves them.
Before you trust it
No company hands a process to a robot because someone said so. That is what shadow mode is for: the robot goes through the rows without saving, people do their work, and then an independent read compares the two. In the film, shadow mode caught a typo: someone entered 135.10 instead of the 131.50 from the sheet.
“Without saving” has to mean really without saving. Odoo saves an abandoned form when you leave the page, so a dry run could leave a row behind. Before leaving, Maptelo takes away the page’s ability to send data, and only then closes it. It is one of many cases where testing on a real system taught me more than any plan.
For sensitive data there is a private mode: screenshots cover typed values and table contents, and the model keeps no example data.
The agent gets a tool, not the keys
An approved process can be offered to an AI agent as a tool, through the Model Context Protocol. In my test, Claude got an instruction in plain language: set a price of 150 for this product in the price list, from 1 December. Maptelo performed exactly the approved steps and returned a result with proof: VERIFIED, a database read and a screenshot. The repeated instruction ended as “already done”, with no second entry. The agent never gets a password or a session. It gets a process someone has checked.
Where it stands today
Maptelo runs on the computer of the person who does the process — like Power Automate Desktop rather than a cloud service. Recordings, models and proof stay on the disk. For work without a terminal there is Studio: a page available only on that computer, where you can record a demonstration, build the model, answer its questions and run the process on a sheet while watching every row live.
Behind it are more than 400 automated tests, including full runs in a browser. The next steps are a Windows installer and a pilot on a real process — but only with the IT department’s approval and a data-protection review.
One thing taught me the most: automation is not ready when it works. It is ready when it can prove that it worked, and say honestly when it does not know. (The project, with the film: Maptelo.)