Was fehlt AI-Modellen im Unternehmen? Eine Welt, Hände und ein Zaun

Welt. Was es in diesem Geschäft gibt, wie jedes Ding typisiert ist und wie die Dinge zusammenhängen.

Hände. Die Operationen, die ein Agent an dieser Welt ausführen darf, angeboten als Tools, die er aufrufen kann.

Zaun. Wer was darf, entschieden bei jedem Aufruf statt einmal, und danach aufgezeichnet.

Das sind die drei Dinge, die einem AI-Modell fehlen, wenn es in ein Unternehmen kommt, und Intelligenz steht nicht auf der Liste. Der Satz stammt von ObjectStack, geschrieben für den Abschnitt „00 · The idea“ seiner Startseite: “What the model lacks is not intelligence: a world, hands, and a fence.” (Was dem Modell fehlt, ist nicht Intelligenz: eine Welt, Hände und ein Zaun.) Dieser Beitrag stellt die engere, prüfbare Behauptung dahinter auf: Eine ausführbare Geschäftsontologie liefert alle drei aus einem Artefakt, und jede Lieferung entspricht einem benannten Runtime-Mechanismus, den man im Quellcode nachlesen kann. Die Tabelle unten ist diese Zuordnung, mit Datei und Zeile für jede Zelle. Danach: was jede Lieferung ist, eine Zahl, gemessen am mitgelieferten CRM-Beispiel, die stärkste Alternative fair dargestellt, und was all das nicht löst.

Woher der Satz kommt

Vom 2026-10-12 bis zum 2026-10-27 formulierte die Startseite von objectstack.ai die Idee in drei Sätzen, die der Quellcode der Seite wörtlich festhielt (apps/docs/app/[lang]/page.tsx, Zeilen 127–131 bei Commit 712361b7, dem Commit, der den Abschnitt hinzufügte; der Kommentar darüber lautet „verbatim from the maintainer’s ruling“, also wörtlich aus der Entscheidung des Maintainers):

An enterprise is definition plus execution. When execution is nearly free, it is its definition.

What the model lacks is not intelligence: a world, hands, and a fence.

An ontology written clearly enough is software. Models change; the ontology stays.

(Ein Unternehmen ist Definition plus Ausführung. Wenn Ausführung fast nichts mehr kostet, ist es seine Definition. Was dem Modell fehlt, ist nicht Intelligenz: eine Welt, Hände und ein Zaun. Eine klar genug geschriebene Ontologie ist Software. Modelle wechseln; die Ontologie bleibt.)

Eine Anmerkung zur Herkunft, weil dieser Beitrag jede andere Quelle bei einem getaggten Release liest. Der Umbau, der objectstack.ai zur Entwicklerseite machte (61c07986, 2026-10-27), hat den Abschnitt eingestellt, sodass die drei Sätze beim Tag @objectstack/cli@18.3.0 nicht mehr im Repository stehen. Die Idee ist weiterhin die, die der Rest dieses Beitrags prüft, und die Prüfung hängt nicht davon ab, wo der Satz gedruckt steht.

Lesen Sie den mittleren Satz als Diagnose. Jedes Enterprise-AI-Pilotprojekt verbindet ein fähiges Modell mit einem Unternehmen und entdeckt dann, einen Vorfall nach dem anderen, dass das Modell nicht wusste, was ein „Account“ in diesem Unternehmen ist (keine Welt), dass es einen nicht wirklich ändern konnte (keine Hände) oder dass es einen geändert hat, den es nicht hätte anfassen dürfen (kein Zaun). Die übliche Antwort ist, jedes fehlende Stück einzeln zu kaufen: eine Retrieval-Schicht für die Welt, eine Function-Calling-Schicht für die Hände, eine Policy-Schicht für den Zaun. Das ist eine vernünftige Antwort, und die zweite Hälfte dieses Beitrags lässt ihr Gerechtigkeit widerfahren. Der erste und der dritte Satz sagen, warum ObjectStack einen anderen Weg geht: Wenn die Definition des Geschäfts präzise genug geschrieben ist, um ausgeführt zu werden, dann ist dieselbe Definition die Welt, erklärt die Hände und trägt den Zaun, und sie überlebt jedes Modell, das sie in diesem Quartal gerade liest.

Drei Lieferungen, ein Artefakt

