Cobra · Multi-agent architecture design
Autonomous supplier invoice processing agent
Context
Hugo was manually processing every supplier invoice in Odoo: checking lines, adding WEEE/shipping/discounts, matching the VAT-inc total, confirming. The goal: only touch Odoo once a week for the SEPA batch — everything else happens in Teams.
What was built (design)
- Mapping of 5 input channels + identification of Cobra's two main ones:
comptabilite@cobra.frand PO via chatter - Distinction between accounting families: merchandise (PO-linked, 607xxx) vs. overheads (6xxxx)
- Line-by-line matching: identification hierarchy (supplier code → EAN → name → price), quantity normalization (pair/unit), 2% price alert threshold, WEEE/shipping integrated or separate
- Teams Adaptive Cards actions: validation, correction, payment creation, navigation — zero Odoo interface except SEPA batch
- Multi-agent architecture: Orchestrator / Teams Agent / Odoo Agent / Patterns Agent
scan_fournisseurs.py: extraction of partners with ≥ 4 invoices over 12 months + JSON patterns structure
What was hard
- Pair/unit handling is a silent trap: Odoo doesn't raise an error if the quantity is wrong — the discrepancy only shows up in the VAT-inc total. Factor memorized per supplier
- WEEE and shipping can't be fixed lines: some suppliers include them in the unit price. The agent builds the pattern progressively
Stack
Python XML-RPC, Adaptive Cards v1.5, Teams webhook, JSON (patterns), Odoo 18 (account.move, account.move.line, purchase.order, product.supplierinfo, account.payment), Claude Code.
What this illustrates
A high-level design session before implementation: architecture, complex business rules and edge cases scoped *before* writing a single line of code. Claude acts here as a technical product manager who formalizes what the CEO has in mind and translates it into a precise implementation plan.