The hard part is rarely the AI.

It’s the process, the data and the guardrails. I build agents that work on Odoo through MCP — and the layer that decides what they are allowed to do, what needs a person, and what never happens.

01

Agent governance for the ERP

A Python/Pydantic layer that validates and audits every action an AI agent wants to take before it reaches Odoo.

In production · Python · Pydantic · MCP · Claude Agent SDK · Odoo XML-RPC

The problem. Agents that can write to an ERP are useful exactly until they post the wrong invoice. The model is rarely the risk — unchecked writes are.

An agent talks to Odoo through MCP, but it never talks to Odoo directly. Every tool call goes through a governance layer that sits between the agent and the database:

  • Typed contracts. Each allowed action is a Pydantic model. If the agent’s arguments don’t validate — wrong partner, missing tax, a date in a closed period — the call never leaves the layer.
  • Policy before execution. Rules decide what an agent may do on its own, what needs a human, and what is never allowed (deleting posted entries, touching payroll).
  • Audit trail. Every proposal, decision and result is logged with who asked, which agent acted and what changed — readable by a consultant, not just by a developer.
  • Read-heavy by default. Agents get broad read access and narrow, explicit write access, scoped per client database.

Why it matters

ERP data is the company’s memory. A governance layer is what turns an impressive demo into something a finance team will actually let run on Monday morning.

10:02:11  agent  create    sale.order        draft
10:02:11  guard  validate  partner_id        ✓
10:02:12  guard  validate  pricelist         ✓
10:02:12  odoo   write     sale.order/4182   ok
10:04:37  agent  post      account.move      
10:04:37  guard  period    2026-09 locked    ✗ blocked
10:04:37  guard  escalate  → human           ↗
10:06:02  agent  read      stock.quant       ok
10:06:03  agent  propose   purchase.order    draft
10:06:03  guard  amount    > 5000            ↗ approval
10:09:44  agent  read      res.partner       ok
10:11:20  agent  unlink    account.move      
10:11:20  guard  never     allowed           ✗ blocked
✓ validated · ✗ blocked · ↗ sent to a person. Illustrative log, no client data.
AI agent calls pass through MCP and a governance layer before reaching Odoo AI agentClaude MCPtool call GOVERNANCE LAYER 1 · Validate — Pydantic contract 2 · Policy — auto / human / never 3 · Audit — who, what, why OdooERP data blocked / escalated to a human
02

Agentic consulting platform

The multi-tenant platform behind Kontext — agents that support ERP consulting work for several clients without mixing their data.

Prototype · LangGraph · LiteLLM / Portkey · Claude Agent SDK · Python

The problem. Consulting knowledge lives in heads and slide decks. Agents can carry it — but only if every client's context stays strictly separate and GDPR-compliant.

Kontext runs on a multi-tenant agent platform: each client is its own tenant, with its own ERP connection, its own knowledge base and its own audit log.

  • Orchestration with LangGraph: multi-step workflows (diagnose → propose → validate → apply) instead of one-shot prompts.
  • Model gateway through LiteLLM / Portkey: routing, cost control and observability per tenant.
  • Claude Agent SDK for the agents that do the actual consulting work.
  • GDPR by design: data residency, minimization and per-tenant isolation are architecture decisions, not afterthoughts.
Multi-tenant platform: each client tenant connects through orchestration and a model gateway to its own ERP Tenant Acontext · audit logTenant Bcontext · audit logTenant Ccontext · audit log ORCHESTRATIONLangGraphdiagnose → propose →validate → apply MODEL GATEWAYLiteLLM / Portkeyrouting · cost · traces Claude Agent SDKgoverned tools → ERP GDPR by design · per-tenant isolation · EU data residency
03

Odoo AI skills

A versioned library of agent skills that encode how an Odoo consultant works — from demo databases to localization and bookkeeping.

In daily use · Claude Code · Agent skills · Python · Git + SemVer

The problem. Every implementation re-learns the same things. Skills turn that know-how into reusable, versioned instructions an agent can follow.

A monorepo of skills, versioned with Git and SemVer, used daily in real projects:

  • odoo-enterprise-expert — functional reference across apps and versions
  • odoo-demo-builder — realistic demo databases seeded with complete business flows
  • odoo-capture — documenting Odoo screens into work instructions
  • odoo-localizacion-generator — localization scaffolding
  • Bookkeeping by country — ES, CL, NL, FI, CA, HU
  • Health scan — diagnostics of inherited Odoo databases
  • context-curator — keeps project context clean and current
Know-how flows from projects into versioned skills that agents reuse on the next project Project work meetings · videos · docs Capture transcribe · structure Skill Git · SemVer · tests Agent applies it next time feedback from the next project
04

Interfaces & automation

Small tools that make the ERP and the knowledge around it reachable — by chat, by video, by daily digest.

In daily use · Telegram Bot API · Whisper · ffmpeg · MCP · Python

The problem. Most people who need ERP data will never open the ERP. And most consulting knowledge is trapped in recordings nobody rewatches.

  • Telegram → Odoo assistant. Ask the ERP in natural language — stock, open orders, overdue invoices — from a phone.
  • Knowledge pipeline. Videos and meetings → transcripts (Whisper + ffmpeg) → structured, versioned skills.
  • Custom MCP server for Flickr. Managing a photography archive through an agent.
  • Automated reporting. A daily digest that summarizes what changed and what needs attention.
05

Google Workspace

✍️ draft — Jorge to describe

Apps Script and Sheets next to the ERP: small automations, sheets that read from Odoo, reports that arrive by themselves.

This work runs as Kontext ↗, my practice for AI-augmented ERP operations. The method behind it lives in the Odoo room.