How an AI assistant became an agentic ERP

MINION did not begin with a clean declaration that it would become an ERP. It began with a more open-ended promise: give an agent enough tools and context to complete useful work. The ERP emerged when that promise met the ordinary gravity of business operations.

An assistant can answer a question with temporary context. An operating system for a business must know whose organization is active, which record is canonical, what the caller may change, how the change is validated, and what survives when the conversation ends. Those requirements changed the center of the product.

The first useful shape

The early shape was a collection of capable surfaces: an agent gateway, chat and session handling, plugins, tools, and a SvelteKit Hub. Each part could solve a local problem. The gateway knew how to reach an agent. The Hub could present sessions and configuration. Plugins could add a bounded capability.

That modularity was valuable, but it did not yet answer a harder question: what happens when an action belongs to a business process rather than to one conversation?

A booking touches a customer, a calendar, a service, a payment expectation, and sometimes stock. A sale touches a shift, a ticket, products, payments, tax settings, inventory, and a party record. A support issue can belong to the same person and organization as both. Conversation state alone cannot be the joining structure.

The pressure that changed the architecture

The platform accumulated shared concerns before it accumulated modules:

• organization-scoped identity and configuration;
• one permission model for navigation, pages, APIs, and agent actions;
• records that could be referenced across CRM, finance, scheduling, support, projects, and channels;
• database transactions and row-level boundaries that did not trust a client-supplied organization;
• preview and confirmation contracts for agent-authored writes;
• audit and operational recovery paths.

These were not decorative enterprise features. They were the conditions under which the agent could move from commentary to controlled action.

The Hub then expanded around those conditions. CRM, finance, scheduling, support, projects, stock, point of sale, Brains, channels, automations, and Workforce became visible modules. The gateway and tool registry remained important, but they were no longer the whole product. They became part of a larger operating loop.

The pivot was a change in authority

The most important transition was not from “few screens” to “many screens.” It was from conversational authority to record authority.

In a conversation, the latest message can redefine the immediate task. In an ERP, a submitted stock entry is not overwritten because the next message changed its mind. A party identity cannot be merged across organizations because two names look similar. A role cannot inherit a write simply because its UI button is visible.

MINION therefore became more explicit about boundaries:

1. Resolve the trusted organization and principal.
2. Check module and action capability.
3. Validate a typed request.
4. Preview or confirm high-consequence actions.
5. Commit the mutation inside the organization boundary.
6. Record the operational result and expose a recovery path.

The assistant still matters. The difference is that it now operates inside the same constraints as the rest of the platform.

A platform, not a feature catalog

It would be easy to tell this history as a list of modules. That would miss the point. MINION became an ERP when different modules began sharing governed infrastructure:

• the party spine connects people and organizations to operational records;
• stock movements are documents and append-only ledger rows, not editable counters;
• POS composes catalog, shifts, payments, parties, bookings, and stock;
• Brains organize business knowledge without discarding source and access boundaries;
• agent actions use the same authorization and validation concepts as human-facing mutations;
• projects can connect work, repositories, and factory gates.

The platform is valuable when those connections reduce the number of incompatible truths an organization must maintain.

The record has seams

This is a retrospective, not a mythology. Some infrastructure exists as a direction or a validated parallel path rather than as the current application default. For example, the Hub’s committed domain events use PostgreSQL notification with scheduled work as a durability fallback. A private JetStream path was designed and validated separately for burst absorption and bounded workers, but that does not make it the asserted application event plane.

Keeping those distinctions visible is part of the product discipline. A specification records intent. Code records an implementation. A deployed dark path proves infrastructure. None of those alone proves that production traffic moved.

Keep the governed record spine

I would preserve the organization boundary, the shared permission vocabulary, the preference for one record spine over point-to-point matches, and the insistence that an agent action becomes an ordinary governed mutation before it becomes convenient.

Publish the authority map

I would make the platform evolution legible earlier. A growing system needs a public map of authority: canonical records, event contracts, action boundaries, and the status of each migration. That map should be generated from code and tests where possible, not maintained as a second aspirational architecture.

Any assistant asked to perform durable business work eventually confronts ERP questions. MINION became interesting when it stopped hiding from them.