AI Builder

Der AI Builder ist die primäre Methode, mit der Kunden ObjectOS erweitern. Öffne die Console, sprich mit dem Assistenten in einfacher Sprache, und er erstellt die Metadaten für dich — Pakete, Objekte, Felder, Aktionen, Flows. Jede Änderung wird in einer Human-in-the-Loop (HITL) Genehmigungsliste eingereiht, bevor sie live geht.

Probiere es in 30 Sekunden

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

Du hast jetzt eine funktionierende Ticketing-App — REST-Endpunkte, Console-Ansichten, Audit-Log-Einträge, Berechtigungskontrollen, alles inklusive. Es wurde keine Datei bearbeitet; es fand kein Neustart statt.

Was die AI kann

Der Assistent hat Zugriff auf eine Reihe integrierter Metadaten-Tools, die alle mit Namespace versehen und gegen @objectstack/spec validiert sind:

Hinzu kommen Action-Tools, die aus jedem deklarierten *.action.ts materialisiert werden — benannt action_<name> — sodass die AI eine Aktion, sobald sie im Paket existiert, wie jedes integrierte Tool aufrufen kann.

Den vollständigen Tool-Katalog zur Laufzeit ansehen: GET /api/v1/ai/tools.

Human-in-the-Loop Genehmigung

Tool-Aufrufe, die Metadaten verändern, werden über eine Warteschlange für ausstehende Aktionen geleitet. Genehmigende Operatoren sehen den vorgeschlagenen Änderungs-Diff, bevor sie auf Genehmigen klicken.

Erforderliche Berechtigungen:

Standard: Nur Mitglieder von Setup Administrator haben ai:approve. Du kannst feiner unterteilen in Permission Sets — z. B. „Product Owner können in com.acme.crm genehmigen, sonst niemand.“

Die Warteschlange ist auditierbar: Jede Genehmigung/Ablehnung landet in sys_audit_log mit der ID der ursprünglichen Konversation.

Konversationen und Kontext

Jeder Chat ist ein ai_conversations-Datensatz. Die Plattform verfolgt:

• Aktives Paket — gesetzt durch set_active_package. Neue Objekte / Felder landen hier.
• Skills — der Ausschnitt der Tools, die für den aktuellen Kontext verfügbar sind (z. B. innerhalb der support_ticket-Detailseite kann die AI support_ticket-bezogene Skills aktiviert haben).
• Wissen — RAG-Themen + Indizes, die der Konversation angehängt sind.

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

Die Plattform ermittelt den Standard-Agent für die aktive Anwendung, filtert die Skill-Menge nach Kontext und lässt das LLM auswählen, welches Tool aufgerufen werden soll. Du verdrahtest Agents nicht vorab fest in bestimmte UIs — der Agent hängt sich basierend auf den Metadaten selbst an.

Was du anfragen kannst

Verifizierte Muster, mit Einzeiler-Prompts:

Wenn die AI etwas nicht kann, sagt sie es — und verweist dich auf den manuellen Weg (meist eine 30-zeilige *.ts-Datei oder ein Console-Formular).

Live-Vorschau

Nach jeder genehmigten Änderung rendert die Console die betroffenen Ansichten an Ort und Stelle neu. Kein Neuladen erforderlich. Der Kernel-Cache invalidiert das berührte Paket; nachfolgende Anfragen verwenden die neuen Metadaten.

Zurückrollen

Datensätze ausstehender Aktionen behalten den Vorher-Zustand. Wenn eine Änderung schiefgeht, lehne alle laufenden Elemente ab und frage die 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]

Für größere Rollbacks verwende os diff gegen dein letztes als funktionierend bekanntes Artefakt und wende den umgekehrten Diff an.

Einschränkungen (heute)

• Der Datenzugriff folgt den eigenen Berechtigungen des Operators. Der Assistent läuft als der angemeldete Benutzer, sodass er nur Datensätze lesen oder schreiben kann, die dieser Benutzer bereits bearbeiten darf. Die meisten Teams halten den Assistenten auf Metadaten fokussiert und lassen ihn Kundendaten abfragen — nicht verändern.
• Paketübergreifende Mutationen erfordern eine ausdrückliche Bestätigung. Die AI zu bitten, ein Systempaket (sys_*) zu modifizieren, gibt eine Ablehnungs- meldung zurück — die Plattform verweigert dies aus Prinzip.
• Langlaufende mehrstufige Pläne (z. B. „eine komplette HR-App von Grund auf bauen“) funktionieren, werden aber am besten als eine Reihe kleinerer Konversationen durchgeführt, von denen jede ein oder zwei Objekte umsetzt.

Über die Build-Time-AI hinaus

Dieselbe AI-Infrastruktur betreibt Runtime-Agents für deine Endbenutzer — Support-Assistenten, Sales-Co-Piloten, interne Q&A-Bots — aufgebaut auf derselben Agent → Skill → Tool Architektur. Siehe Agents.

Wie es weitergeht

• Agents — Endbenutzer-Assistenten auf Basis deiner Daten
• Data Model — was die AI tatsächlich generiert
• Actions — die Einheit, die die AI als Runtime-Tools bereitstellt
• AI Service — Provider-Konfiguration (OpenAI / Anthropic / Doubao / …)