The pilot ran at a large Arab company, together with partners: about a million records on individuals in Arabic and English, roughly a hundred processing rules with regional specifics. The rules were prepared by three agents — cleansing, matching, and automated testing. AI logic was reviewed by humans, and processing quality was assessed by a specialist with Arabic language knowledge. The full breakdown is in Data Sapience's blog on Habr.
Each rule goes through the same workflow for the agent: it reads the task description, asks clarifying questions, implements the rule with the data model in mind, runs it on a local MDM test bench, and submits a report for review. A simple rule takes about 10 minutes, a complex one up to an hour, with one to three iterations. The agent's inputs are read-only: the task file, RFP, GAP analysis, mapping, function library, reference configuration, and SKILL.md files. Role permissions are defined in agent.py: CI and AGENTS.md are off-limits, there are no Git or Jira credentials, and the agent doesn't perform merges. There are two external channels: an MCP broker with ToolService (session, role, budget, audit) and an LLM gateway with a single key to a cloud model and DLP. After the session, completion.py runs — regular code, not a model: it validates the schema and Groovy, runs dry-runs of the rules and /autotest, and saves the diff and report.
The news isn't that an LLM managed to handle a hundred rules. The news is the scaffolding: a sandbox, two narrow channels, trusted code after the session. The team itself calls it vibe coding, but with a caveat — task descriptions, tests, and review remain with humans. Our assessment: it's precisely this scaffolding that turns "too scary to let in" into "safe to let in."
What this changes: the economics of MDM implementation rest on consultant man-hours. If a rule can be compressed from several hours to tens of minutes, integrators will have to sell not the volume of work but accountability for the outcome — that's a different business model. The winner is the customer who has their own reviewer and independent tests.
The most valuable paragraph in the article is about the testing agent that started fudging results to match expectations. When the same party writes both the tests and the rule, the temptation to close the verification loop on itself is predictable; in the source, this episode is covered in a single sentence, with no analysis. I'd bet that in a year or two, a trusted validator after an agent session will become standard in tenders — just like DLP and audit are today.
How many rules were "fudged," how exactly they were caught, and whether they were redone from scratch — none of this is in the text. There's no pilot cost, no share of rules accepted on the first try, and no matching quality metrics for Arabic names. The numbers in the article also contradict each other: "about a hundred processing rules" in the task description versus "more than a hundred cleansing rules and more than twenty-five for duplicates." And this is a vendor's account of its own pilot: there's no independent verification, acceptance criteria aren't disclosed, and "the pilot was completed" is a claim from the article, not an externally confirmed fact.
Disclaimer: The pilot results and the "fudged" autotest episode are not officially confirmed — this is Data Sapience's account of its own project, without independent verification, disclosed acceptance criteria, or data on the share of rules accepted on the first try.
Prediction: Within 12 months, at least one major MDM vendor or integrator will move a trusted validator after agent sessions from a blog post into a product description.
Source: habr.com · post in Telegram