
An AI agent that runs your business systems.
Ask for stock, issue an invoice, move a deal forward. In plain language, on your own data.
The problem
Your ERP knows everything, and nobody can talk to it
Stock levels, price lists, open orders, every invoice, every customer. It is all in the ERP, behind forms, tabs, and a permissions matrix. Getting anything out, or in, is a job in itself.
So the work leaks out of the system built to hold it. Someone checks stock by walking to the warehouse. Someone keeps the real order book in a spreadsheet. A quote is agreed over WhatsApp and typed into the ERP two days later, if at all.
The result is a back office held together by workarounds:
- The ERP only answers the questions its screens were built for. Anything else is a support ticket, an export, or a favour from whoever writes the queries.
- The spreadsheet and the chat thread become the real record. What reaches the ERP is a late, hand-typed copy.
- The CRM and the ERP disagree. One says the deal closed, the other never saw the order. The same customer exists twice, with different tax numbers.
- The one person who knows the ERP becomes the bottleneck, and the back office waits on them.
None of this is a data problem. The data is fine. What is missing is a way to ask the systems for things and tell them to do things, in plain language, without opening a form.
How we approach it
Read and operate the systems you already have
We do not replace the ERP, and we do not copy it into a database of our own. The ERP stays the system of record. We put an agent in front of it that can read it and operate it.
The agent runs on Ardaven, LayerX's agent and knowledge platform, and connects to each system through a dedicated MCP server. Ardaven handles the conversation, the knowledge, and the policy. The MCP servers connect it to the ERP, the CRM, and everything else the company runs on.
A typed tool layer around each system
Every system gets its own MCP server: one for Moloni, one for TOConline, one for the CRM. Each exposes typed tools with a clear schema for what goes in and what comes back, built for that system rather than generated from a spec.
Pagination, rate limits, retries, authentication, and each vendor's version of the word "invoice" stay inside its server. Adding another ERP means writing another server, not rewriting the agent.
Credentials are scoped per tenant, so a customer's agent reaches that customer's data and nothing else.
Reads run freely, writes are bounded
Checking stock is safe. Issuing an invoice is not, because an invoice is a legal document.
So every operation carries a policy: run it, or prepare it and wait for a named approver. Checking stock and drafting a quote can run on their own. Issuing a fiscal document or writing off inventory can require a person. The boundary is configuration, so a customer starts strict and loosens it as trust builds.
Writes carry idempotency keys, so a timeout or a repeated request never issues the same invoice twice.
Set up against the customer's real process
A generic ERP agent is useless to a specific company. Ours is configured against the real thing: document series, warehouses, pipeline stages, VAT rules, product catalogue, naming.
Before anything is written, the customer named in a sentence is matched to a customer in the ERP, the product to a SKU, the order to an order. If a name is ambiguous, the agent asks instead of guessing.
The approach
Typed tools per system · reads free, writes bounded · the customer's own process, not a generic ERP.
What we build
One conversation, every system behind it
The team sees a chat box. Behind it are the ERP, the CRM, and whatever else the company runs on, reachable in one sentence instead of four applications.
One agent across every system
Nobody has to know which system holds the answer or which one needs updating. The agent picks the tools, calls them in order, and reports what the systems returned.
That last request is four systems' work in one sentence: mark the deal won in the CRM, turn the quote into an order, check the stock, issue the invoice in the ERP.
Stock and logistics that answer back
Stock is the question people ask most and the ERP answers worst, because the answer lives across warehouses, pending orders, and goods already committed. The agent covers:
- Levels per warehouse and in total, including what is physically there versus what is already promised.
- Movements and transfers between warehouses, entered as a sentence and recorded in the ERP as a proper document.
- Reorder points and supplier orders, so "do we need to buy more of this?" has an answer before the shelf is empty.
- Shipping and tracking, tied back to the order and the customer waiting for it.
Invoicing that is fiscally correct in Portugal
A fiscal document is regulated, sequential, and reported to the tax authority, so this is exactly where the policy layer earns its place.
The agent uses the company's real document series, applies the right VAT rate or exemption reason, and produces documents that carry ATCUD and the printed QR code, feed SAF-T (PT), and reach AT correctly.
The ERP stays in charge of what must not be improvised: Moloni or TOConline assigns the number, signs the document, and communicates it. The agent prepares the document, shows it in full, and issues it only when the policy allows.
Sales and CRM in step with the ERP
A deal in the CRM and a customer in the ERP are the same company. The agent gives them one identity across systems, matched on tax number rather than on how someone typed the name that day. From there the chain runs without re-typing: deal, quote, order, invoice.
What is agreed in the CRM becomes the document in the ERP, and what happens in the ERP is written back to the CRM, so the pipeline reflects invoices issued rather than optimism.
Proven in production
This is running, not a slide.
The tool layer is in production against real accounting and sales systems:
- Moloni, for invoicing, commercial documents, and stock.
- TOConline, for invoicing and fiscal documents, including Portuguese certification requirements.
- CRM systems, for customers, deals, and quotes kept in step with the ERP.
- Other ERPs behind the same tool layer. A new system is a new server, not a new agent.
It builds on work we have already shipped.
The grounding from Company Brain handles the document side, so contracts, price lists, and internal policy inform an answer alongside live ERP records. Cadence applies the same idea to a factory: an agent operating on live operational data, not a dashboard about it.
How it works
Turning an API nobody enjoys into something you can just ask.
Underneath, it is the same machinery for any system with an API.
Giving a system a tool surface
When we add a new ERP or CRM, we:
- Read the vendor API once: its objects, its constraints, its failure modes, its idea of what a customer is.
- Model it as typed tools, with explicit schemas for arguments and results, so an invalid call fails before it reaches the vendor.
- Absorb the mess inside the server: scoped OAuth per tenant, token refresh, pagination, rate limits, retries with backoff, and error dialects translated into something the agent can reason about.
The same tool name then means the same thing whether it lands on Moloni or TOConline, which is what makes adding a system cheap. Ardaven discovers the tools each server offers, so a new capability appears without the agent being rewritten.
Running an operation
- The request is read as an intent, and the entities it mentions are pulled out.
- Those entities are resolved against real records, so a name becomes a customer ID and a product becomes a SKU. Ambiguity gets a question, not a guess.
- A preview is built: exactly what would be written, to which system, with what totals and tax treatment.
- The policy check decides whether it runs now or waits for a named approver.
- It executes with an idempotency key, and the confirmation quotes the ERP's own document reference.
- The whole thing lands in an append-only audit log: who asked, what was proposed, who approved, what the system returned.
Security and privacy
An agent with keys needs guardrails.
Credentials are least-privilege and scoped per tenant, so an agent reaches one company's systems with the permissions that company granted, and cross-tenant reads are impossible by design. Every read and write goes into an append-only audit log with the actor attached. Rate limiting absorbs spikes and abuse. GDPR and EU AI Act requirements are handled at the platform level, with EU hosting available.
When the data cannot leave the building, the whole stack runs inside the company's own perimeter: the models run on your infrastructure, next to the ERP, and nothing is sent to a third party.
What it delivers
The back office, operated in sentences instead of forms.
| Layer | Choice |
|---|---|
| Platform | Ardaven, LayerX's agent and knowledge platform: conversation, knowledge, policy, and surfaces |
| Systems | Moloni · TOConline · other ERPs · CRM, each kept as the system of record |
| Tool layer | One MCP server per system · typed tools with explicit schemas · credentials scoped per tenant · vendor quirks absorbed inside the server |
| Reads | Live queries against the system of record · entities resolved to real records · ambiguity raised as a question |
| Writes | Per-operation policy, autonomous or approval · previews before execution · idempotency keys · named approvers |
| Fiscal | Document series · VAT rates and exemption reasons · ATCUD · QR code · SAF-T (PT) · AT communication, all issued by the ERP |
| Safety | Least-privilege scoped credentials · no cross-tenant reads · append-only audit log · rate limiting · GDPR and EU AI Act handling · EU hosting · on-premise deployment with local inference |
The result is a back office where asking and doing are the same action. Stock questions get answered where they are asked, documents get issued the moment they are agreed, the CRM and the ERP tell the same story, and nobody spends the afternoon re-typing a spreadsheet into a form.
Beyond ERP and CRM
Any system with an API becomes something you operate.
ERP and CRM are the showcase, not the limit.
Billing, ticketing, HR, e-commerce, banking, logistics, internal back offices: anything with an API can be given a tool surface and put behind the same agent, with the same policy deciding what runs on its own and what waits for a person.
Wherever people spend the day moving information between systems that were never introduced to each other, that work can become a conversation.
Let's wire an agent into your systems.
We build the AI and integration layers that let a company operate its own software in plain language, pairing real depth in agents and systems integration with modern software practice, and built to be safe, secure, and compliant for the EU.
If that sounds like your situation, let's talk.
Let's Talk