Die einzeilige Definition der ObjectStack-README lautet: „Eine ausführbare Geschäftsontologie. AI schreibt sie, die Runtime führt sie aus, Agents bedienen sie, Sie besitzen sie.“ Die Konzeptseite nennt als ihren Kern sechs Arten von Dingen: Objekte und Felder, Relationen, Aktionen, Berechtigungen, Flows sowie Agent- und Tool-Definitionen. Die Behauptung dieses Beitrags ist, dass sich diese sechs Arten in die drei Lieferungen einsortieren und dass die Runtime jede davon in etwas verwandelt, das der Agent nutzen kann, ohne dass jemand Klebstoff schreibt. Hier ist die Zuordnung. Jede Quelle ist eine Datei in objectstack-ai/objectstack beim Tag @objectstack/cli@18.3.0 (gelesen am 2026-11-04, dem Release, das npm create objectstack@latest an diesem Tag installiert) oder eine Seite seiner Dokumentation, die aus demselben Repository gebaut wird.

Was dem Modell fehlt	Geliefert von (in der Ontologie)	Der Runtime-Mechanismus, und wo er steht
Eine Welt — die Substantive: welche Entitäten es gibt, wie jede typisiert ist, wie sie zusammenhängen	Objekte und Felder; Relationen (zwei der sechs Arten)	Eine typisierte Definition wird nach objectstack.json kompiliert; daraus leitet die Runtime das Datenbankschema, die REST- und Realtime-API, die Console-UI und einen MCP-Server ab (ontology.mdx:64-70). Der Agent liest diese Welt mit list_objects und describe_object (connect-mcp.mdx:225-229).
Hände — die Verben: was mit diesen Substantiven getan werden darf	Aktionen, Flows und die Datensätze selbst	Die laufende App ist ein MCP-Server unter /api/v1/mcp, standardmäßig eingeschaltet; Objekte werden automatisch exponiert, Aktionen melden sich mit ai: { exposed: true } an (README.md:136-151). Das Opt-in ist ein Schemafeld mit Vorgabe false, das eine LLM-gerichtete Beschreibung von mindestens 40 Zeichen verlangt (action.zod.ts:815-822).
Ein Zaun — wer was darf, auf welchen Zeilen und Feldern, geprüft bei jedem Aufruf und aufgezeichnet	Berechtigungen, Zeilen- und Feldsicherheit, Sharing, Audit	Sicherheit ist eine Middleware, die auf der ObjectQL-Engine registriert ist, sodass jede Engine-Operation sie durchläuft (security-plugin-authz-middleware.ts:4-7). MCP-Tools laufen unter dem Principal des Aufrufers über “the SAME permission/RLS-enforcing path the REST API uses” (denselben berechtigungs- und RLS-durchsetzenden Pfad, den die REST-API nutzt) (mcp-http-tools.ts:7-11). Audit-Zeilen werden von Engine-Hooks bei jedem Insert, Update und Delete geschrieben (audit-writers.ts:2435-2440).

Wo die Dateien liegen, damit die Zitate geöffnet werden können: README.md im Wurzelverzeichnis des Repositorys; ontology.mdx unter content/docs/concepts/ und connect-mcp.mdx unter content/docs/ai/; action.zod.ts in packages/spec/src/ui/; security-plugin-authz-middleware.ts in packages/plugins/plugin-security/src/; mcp-http-tools.ts in packages/mcp/src/; audit-writers.ts in packages/plugins/plugin-audit/src/. Die Zeilennummern sind die des Tags.

Die Konzeptseite verdichtet die rechte Spalte zu einem Satz, der es wert ist, ganz zitiert zu werden: Die Runtime “enforces the definition on every call. RBAC, row-level and field-level security, sharing, and audit apply to a REST request, a Console click and an agent’s tool call alike. Nothing is reasoned over at runtime: what runs is what was validated.” (setzt die Definition bei jedem Aufruf durch. RBAC, Zeilen- und Feldsicherheit, Sharing und Audit gelten für eine REST-Anfrage, einen Console-Klick und den Tool-Aufruf eines Agents gleichermaßen. Zur Laufzeit wird über nichts geschlossen: Was läuft, ist das, was validiert wurde.)

Der Rest des Beitrags geht die drei Zeilen durch.

Die Welt: eine Definition, die auch die Runtime liest

