AI Builder

The AI Builder is the primary way customers extend ObjectOS. Open Console, talk to the assistant in plain language, and it builds the metadata for you — packages, objects, fields, actions, flows. Every change is queued in a Human-in-the-Loop (HITL) approval list before it goes live.

Try it in 30 seconds

You: I need to track customer support tickets.
     Each ticket has a subject, description, priority (low/medium/high/urgent),
     status (new/open/pending/resolved/closed), and assignee.

AI:  I'll create that for you. Here's the plan:
     • Create package `com.you.support` (v0.1.0)
     • Create object `support_ticket` with 5 fields
     • Add a kanban view grouped by status
     • Add 3 permission sets: agent, manager, viewer

     Approve? [Yes] [Modify] [Cancel]

You: [Yes]

AI:  ✓ Package created
     ✓ Object created with 5 fields and 12 indexes
     ✓ Kanban view registered
     ✓ Permission sets created
     Done. Try it: /support_ticket

You now have a working ticketing app — REST endpoints, Console views, audit log entries, permission checkpoints, the works. No file was edited; no restart happened.

What the AI can do

The assistant has access to 11 built-in metadata tools, all namespaced and validated against @objectstack/spec:

Plus action tools materialized from every declared *.action.ts — named action_<name> — so once an action exists in the package, the AI can call it like any built-in tool.

See the full tool catalog at runtime: GET /api/v1/ai/tools.

Human-in-the-Loop approval

Tool calls that mutate metadata route through a pending-action queue. Approving operators see the proposed change diff before clicking Approve.

Required permissions:

Default: only members of Setup Administrator have ai:approve. You can decompose finer in Permission Sets — e.g. "product owners can approve in com.acme.crm, nobody else."

The queue is auditable: every approve/reject lands in sys_audit_log with the originating conversation id.

Conversations and context

Each chat is a sys_ai_conversation record. The platform tracks:

• Active package — set by set_active_package. New objects / fields land here.
• Skills — the slice of tools available for the current context (e.g. inside support_ticket detail page, the AI may have support_ticket-scoped skills enabled).
• Knowledge — RAG topics + indexes attached to the conversation.

POST /api/v1/ai/assistant/chat
{
  "messages": [{ "role": "user", "content": "Add a tags field to support_ticket" }],
  "context":  { "objectName": "support_ticket", "recordId": "tkt_123" }
}

The platform resolves the default Agent for the active application, filters the skill set by context, and lets the LLM pick which tool to call. You don't pre-wire agents into specific UIs — the agent attaches itself based on metadata.

What you can ask for

Verified patterns, with one-liner prompts:

If the AI can't do it, it says so — and points you at the manual path (usually a 30-line *.ts file or a Console form).

Live preview

After each approved change, Console re-renders the affected views in place. No reload needed. The kernel cache invalidates the touched package; subsequent requests use the new metadata.

Roll back

Pending-action records keep the before state. If a change goes wrong, reject any in-flight items and ask the AI:

You: Roll back the last 3 changes to support_ticket.
AI:  Found 3 mutations from conversation conv_abc (3 minutes ago).
     Restoring 'support_ticket' to its state at 13:42:11.
     Approve? [Yes]

For larger rollbacks, use os diff against your last known-good artifact and apply the reverse diff.

Limitations (today)

• The assistant is read-only on customer data by default. It can query records but cannot insert/update/delete unless given the ai:write_data permission. Most customers leave this off.
• Cross-package mutations require explicit confirmation. Asking the AI to modify a system package (sys_*) returns a rejection message — the platform refuses on principle.
• Long-running multi-step plans (e.g. "build a full HR app from scratch") work but are best done as a series of smaller conversations, each landing one or two objects.

Going beyond build-time AI

The same AI plumbing powers runtime agents for your end users — support assistants, sales co-pilots, internal Q&A bots — built on the same Agent → Skill → Tool architecture. See Agents.

Where to go next

• Agents — end-user assistants on top of your data
• Data Model — what the AI is actually generating
• Actions — the unit the AI exposes as runtime tools
• AI Service — provider config (OpenAI / Anthropic / Doubao / …)