Skip to content
Work

02 · Enterprise AI

ERP AI

Ask a business question in plain language. Get an answer from the ERP.

In progress: Phase 1 built
Ask

Compare sales between July and August

  1. ModelIn evaluation
  2. Read-only APIPeriod comparison
  3. PostgreSQL 16Controlled views

Period comparison, THB

+16.7%

Sales rose from 4.2M in July to 4.9M in August.

Synthetic data

Jul4.2M
Aug4.9M
Illustration
Status
Phase 1 built
Stack
  • Python
  • FastAPI
  • PostgreSQL 16
  • Docker
  • LM Studio
  • llama.cpp
  • Apple Metal
  • GitHub CI

Overview

ERP AI is an interface for asking questions about business data in plain language: what revenue was last month, how two periods compare, which products earned the highest gross profit. The goal is to make ERP information reachable without navigating database tables or building a report.

The first phase is the foundation rather than the conversation: a synthetic ERP in PostgreSQL 16, and a read-only API on top of it that computes answers instead of leaving them to a model. Everything so far runs on synthetic data.

The problem

Business data lives in ERP tables that most of the people who need answers cannot query. Reports help, but only for the questions somebody anticipated.

Letting a language model write arbitrary SQL against an ERP is not an acceptable fix. The model needs a narrow, read-only, well-tested surface to work through, and the numbers have to come from the database, not from the model.

Architecture

  1. Question

    Target experience

    • Plain-language business question

  2. AI layer

    In evaluation

    • Local models
    • LM Studio
    • llama.cpp
    • Tool calling

  3. Read-only API

    • FastAPI
    • Sales summary
    • Period comparison
    • Data validation

  4. Database

    • PostgreSQL 16
    • Synthetic ERP dataset
    • Controlled SQL views
    • Read-only access
The lower two layers are built and tested. The model layer has been benchmarked but not integrated.

What exists, and what doesn't

Implemented

  • Synthetic ERP environment in PostgreSQL 16
  • Read-only database access through controlled SQL views
  • FastAPI service with structured, validated endpoints
  • Sales-summary endpoint, including sales aggregation
  • Period-comparison endpoint
  • Automated backend tests, 21 passing, with CI checks
  • Docker-based environment on Apple Silicon
  • Local model benchmarking on a Mac Studio: Hermes 4 14B through LM Studio with Metal acceleration, with memory use evaluated

Planned

  • Tool integration between a model and the API
  • Gross-profit and operating-performance questions
  • Multi-location deployment: four business locations with four independent databases and data isolation
  • A hosted interface with authenticated users, each limited to the right business data
  • Centralised, cloud-hosted inference
  • Possible Odoo compatibility
  • Reporting into Fox's Shelter for monitoring

My role

  • Defined the phases and the acceptance criteria for each.
  • Designed the read-only data surface: which views exist and what the API may expose.
  • Ran the local model benchmarks and made the call on the result.
  • Designed the multi-database architecture for the enterprise expansion.
  • Implementation was done with AI coding agents working from my specifications. I reviewed the results, set the tests a change had to pass, and decided what was ready.

What I learned

A failed benchmark is still a result

I benchmarked Hermes 4 14B on my Mac Studio, as a quantized GGUF model through LM Studio with Metal acceleration. It loaded and ran, but it did not meet the acceptance criteria I had set. It is recorded here as an experiment, not an integration, and the next candidate has to clear the same bar.

Read-only first

Starting with a read-only API and controlled views means that whichever model ends up in front of it can only reach what it has been deliberately given.

Next · 03

Business World

ERP records, shown as an interactive world instead of a dashboard.