Die Welt eines Modells muss zwei Leser zugleich zufriedenstellen. Das Modell braucht sie klein und explizit genug, um sie ganz zu halten; die Runtime braucht sie präzise genug, um sie auszuführen. Dokumente stellen den ersten Leser zufrieden und den zweiten nicht: Ein abgerufenes Richtlinien-PDF sagt dem Modell, was eine Opportunity ist, und nichts prüft, ob die Datenbank zustimmt.

Die Welt einer ausführbaren Ontologie ist die typisierte Definition selbst. Die Konzeptseite: Die Ontologie “is the definition of your business that the runtime executes: authored as typed metadata in objectstack.config.ts, compiled into the objectstack.json artifact.” (ist die Definition Ihres Geschäfts, die die Runtime ausführt: verfasst als typisierte Metadaten in objectstack.config.ts, kompiliert in das Artefakt objectstack.json.) Objekte und Felder erklären die Entitäten und ihre typisierten Attribute; Relationen erklären Lookups und Master-Detail-Verknüpfungen. Die Runtime leitet die Tabellen und die Endpunkte aus dieser Definition ab, und das Tool describe_object des MCP-Servers antwortet aus derselben Definition. Die Welt, die der Agent liest, ist also konstruktionsbedingt die Welt, die läuft. Es gibt keine zweite Beschreibung, die abdriften könnte.

Zwei Konsequenzen folgen, und beide sind an anderer Stelle in diesem Blog bereits begründet, also werden sie verwiesen statt wiederholt. Erstens ist die Welt begrenzt: Views, Dashboards, Apps und Übersetzungen sind Projektionen der Ontologie, nicht Teil von ihr, und genau das erlaubt einem Agent, vom Kern aus über das Geschäft zu schließen statt von jedem Bildschirm aus (der Grundsatzbeitrag enthält den Entfernungstest, um beides auseinanderzuhalten). Zweitens wird die Welt validiert, bevor sie läuft: os validate lehnt eine Definition ab, die zwar den Typcheck besteht, aber zur Laufzeit stillschweigend scheitern würde, einschließlich einer fehlenden Sicherheitshaltung, sodass die Welt, die ein Agent übergeben bekommt, für jede hängende Referenz darin schon einmal zurückgewiesen wurde.

Die Hände: Tools, die der Autor scharfgeschaltet hat, nicht Tools, die das Modell geraten hat

Hände sind der Teil, den die meisten Enterprise-AI-Stacks schon haben, in Form von Function Calling. Der Unterschied, den eine ausführbare Ontologie macht, liegt darin, wer entscheidet, welche Hände es gibt.

Objekte kommen standardmäßig mit Händen. Weil die Definition typisiert ist, stellt die Runtime sie als MCP-Server bereit: “Objects are tools, actions are tools, permissions decide what an agent may call, and audit records what it did” (Objekte sind Tools, Aktionen sind Tools, Berechtigungen entscheiden, was ein Agent aufrufen darf, und Audit zeichnet auf, was er getan hat) (README.md:138-139). Die connect-mcp-Seite listet, was ein Agent bekommt, als “Twelve tools, generated from your metadata” (zwölf Tools, aus Ihren Metadaten generiert): Entdeckung (list_objects, describe_object, validate_expression), Lesen (query_records, get_record, aggregate_records), Schreiben (create_record, update_record, delete_record) und Aktionen (list_actions, run_action, resume_run). Niemand schreibt eine Tool-Definition für ein neues Objekt; das Objekt ist das Tool.

Aktionen kommen standardmäßig nicht mit Händen, und das ist der beabsichtigte Teil. Eine Aktion wird für einen Agent erst aufrufbar, wenn ihr Autor ai: { exposed: true } setzt und die Beschreibung schreibt, nach der das Modell sie auswählt. Der Schemakommentar in action.zod.ts sagt warum: “This is a deliberate governance gate: in an AI-authoring world the platform’s value is that a human can govern exactly which capabilities the agent fleet is allowed to invoke — a half-finished or unreviewed action must never be silently armed.” (Das ist ein bewusstes Governance-Gate: In einer Welt, in der AI schreibt, liegt der Wert der Plattform darin, dass ein Mensch genau steuern kann, welche Fähigkeiten die Agentenflotte aufrufen darf — eine halbfertige oder ungeprüfte Aktion darf niemals stillschweigend scharfgeschaltet werden.) Das kleinste mitgelieferte Beispiel, die Todo-App, schaltet eine so scharf (examples/app-todo/src/actions/task.actions.ts, die reinen UI-Schlüssel gekürzt):

