Define custom fields and records, deploy the module to one workspace or an agency fleet, and inherit tenant isolation, permissions, record pages, and activity history from the platform itself.
Describe the records your operation actually keeps — fields, types, and relationships — without leaving the platform they are going to live on.
02
Deploy to one tenant or a fleet
Ship a module to a single workspace, or to every client under an agency, from the same definition and with the same guarantees.
03
Isolation is inherited
A custom module is workspace-isolated by construction. It does not get its own database, and it does not get its own tenancy bugs.
04
Permissions are inherited
Roles, module access, and user grants apply to custom records exactly the way they apply to invoices, tasks, and employees.
05
Record pages and history
Custom records arrive with list views, detail pages, and an activity history, so nobody rebuilds those surfaces for the fourth time.
06
Reachable by the assistant
Because it is a real module on the shared action layer, the assistant can read and act on it under the same authority it has everywhere else.
Specifications
Engineered to a standard, not a slogan.
Extensibility
Custom fields and records
Custom operations extend the core instead of forking it, which is what keeps upgrades from becoming migrations.
Data model
Workspace-isolated by construction
Custom records are tenant-scoped on the same schema as the built-in modules, filtered by workspace like everything else.
Permissions
Inherited, not reimplemented
Role, module, and grant checks apply to custom records without anyone writing a second authorization layer.
Deployment
One tenant or an agency fleet
The same module definition installs into a single workspace or across every client workspace an agency operates.
Audit
Activity history included
Custom records carry the same activity history and record pages the rest of the workspace has.
Assistant access
Same authority as the user
Custom modules are reachable by the assistant, the API, and MCP through the shared action layer, under the caller's own permissions.
Frequently Asked Questions · Module Builder
What teams ask about Module Builder before they move their operations.
Custom fields and custom records for operations the standard modules do not cover, kept inside Agaro rather than pushed into a spreadsheet beside it. You define the records your business actually tracks — inspections, claims, equipment loans, whatever is missing — and they become first-class records in the workspace, with record pages, activity history, permissions, and workspace isolation inherited from the platform. Nothing about a custom record is second-class: it is stored in the same workspace isolated PostgreSQL, reached through the same shared action layer, and covered by the same audit history as an invoice. That inheritance is the point. Teams normally extend an ERP by leaving it; the module builder exists so the extension keeps the controls, the permission model, and the assistant the rest of the workspace already has.
Yes, by inheritance rather than by configuration. A module you define picks up workspace isolation, the role and grant model, record pages, and activity history from the platform, so a custom record is protected and traced the same way a payroll register is. Reads and writes go through the same guarded business logic every other action uses, which means validation, authorization, transaction handling, and the activity log apply without you wiring any of it. Access is a role and grant question exactly as it is elsewhere: a user without the module sees nothing of it, and neither does their assistant. This is also why custom work does not open a governance gap. There is one audit trail per workspace covering standard and custom records alike, not a well-controlled core with an unmonitored extension bolted to the side.
Yes. Because custom records live inside Agaro and are reached through the same shared action layer, the assistant can create, find, update, and act on them the way it does invoices or tasks — bounded by the same role, module access, grants, model permissions, and workspace. If a user cannot open the module, prompts about its records return nothing. If they can, the assistant resolves real records before acting and writes the outcome to activity history under their identity. That is a meaningful difference from extending an ERP with an external tool, because work that leaves the platform also leaves the assistant's reach and the audit trail. Keeping the extension inside means one execution path — prompt, identity, access, resolve data, engine, action, audit — covers the parts of your operation nobody else's ERP models.
Yes. A module can be deployed to a single tenant or across an agency fleet, so an agency that has built a client onboarding record set can roll it out to every client workspace it operates from the control plane above them. The tenant boundary does not soften when a module is shared: each client workspace keeps its own records, users, permissions, and audit history, and a deployed module runs inside that isolation rather than across it. Staff reach a client's data only through their assigned access, and their assistant reaches exactly the same. For a product-minded agency that is the difference between rebuilding the same customization for every client and maintaining one module every client workspace inherits while their data stays strictly separate. Updating it is one job rather than a dozen, and each workspace still enforces its own roles and grants over the records it holds.
Agaro ERP is an AI native ERP from Agaro Technologies LLC, built so the software can do the work rather than only record it. It covers finance and invoicing, HR and payroll, CRM and leads, marketing, inventory and supply chain, manufacturing, projects and tasks, an app and website builder, a module builder, agency mode, and the AGARO Assistant — one connected workspace instead of a stack of tools that have to agree with each other. ERP has always held the facts: the customer, the price, the hours, the contract, the approvals. Someone still had to find the records, calculate the result, push the buttons, and reconcile what happened. Agaro closes that gap by giving the assistant the same authority the prompting user has and keeping deterministic engines in charge of money, pay, and stock. It is launching soon.
It does not decide; your access does. The prompting user is the identity and their workspace is the data boundary, and the assistant inherits all of it: same role, same module access, same user grants, same model permissions, same workspace. If the user cannot perform an action, the assistant cannot perform it. Every prompt follows one path — prompt, identity, access, resolve data, engine, action, audit — and access is checked before any record is read, so a request outside your permissions stops before data is resolved rather than being declined politely after the fact. The model's role is narrow by design: it selects an action, and Agaro decides whether and how that action executes. Anything that commits or delivers is presented for confirmation, and everything that happens is recorded under your identity in your workspace's audit history.
It means no route from a model to your data skips the business logic. The product interface, the AI assistant, the API, and MCP all resolve to a signed in actor with a workspace, role, modules, and model permissions, then pass through one shared action layer where input validation, authorization, the transaction, and the activity log happen. Only then do the finance, payroll, inventory, CRM, and workflow engines run, against workspace isolated PostgreSQL data and audit history. A button click and an assistant tool call reach the same guarded business logic. Practically, that is why the model never calculates an invoice total, a payroll register, or a stock quantity: the engines do, deterministically, and the same request produces the same result whichever route it arrived on. Same identity, same controls, same business actions, one audit trail.
Agaro ERP is launching soon. We are not publishing a date, because the parts that have to be right — the finance and payroll engines, the single stock-write path, the permission model binding the assistant to the user — are the parts worth finishing properly rather than shipping to a calendar. Early access is by talking to us. Tell us what you run today, which modules matter first, and whether you operate one business or a portfolio of client businesses through agency mode, and we will tell you plainly whether Agaro fits and when. If it does not fit yet, we would rather say so than take the signup. You can sign up on agaro.ai to be told when it opens, or reach Agaro Technologies LLC directly at [email protected] or +1 (571) 278-8979. The company is based in Brambleton, Virginia.
The AGARO Assistant can do anything the prompting user can do. It is not a search box or a summarizer bolted onto a report screen — it creates and updates records, runs workflows, and completes transactions inside the ERP. Ask it to invoice a customer and it resolves the real customer, the catalog item, the stored price, the workspace currency, tax, and payment terms, then calls the finance engine to validate the request, calculate totals, allocate the invoice number, create the invoice, and commit the journal. It can create and assign tasks, move projects, prepare a payroll run, raise a purchase, or record a stock movement, each through the same server action a person triggers by clicking. When something is missing it asks. When an action needs confirmation, such as sending a document to a customer, it presents that action and waits for you.
By the prompting user. The signed in user is the identity and their workspace is the data boundary, so the assistant inherits the same role, the same module access, the same user grants, the same model permissions, and the same workspace. If the user cannot perform an action, the assistant cannot perform it. There is no service account with elevated rights sitting behind the chat window and no side channel into the database. Every prompt follows one controlled path: prompt, identity, access, resolve data, engine, action, audit. Access is evaluated before any record is read, engines validate and calculate before anything is written, and the outcome is recorded under the user who asked, not under the model. The model selects an action; the ERP decides whether and how that action executes. The audit history reads the same whether the work was done by clicking or by prompting.
Get early access to Module Builder
Agaro ERP is launching soon. Tell us how you run this part of the business today and we will show you how the assistant runs it inside Agaro.