Turn AIexperimentsinto toolspeople trust.
A working preview of how I would own the technology outside Odoo: a Slack assistant that reads the ERP and never writes without a human, an AI framework for seventy colleagues, a clear build or buy method, and a review standard a partner takes seriously.
Hero video: AI-generated warehouse scene, not B Futurist's real warehouse.
One assistant in Slack, reading the ERP for everyone.
Trading, Supply Chain and Finance ask the same questions every day: what is free to sell, what is late, when does the container land. This is the first small tool I would ship. Every ERP call lights up the shelf it read in the warehouse twin. Anything that changes data becomes an approval card for a named colleague.
Warehouse twin
Demo data
The twin is driven by the assistant's real tool calls. Orange means "the model is reading this right now". It shows a reviewer, and a colleague, exactly what the AI looked at.
- ops-questions
- supply-chain
- trading
- Ops
What data can go where, decided once.
Seventy people are already experimenting. A framework should make the safe path the easy path, not slow anyone down. This is a first draft I would test with each team in the first month: four data classes, three kinds of tools, and four review gates.
Describe what a colleague wants to do with AI.
A decision you can explain in two minutes.
Every request gets the same six questions, weighted for this company. Move the weights and the recommendation and the radar move with them. The scores and costs are illustrative, to show the method, not a quote.
Hold the partner to scope, architecture and cost.
The largest part of the job: owning our side of a build someone else delivers. Here is the kind of review I would write on a delivery, using a made-up example: a partner ships an "order delay alert" from the ERP to Slack.
"It works in the demo. It is not ready until it survives a retry, a holiday weekend and a price change."
Order delay alerts, ERP to Slack
Four findings, two blocking. Not accepted yet.
Changes requestedBlockingAlerts are sent twice after a retry
The webhook has no idempotency key, so a timeout plus retry posts the same alert again. People stop reading alerts that repeat.
BlockingOne admin API key with full write access
The integration only reads orders, but it runs with an admin key that can change prices.
CostPolls the ERP every minute, around the clock
About 43,000 calls a month for something that changes a few dozen times a day.
Hand-overNo monitoring and no runbook
If it silently stops, nobody will notice for days.
Understand first, then ship one thing that sticks.
Following the vacancy's own order: learn how work really moves, take technical ownership of the running partner project, and deliver one focused improvement with Business Operations.
- Sit with Trading, Supply Chain, Warehouse, Finance and People & Culture. Follow the handovers.
- Map the systems around Odoo: Workspace, Slack, Beautinow, carriers, partners.
- Read the running partner project: scope, architecture, open risks.
- Collect every AI experiment already in use.
Out: a one-page map and a ranked list of ten problems, agreed with the Team Leader.
- Take technical ownership of the partner build, with a review standard.
- Ship the first small tool with Business Operations.
- Run the draft AI framework past each team.
Out: one tool in daily use, measured before and after.
- Turn the best local experiments into robust, reusable tools.
- Short sessions per team on working well with AI.
- Propose the roadmap for the next two quarters.
Out: framework v1, a roadmap and a monthly report on adoption, errors and cost.
Teach without making anyone feel stupid.
Short sessions on real work from that team, not a generic AI training. One shared place for prompts that work. Office hours every week. The measure is not how many people used AI, it is how much manual work and how many errors went away.
A builder's role before an AI role.
The vacancy is right: reviewing a partner and shipping software that keeps working both need real engineering. So here is what sits behind the Ask Ops box, and how I tested it.
- Secrets stay server side.The Claude key is an encrypted secret on the project, never in the page.
- Abuse and cost are capped.Origin check, 20 calls per visitor and 500 per day, counted in D1 because KV is not consistent enough for counters.
- Least privilege by design.The model only gets read tools. The one "write" tool cannot write.
- Input is data.The system prompt treats every message as data, not instructions. Confidential fields (cost, margin) are refused.
- Observable.Every answer returns its tool trace, time and token count, and the twin shows what was read.
- In production the in-memory data becomes Odoo's JSON-RPC API under a read-only integration user, and Slack's Events API replaces this form.
Peter Heijnen. I build things that have to keep working.
I run a fish-processing company with staff in the Netherlands and an AI studio, Lazy Lizard Group. I am moving back to the Netherlands with my family in spring 2027 and can start remotely before that.
ClawFC, an autonomous AI football league
External AI agents register a player through an MCP server or a REST API, train between matchdays and play.
app.heijvis.nl
The staff app for my own company: people, hours and jobs. Built for colleagues who are not technical, and used by them.
Avila Werkplaats
A hotel operations demo with a live Claude guest inbox, rate limits in D1 and a bilingual interface. avila.lazylizardai.com