export const CompleteTaskAction = defineAction({
  name: 'complete_task',
  label: 'Mark Complete',
  objectName: 'todo_task',
  type: 'script',
  target: 'completeTask',
  ai: {
    exposed: true,
    description: 'Mark a todo task as complete. Use when the user says a task is done or finished.',
  },
});

Das mitgelieferte CRM dagegen schaltet keine scharf. Seine einzige Aktion, Convert Lead, ist eine flow-Aktion ohne ai-Block, sodass ein Agent, der mit dieser App verbunden ist, jedes Daten-Tool über ihre sechs Objekte hat und von list_actions eine leere Antwort bekommt. Das ist keine Lücke im Beispiel; es ist die Regel bei der Arbeit. Hände über Geschäftslogik werden durch eine geprüfte Zeile in der Definition gewährt, niemals aus der Tatsache abgeleitet, dass ein Button existiert.

Warum gerade Schreiboperationen diese eine gesteuerte Definition brauchen statt eines zweiten Tool-Pfads neben der UI, ist das Thema des Beitrags über Ontologie-Aktionen und wird hier nicht wiederholt.

Der Zaun: bei jedem Aufruf entschieden, von der Runtime

Ein Zaun, der im Prompt lebt, ist eine Bitte. Ein Zaun, der in einem Policy-Dienst vor den Tools lebt, ist ein Gate für Aufrufe. Der Zaun, den eine ausführbare Ontologie trägt, sitzt auf dem Datenpfad selbst, und dieser Unterschied entscheidet, wie weit ein Fehler reichen kann.

Der Mechanismus ist Middleware. plugin-security registriert seine Durchsetzung auf der ObjectQL-Engine (ql.registerMiddleware(...), security-plugin-authz-middleware.ts:2466, ausgeführt aus dem start() des Plugins), und das ist die Engine, durch die jedes Lesen und Schreiben geht, ob die Anfrage von einer REST-Route, einem Console-Klick oder einem MCP-Tool kam. Das MCP-Tool-Modul sagt in seinem eigenen Kopf, dass es die Daten-Engine nie direkt berührt: “all reads/writes go through an injected McpDataBridge that the host wires to the SAME permission/RLS-enforcing path the REST API uses. This module owns the tool shape; the bridge owns execution + security.” (Alle Lese- und Schreibzugriffe laufen über eine injizierte McpDataBridge, die der Host an denselben berechtigungs- und RLS-durchsetzenden Pfad anschließt, den die REST-API nutzt. Dieses Modul besitzt die Form der Tools; die Bridge besitzt Ausführung und Sicherheit.) Es gibt keinen agentenspezifischen Zaun, der mit dem menschlichen synchron gehalten werden müsste, weil es einen Zaun gibt. Wo genau jede Prüfung läuft und warum das Filtern der Modellausgabe zu spät kommt, begründet Wo Agent-Berechtigungen durchgesetzt werden.

Drei Eigenschaften dieses Zauns sind es wert, benannt zu werden, weil den alternativen Stacks meist mindestens eine fehlt.

Er entscheidet über Zeilen und Felder, nicht nur über Aufrufe. Berechtigungssets gewähren Erstellen, Lesen, Bearbeiten und Löschen auf Objektebene; Zeilensicherheit filtert, welche Datensätze ein Aufrufer sehen kann; Feldsicherheit maskiert, welche Spalten. Der Vertrag des Sicherheitsdienstes nennt die Fehlerhaltung des Zeilenfilters klar: “Access-narrowing answers fail CLOSED … a resolution failure returns a DENY filter (zero rows), never undefined” (Antworten, die den Zugriff einengen, schlagen GESCHLOSSEN fehl … ein Auflösungsfehler liefert einen DENY-Filter (null Zeilen), niemals undefined) (packages/spec/src/contracts/security-service.ts:28-31). Ein Modell, das alles verlangt, bekommt, was sein Benutzer sehen darf.

