Introduction to AI GO

AI GO is a platform for building your own business applications. It ships with a complete enterprise data foundation already in place — accounting, sales, purchasing, inventory, manufacturing, CRM, HR, and projects — and opens up full development and API access on top of it, so you can assemble that data into applications that match how your company actually works.

Put differently: AI GO does not hand you an ERP interface you have to adapt to. It hands you a foundation where the tables, the relationships, and the business engines are already built, plus the tooling to build on top of it.

The three layers

Understanding AI GO means understanding three layers.

Layer 1: Data (the Data Center)

The platform ships a complete enterprise data model — not just empty tables, but the relationships between them and the cross-module business engines already wired up. Confirming a sales order flows into fulfillment and invoicing; an inventory movement immediately produces a stock valuation entry; posting a payment automatically reconciles invoices on a first-in-first-out basis.

On top of that you can:

• Create custom tables (organization-level, shared by every application)
• Add extension fields to existing ERP tables
• Store industry-specific data in the custom_data JSONB column every table carries

Layer 2: Applications (Custom Apps)

A Custom App is what you actually ship to users. It can be an internal tool for staff, or an external application for customers and suppliers.

Every Custom App receives a full set of capabilities the platform has pre-built — read and write data, trigger ERP business actions, submit approvals, search enterprise knowledge, call external APIs, run on a schedule, receive webhooks. You do not implement these. You call the SDK. This is what most of this guide is about.

Layer 3: Access (four equal entry points)

The same data and the same service layer, reachable four ways:

All four hit the same service layer with the same guardrails. Nearly everything the Dashboard UI can do, the API can do too — you can use AI GO as a pure backend service and never open the Dashboard.

This matters because it shapes how you adopt the platform: you do not have to move your team onto a new back-office interface. You can wire AI GO's capabilities into the systems and workflows you already have.

Two kinds of data, one foundation

Custom tables are organization-level resources — every application under the same organization sees the same tables and the same rows. That is deliberate: it prevents two apps from each creating their own "customers" table and splitting one dataset into two.

One code sample explains the model

Here is a Custom App server-side action showing how the pre-built capabilities compose:

def execute(ctx):
    # 1. Read a built-in ERP table (authorized columns only)
    orders = ctx.db.query('sale_orders', filters=[
        {'column': 'state', 'op': 'eq', 'value': 'draft'}
    ])

    # 2. Search the enterprise knowledge base for the discount policy
    policy = ctx.knowledge.search('large order discount policy', top_k=3)

    # 3. Trigger the ERP engine (confirming cascades into invoicing and fulfillment)
    confirmed = 0
    for o in orders:
        if o['amount_total'] < 100000:
            ctx.erp.confirm_sale_order(o['id'])
            confirmed += 1

    # 4. Call an authorized external service
    ctx.http.call('notify', '/send', method='POST', body={'count': confirmed})

    ctx.response.json({'confirmed': confirmed})

None of these four things — querying ERP data, retrieving from the knowledge base, triggering the business engine, calling an external service — has to be implemented by you. The platform pre-builds them and hands them to your application as an SDK.

Who uses which layer

• Developers / IT: mostly the application and access layers. Build with the App Builder or straight against the API; reach the data layer through the SDK.
• Administrators: configure the data model, permissions, approval workflows, and business rules in the Dashboard. Those settings apply automatically across all entry points.
• Operations staff: only ever see a Custom App or the AI assistant.
• External systems: connect via REST API with an API key. Nobody has to log into a UI.

Security model at a glance

Authorization in AI GO is layered, not a single switch:

1. Tenant isolation — all data is anchored to an organization; cross-organization access is reported as nonexistent.
2. References — an application must explicitly declare which table, which columns, and which operations it needs. Anything undeclared is unreachable.
3. Scope approval — an application declares which capability groups it needs (read data, write data, trigger ERP, read secrets…). An administrator approves them; expanding into high-risk capabilities requires the owner to re-enter their password on the spot.
4. Role-based access control — what a user can see and do is determined by their roles.
5. File-level access policy — every file in the Knowledge Center has its own policy, and AI retrieval obeys the same policy.
6. Egress allowlist — applications can only call explicitly authorized external domains.

Every SDK call is audited.

What to read next