---
title: "Introduction to AI GO"
category: "getting-started"
canonical: "https://www.ai-go.app/en-US/docs/guide/introduction"
locale: "en-US"
last_updated: "2026-08-10"
source: "AI GO 開發者文件（https://www.ai-go.app）"
---

# 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:

| Entry point | Who it's for | Notes |
|---|---|---|
| **REST API** | Third-party systems, automation, external developers | Authenticated by API key or token; covers ERP tables, custom tables, approvals |
| **Custom App** | Operations staff, external partners | Dedicated URL; users see only what's relevant to their job |
| **Dashboard** | Administrators and developers | Configuration, development, auditing |
| **AI assistant (Cowork)** | Everyone | Natural-language query and action |

**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

| | Built-in ERP tables | Custom tables |
|---|---|---|
| Defined by | The platform | You |
| Owned by | The organization | **The organization** (not a single app) |
| Relationships | Cross-module relations and engines pre-wired | `relation` fields link tables to each other |
| Authorization | Requires a declared reference | Naturally shared across apps |
| Typical use | Orders, invoices, stock, employees | Industry-specific data (measurements, event sign-ups) |

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:

```python
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

| What you want to do | Chapter |
|---|---|
| Get an account and figure out where to log in | 2. Accounts, Login, and Access Paths |
| See what the Dashboard offers — and why it isn't the only way in | 3. Dashboard Tour |
| Learn which tables and relationships come pre-built | 4. The Data Center |
| Build your own tables | 5. Custom Tables |
| Start developing an application | 7. The App Builder |
| **See every capability your app gets for free** | **8. The SDK** |
| **Drive the platform by API instead of UI** | **11. API Overview** |