Er steuert Geschäftslogik getrennt, weil Logik kein Sicherheitsnetz hat. Objekt-CRUD ist auf jeder Zeile durch RLS und FLS begrenzt. Ein Aktionsrumpf ist es nicht: Einmal aufgerufen, “executes as TRUSTED app code,” (läuft er als VERTRAUENSWÜRDIGER App-Code), also “gates at invoke time: ai.exposed (the author’s explicit AI opt-in, ADR-0011) + the ADR-0066 D4 capability gate” (steuert die Bridge zum Aufrufzeitpunkt: ai.exposed (das explizite AI-Opt-in des Autors, ADR-0011) plus das Capability-Gate ADR-0066 D4) (mcp-http-tools.ts:1450-1455). Hände und Zaun treffen sich genau hier: Dieselbe Zeile, die eine Aktion scharfschaltet, ist die Zeile, die der Zaun prüft.

Er zeichnet auf. Audit-Writer sind Engine-Hooks auf afterInsert, afterUpdate und afterDelete (audit-writers.ts:2435-2440), sodass eine Zeile, die der update_record-Aufruf eines Agents geändert hat, genauso im Audit-Log landet wie eine in der Console geänderte Zeile, mit der handelnden Identität. Das vierte Gate der README fasst die Konsequenz in einen Satz: “The runtime enforces permissions and audit on every call, so even a wrong app stays inside the fence.” (Die Runtime setzt Berechtigungen und Audit bei jedem Aufruf durch, sodass selbst eine falsche App innerhalb des Zauns bleibt.)

Gemessen am mitgelieferten CRM

Eine Zahl, genommen an examples/app-crm beim Tag @objectstack/cli@18.3.0 und so gezählt, wie die README die App zählt: TypeScript unter src/, Tests ausgenommen. Die eigene Zahl der README, 1.873 Zeilen, trägt den Stempel eines früheren Commits (95294be3); von den 213 Zeilen, die die App seitdem gewonnen hat, sind 178 Übersetzungen:

find examples/app-crm/src -name '*.ts' -not -name '*.test.ts' | xargs cat | wc -l
# 2086

2.086 Zeilen in 30 Dateien sind die gesamte Anwendung. Ihre Verzeichnisse in die drei Lieferungen einsortiert:

Lieferung	Verzeichnis	Zeilen	Was darin steht
Welt	src/objects/	516	Sechs Objekte (Account, Kontakt, Lead, Opportunity, Opportunity-Position, Aktivität) mit ihren Feldern und Lookups
Hände	src/actions/ + src/flows/	240	Eine Aktion, Convert Lead, und der Screen-Flow, den sie startet
Zaun	src/security/	99	sales-positions.ts macht davon 89 aus: zwei Berechtigungssets, drei Positionen, wobei jede Position die Sets nennt, die sie verteilt
Verrohrung	Tool-Registrierung, Autorisierungs-Middleware, Audit-Code	0	Eine Suche nach registerTool, middleware, authoriz, checkPermission und audit über src/ findet vier Treffer, alle in Kommentaren

Der Rest sind Projektionen (Views, ein Dashboard, eine App, eine Seite, Übersetzungen, ein Analyse-Dataset) und Seed-Daten, um die es in diesem Beitrag nicht geht.

Nennen wir die Hauptzahl 89 Zeilen Zaun. Das ist die gesamte Autorisierungserklärung eines CRM mit sechs Objekten, und dieselben 89 Zeilen regieren die REST-API, die Console und alle zwölf MCP-Tools, weil alle drei die Daten über die Engine erreichen, auf der der Zaun montiert ist. Die ergänzende Zahl ist die Null: Die Anwendung erklärt ihre Welt, ihre Hände und ihren Zaun und enthält keinen Code, der irgendetwas davon mit dem Modell verdrahtet. Die Verdrahtung gehört der Runtime, und genau das ist der ganze Inhalt der Formulierung „ein Artefakt“.

Zwei ehrliche Fußnoten zur Messung. Die 89 Zeilen sind die eigene Erklärung der App; der Zeilenfilter und die Feldmaskierung, die sie implizieren, werden von der Runtime aus dem sharingModel jedes Objekts und aus diesen Berechtigungssets berechnet, sodass „der Zaun“ im laufenden System größer ist als seine Erklärung, wie es sein sollte. Und dieses CRM exponiert, wie oben erwähnt, keine Aktion für AI, sodass seine Hände über Geschäftslogik null sind, bis ein Autor eine scharfschaltet.

Die Alternative, fair dargestellt

