Building Your First Etendo Copilot Agent That Touches Real ERP Data

If you’ve been near Etendo lately, you’ve heard the pitch: an agentic ERP where AI agents “observe, plan, act, and verify” instead of waiting for a human to click through windows. Strip away the paradigm-shift language and there’s a genuinely useful thing underneath — Copilot, a framework for running LLM agents inside your ERP, with access to your data, your processes, and (this is the part that should make you sit up straight) your permissions.

We’ve built on it in production. Before BeaverMinds we were Applications Engineers at Openbravo, and since then we’ve shipped LLM features inside Etendo for real operations — product categorization, variant management, automated quality-control inspection. So this is the tutorial we wish the docs came with: what Copilot actually is, how to stand up a first agent that does something useful, and the lessons nobody writes down about pointing a language model at a live ERP.

What Copilot actually is

Architecturally, Copilot is a companion service that runs in Docker alongside your Etendo instance, talking to your ERP over HTTP. You don’t write agents in code (unless you want to); you configure them in ERP windows, the same way you’d configure a report or a process. The agents themselves are powered by whichever LLM provider you plug in — the installation guide supports OpenAI, Google Gemini, Anthropic, and DeepSeek, each via its own API key in gradle.properties.

Two agent architectures matter, per the setup and usage docs:

• Multi-Model agents — the recommended default. One agent, a prompt, a model of your choice, plus optional knowledge base files and tools.
• LangGraph agents — supervisor agents that delegate to a team of other agents. Powerful, and exactly the kind of thing you should build second, not first.

The Copilot Extensions Bundle from the Etendo Marketplace ships the infrastructure plus default agents and tools. Out of the box you get, among others, Bastian (the Etendo documentation indexed as a knowledge base — genuinely handy) and SQL Expert, which turns natural-language questions into SQL queries against your database. There are also developer-focused agents for generating windows, tabs, event handlers, and Jasper reports, but that’s a different article.

“Touching real ERP data” happens through tools. The available tools include an API Call Tool (REST calls with authentication — this is how agents hit Etendo’s own webservices), an Etendo SQL to CSV Tool (SQL queries with security validation, results as CSV), file read/write tools, OCR, email, and more. You can also write your own tools in Python, and newer versions support wiring in external MCP servers. An agent is, in the end, a prompt plus a set of tools plus the permissions you gave it. Keep that sentence in mind; we’ll come back to it.

What you need before starting

From the installation docs, the honest prerequisite list:

• Etendo 25 (recommended; 24 works with an extra setup step). If you’re still on Openbravo, this is one more reason the migration is the toll booth, not the destination.
• Docker 26+ and Docker Compose 2.26+ on the host. The docs specifically warn against installing Docker via Snap — heed that, it breaks volume mounts.
• A paid LLM API key. The docs are blunt: free-tier API access won’t cut it due to access limitations. Budget a real (if modest) monthly API spend.
• The Copilot Extensions Bundle installed from the Marketplace.

Setup itself is standard Etendo choreography: set docker_com.etendoerp.copilot=true and your API key in gradle.properties, then ./gradlew setup, ./gradlew resources.up to bring the containers up, and the usual update.database compile.complete smartbuild. If you’ve done any Etendo module install, nothing here will surprise you.

Standing up your first useful agent

Skip the temptation to build “an agent that runs my company.” Pick one narrow, checkable task. A good first candidate: an agent that answers questions about open sales orders, or one that drafts product descriptions from your item master. Narrow scope, verifiable output, low blast radius.

The workflow, grounded in the agent configuration docs:

1. Create the agent. Open the Agent window (Application > Service > Copilot > Agent). Give it a name, a description (write a real one — LangGraph supervisors literally cannot delegate to an agent without a description), and pick Multi-Model as the type. Choose a model from the AI Models list.

2. Write the prompt. This is the agent’s job description, in plain English (or Spanish). Be boringly specific: what it does, what it must never do, what format its answers take. Our rule from production: the prompt should read like instructions to a competent temp on their first day, not a mission statement.

3. Ground it. In the Knowledge tab, attach reference files (.txt, .pdf, .md, .zip). The docs offer several behaviors — retrieved as a knowledge base, appended to the prompt for small files, or, notably, an OpenAPI spec that auto-generates API tools so your agent can call your Etendo webservices without you hand-writing a tool.

4. Give it hands, carefully. In the Skills and Tools tab, enable only the tools this task needs. For a read-only order-status agent, that might be a single API tool against a query webservice. Resist enabling the SQL tool “just in case.”

5. Sync and gate. Press Sync Agent — it creates or updates the agent on the Copilot side and uploads your knowledge files. Then grant access through the Agent Access window to specific roles. Not everyone. Specific roles.

6. Use it in context. Per the user guide, users reach Copilot from the navigation bar or — more interestingly — from the toolbar button inside any window, which passes the current form fields and selected grid rows to the agent as context. “Summarize the selected orders” suddenly means those orders. This context-passing is the single most underrated feature in the stack.

That’s a working agent, standing on documented rails. Now for the part the rails don’t cover.

What the docs don’t tell you

Everything above is configuration. What follows is what we learned shipping LLM features — categorization, variant management, QC inspection — against production ERP data.

Your data quality becomes visible immediately. An LLM reading your product master will faithfully surface every “TBD”, every description that’s just a supplier SKU, every category that means something different in each warehouse. Our categorization work only got good after we cleaned reference data the humans had been quietly routing around for years. Budget data cleanup into any Copilot project, because the agent will not route around it — it will confidently repeat it.

Permissions are the design, not a checkbox. An agent with the SQL tool and a generous role can read anything that role can read — payroll-adjacent tables included. Decide up front what each agent may see and do, express it in the role you run it under, and constrain the tools to match. We’ve written more on this in why agentic ERP needs governance first; the short version is that “prompt says don’t” is not a security boundary. Tools and roles are.

Constrain early, loosen late. Our production agents that work are narrow: one job, few tools, structured output (the JSON Schema option in advanced settings is your friend here). The QC inspection agent doesn’t chat — it looks at inspection input and returns a verdict in a fixed schema that a normal, deterministic process then acts on. Read-only first. Human approval on anything that writes. Autonomy is something an agent earns per task, not a launch setting.

Test like it’s software, because it is. Build a set of 30–50 real questions or cases with known-correct answers before you ship, and rerun them whenever you change the prompt, the model, or the knowledge base. Prompts regress exactly like code, except silently. Also watch the model dropdown: swapping providers changes behavior in ways your prompt didn’t anticipate.

Realistic vs. hype

Etendo’s own agentic ERP piece is candid on this if you read it closely: some things “already work today,” while autonomy on complex processes is roadmap. Our experience agrees. What works now: grounded Q&A over your data and docs, drafting and categorization work, natural-language queries, narrow structured tasks like our QC checks, and context-aware assistance inside windows. What doesn’t yet: unsupervised agents running end-to-end financial processes — and frankly, you don’t want that until the governance is boring.

That’s not a criticism. A framework where a mid-size Etendo shop can configure a grounded, permission-scoped agent in ERP windows — without building LLM plumbing from scratch — is a real capability the classic Openbravo platform never had, and a legitimate reason shops migrate in the first place.

If you want a second pair of eyes before you point a language model at your production database: our Openbravo & Etendo consulting page covers what we do, and the free ERP & AI Readiness Assessment is one call plus a written report on where an agent would genuinely pay off in your instance — and where your data isn’t ready for one yet. We’d rather tell you the second part before you find out from the agent.