Pandora — Agente de Operações do ERP
An agent orchestrator that operates the ERP — and, where money is involved, asks before it signs.
- from defect to delivered brief (before: 1 day)
- 8 min
- divergences across 1,179,236 checked rows
- 0
- candidates before and after the restore
- 102 → 1
From pain to result
Before
Memoryless scheduled robots, retrying forever what would never succeed — and payment approval that can neither be left to a robot nor stall waiting for someone.
The old robots ran on a schedule with no memory: they wiped their own state on every run and retried forever what would never succeed. One of them, over 13 months, made 71,930 attempts to approve what was already approved and sent 222,659 attachments — many of them the same PDF, again.
And automation that touches payment approval cannot be a robot that signs everything: whoever is accountable for the decision must keep deciding, without becoming a bottleneck.
Worse than failing is finishing "OK" with nothing delivered. A monitoring robot completed a run without a single error in its log and delivered 2 court briefs instead of about 70 — noticed only the next day.
How · 1/3
I built an asynchronous Python orchestrator that serves, in a single process, the WhatsApp channel, the API and a web dashboard. Each robot became a registered agent with persistent state, auditable runs and a schedule designed around the ERP replica’s restore windows.
How · 2/3
Agents that touch approvals ask instead of signing: they send the list to the person in charge on WhatsApp and execute only what is confirmed. Autonomy was designed to require two keys — a written rule, with author and ceiling, and autonomous mode switched on — and any read failure falls back to "ask".
How · 3/3
A watcher looks at the other robots’ results, not just whether they are up: it compares what was collected, matched and delivered. Email triage applies rules first and an LLM only to the residue, with structured output. The AI classifies and drafts; the rules engine executes.
After
The robots became agents with memory and an auditable history. Where money is involved, Pandora asks the person in charge on WhatsApp and executes only what is confirmed — and a watcher checks whether the other robots actually delivered.
- 8 min
- from defect to delivered brief (before: 1 day)
- 0
- divergences across 1,179,236 checked rows
- 102 → 1
- candidates before and after the restore
Reading the diagram
Agents read the ERP replica to know what to do and act through the API — but approvals go through a question to the person in charge first. Every run is recorded, and the watcher closes the loop by checking the other robots’ ends. Email triage goes through the same rules engine.
Technical highlights
- 1 An agent with memory in place of a memoryless robot: every ERP response is classified — success, "already approved by another user" (a conclusion, not a failure), permanent or transient error — and what will never change leaves the queue instead of being retried forever.
- 2 Schedule matched to the replica: the same query returned 102 candidates on a stale replica and 1 right after the restore. The stale replica caused the "already approved" responses; the agents’ schedule now follows the restore windows.
- 3 A robot that finishes "OK" with nothing delivered is indistinguishable, from the inside, from one that had nothing to deliver. On its first day in production the watcher caught the same defect and the brief reached the client 8 minutes later; the day before, that defect had taken a whole day.
- 4 Automatic correction only where it is safe: a single one, idempotent, checked against 1,179,236 of 1,179,236 rows with zero divergence. Anything that emails a client or stops production asks first.
- 5 Least privilege measured, not assumed: the watcher’s service user was demoted from administrator to operator, and the routes it uses kept responding while the admin ones started refusing.
- 6 Switching AI models became configuration: the client checks at startup what each model supports and only sends accepted parameters. A small model classified an email in 3.6 s, with the same result as the larger model on the same case.