Der übliche Weg, die drei Dinge zu liefern, ist ein Stack: Retrieval über Dokumente und Schemata für die Welt, Function Calling (oder ein Tool-Server, den Sie schreiben) für die Hände und eine Policy-Engine oder ein Gateway vor den Tools für den Zaun. Er verdient eine faire Anhörung, denn in etlichen Situationen ist er die richtige Antwort.

Er arbeitet mit den Systemen, die Sie schon betreiben. Nichts wird migriert; der Retriever indexiert, was existiert, und die Tools kapseln APIs, die es schon gibt. Jede Schicht ist das Beste ihrer Klasse und austauschbar, sodass ein besserer Retriever oder eine strengere Policy-Engine eingesetzt werden kann, ohne die anderen anzufassen. Die Muster sind gut verstanden, die Anbieter zahlreich, und ein Team, das bereits ein Tool-Gateway besitzt, hat den Großteil des Zauns schon stehen. Für einen Agent, dessen Aufgabe es ist, über ein Dutzend Altsysteme zu lesen und in keines zu schreiben, ist dieser Stack wahrscheinlich das, was Sie wollen, und eine ausführbare Ontologie über diesen Systemen ist nur lesend und früh.

Was er nicht löst, ist das, wovon der erste Satz der Startseite handelt: Die drei Lieferungen sind drei Artefakte, mit drei Eigentümern, und nichts prüft, ob sie übereinstimmen.

	RAG + Function Calling + Policy-Schicht	Eine ausführbare Ontologie
Welt	Ein Korpus, den das Modell liest; die Systeme lesen ihn nicht	Die Definition, die die Runtime ausführt; describe_object antwortet daraus
Hände	Von Hand geschriebene Tool-Schemata, eines pro Operation, neben den Systemen gepflegt	Objekte sind automatisch Tools; Aktionen melden sich mit einer geprüften Zeile an
Zaun	Ein Gate auf Tool-Aufrufen, meist mit der Autorität eines Service-Accounts hinter jedem Tool	Middleware auf dem Datenpfad, unter den Berechtigungen des aufrufenden Benutzers, Zeilen und Felder eingeschlossen
Drift	Drei Beschreibungen des Geschäfts, jede kann veralten	Ein Artefakt, validiert, bevor es läuft
Audit	Der Aufruf wird protokolliert; die Zeilenänderung ist das Problem des nachgelagerten Systems	Die Zeilenänderung wird mit der Identität protokolliert, auf jedem Pfad

Die Zaun-Zeile ist die, die in einem Vorfall am meisten zählt. Eine Policy-Schicht vor einem Tool get_customer kann entscheiden, ob der Agent es aufrufen darf. Sie kann meist nicht entscheiden, welche Zeilen der Benutzer des Agents im Ergebnis sehen darf, weil das Tool mit dem Zugangsdatensatz läuft, den die Integration bekommen hat. Zeilen- und Feldsicherheit auf dem Datenpfad beantwortet diese Frage für jeden Aufrufer, und zwar für einen Menschen und einen Agent auf dieselbe Weise.

Was das nicht löst

Ein Beitrag über einen Zaun sollte sagen, wo der Zaun endet.

Er liefert kein Urteilsvermögen. Der Zaun macht einen falschen Aufruf ablehnbar und nachvollziehbar; er macht den Aufruf nicht richtig. Ein Modell kann immer noch das falsche Tool wählen, ein Feld falsch lesen oder eine Aktion verlangen, die es nicht wollen sollte. Welt und Zaun begrenzen den Schaden. Intelligenz, das, was das Modell mitbringt, ist weiterhin das, was wählt.

Das Opt-in-Gate bewacht die Türen, die der Runtime gehören. Das Gate ai.exposed wird an der Aktionstür durchgesetzt, die vom MCP-Tool run_action erreicht wird. Die eigene Anmerkung der Spezifikation ist ausdrücklich: “REST /actions is NOT ai.exposed-gated and sits OUTSIDE this gate, so a human in front of that route is still yours to arrange” (REST /actions ist NICHT durch ai.exposed gesteuert und liegt AUSSERHALB dieses Gates, sodass ein Mensch vor dieser Route weiterhin von Ihnen zu arrangieren ist) (packages/spec/src/ai/tool.zod.ts:95-98). Berechtigungen gelten auf dieser Route weiterhin; das AI-Opt-in nicht.

Lese-Audit ist enger als Schreib-Audit. Jeder Insert, jedes Update und jedes Delete wird aufgezeichnet. Das Aufzeichnen von Detailansichten eines Datensatzes ist ein Opt-in pro Objekt, und Listen- und Suchergebnisse werden nicht auditiert (packages/plugins/plugin-audit/src/audit-plugin.ts:49-68). Ein Agent, der breit liest, hinterlässt eine kleinere Spur als einer, der schreibt.

Die Welt sind die Apps, die die Runtime ausführt. Für Systeme, die sie nicht ausführt, ist das Föderieren einer externen Datenquelle standardmäßig nur lesend und wird als früh beschrieben. Die drei Lieferungen decken ab, was die Ontologie ausführt; der Rest des Bestands braucht weiterhin den Stack oben oder eine Migration.

Eine exponierte Aktion ist vertrauenswürdiger Code. Das Tool run_action sagt es dem Modell in seiner eigenen Beschreibung: Der Aktionsrumpf “runs as trusted application code with the app’s full data authority.” (läuft als vertrauenswürdiger Anwendungscode mit der vollen Datenautorität der App.) Eine Aktion scharfzuschalten ist daher eine Review-Entscheidung, kein Schalter, und für die, die zuerst einen Menschen fragen sollten, gibt es requiresConfirmation: true.

Gehostet, oder auf Ihrer eigenen Infrastruktur

Alles oben ist der offene Stack, Apache-2.0, in einem Repository: Die Definition ist eine Datei, die Sie halten. Zum Ausführen liefert das ObjectStack-Repository ObjectOS Community — das Image ghcr.io/objectstack-ai/objectstack, os start und die Console, kostenlos und selbst gehostet — während ObjectOS Cloud die gehostete Edition ist und ObjectOS Enterprise die selbst verwaltete, lizenzierte. (Das übersetzt den Satz der README beim Tag, README.md:26-31.) ObjectOS gibt es in drei Editionen: ObjectOS Community, quelloffen und kostenlos selbst gehostet; ObjectOS Cloud, gehostet im Browser ohne Installation; und ObjectOS Enterprise, selbst verwaltet auf Ihrer eigenen Infrastruktur. Ihre Ontologie besteht aus gewöhnlichen ObjectStack-Metadaten. Der Export aus ObjectOS Cloud oder ObjectOS Enterprise zur Ausführung auf der quelloffenen ObjectStack Runtime ist geplant. Die drei Lieferungen sind Teil dieser Metadaten und gelten deshalb in jeder Edition, die sie ausführt.

Richten Sie Ihren Agent darauf

Nichts davon verlangt, die Zuordnung auf Treu und Glauben zu nehmen; die laufende App zeigt sie jedem MCP-Client.

1. Legen Sie ein Projekt mit npm create objectstack@latest my-app an. Der Scaffolder schreibt eine AGENTS.md und installiert das Skills-Bundle, sodass ein Coding-Agent mit den Regeln des Protokolls geladen startet, und how to point your agent at ObjectStack behandelt die Regeldatei und den Tool-Server.
2. Bitten Sie den Agent um die Welt: ein paar Objekte mit Feldern und einem Lookup dazwischen. Lassen Sie ihn npm run validate ausführen, und lesen Sie den Diff vor der Console.
3. Starten Sie die App mit npx os dev --ui und richten Sie einen beliebigen MCP-Client auf http://localhost:3000/api/v1/mcp. Der Agent verbindet sich als Benutzer, über den eigenen OAuth-Server des Deployments oder einen API-Schlüssel, und describe_object liefert die Welt, die Sie gerade geprüft haben.
4. Schalten Sie eine Hand scharf: Geben Sie einer Aktion ai: { exposed: true } mit einer Beschreibung, validieren Sie erneut, und sehen Sie zu, wie list_actions von leer auf eins geht.
5. Testen Sie den Zaun mit einem zweiten Benutzer, dem eine Berechtigung fehlt, die der erste hat, und lesen Sie die Ablehnung und die Audit-Zeile.

Die Seite Connect an MCP Client hat den Einzeiler jedes Clients, und die Seite Business Ontology ist die Autorität für die Definition selbst. Geben Sie beide Ihrem Agent. Welt, Hände und Zaun stehen in derselben Datei, die er gleich schreiben wird.