ObjectOSExtend Existing Systems
Federate a database you already run into ObjectOS as an external datasource — read-only by default, and early — and model its tables as objects, no migration.
Most teams evaluating ObjectOS already have a system of record — a CRM, an ERP, a ticketing tool, a homegrown back office sitting on a production SQL or MongoDB database. The question is rarely "should we throw it away and rebuild?" It's "can we work with the thing we already have, without a risky migration?"
One boundary first, because it decides what this page can promise. The ontology ObjectOS runs is not a semantic layer over your existing systems: it is the system — the database, API, UI and agent tools are derived from it. What it offers for a system you already run is narrower, and stated the way the ObjectStack README states it: federating an external datasource is read-only by default and early. You connect the database as a datasource, model the tables you care about as objects, and ObjectOS reads them through the same permission model as everything else. The system of record stays the system of record.
The shape of the move
You don't replace your business system. You put ObjectOS next to it and point it at the same database:
- Connect the existing database as a datasource.
Credentials come from your environment. Start read-only — a
readOnlydatasource, or a read-only database user — and enable writes deliberately. - Model the tables as objects — by hand, or by letting a coding agent scan the schema and generate source-level object files for you.
- Bind each object to the datasource (per object, or with a routing rule for a whole namespace).
- Read — the moment a table is an object, every view, dashboard, flow and agent tool can read it, routed automatically to the right database and gated by the same permissions.
Nothing about the legacy application changes. The rows stay where they are, and the legacy application keeps writing them.
Why this works without a rewrite
| Concern | How ObjectOS handles it |
|---|---|
| "We can't move the data" | The data never moves. ObjectOS connects to your database in place. |
| "We can't risk writes to production" | Start read-only — the readOnly capability, or a read-only database user — and enable writes deliberately, per object, once you trust the model. |
| "Modeling every table is weeks of work" | A coding agent scans the schema and generates one object file per table — you review and refine, you don't hand-type. |
| "AI can't be trusted with our data" | Agents run as the signed-in user and obey object-, record-, and field-level permissions. They never see more than the person behind them. |
| "Our data can't leave our network" | On ObjectOS Enterprise, ObjectOS runs in your environment: business data and prompts stay inside your perimeter. |
Generating objects with a coding agent
The fastest way to bring an existing schema in is to use a coding agent
(such as Claude Code) to scan the business tables and generate
source-level object definitions — one *.object.ts file per table.
The hotcrm reference app
shows the exact shape that output should take: each table becomes a
src/objects/<name>.object.ts using ObjectSchema.create({ … }) with
typed Field.* definitions and Field.lookup(...) for foreign keys,
assembled by defineStack. The agent introspects your connected
database, maps columns to field types, and writes objects you own and
commit. You keep what fits, drop columns you don't want exposed, and add
labels, validations, and permissions on top.
See Data Sources for the full, step-by-step authoring guide.
What you get on day one
Once the tables are modeled as objects bound to your existing database:
- Natural-language analysis. Users ask questions about the real records — "which deals slipped this quarter and who owns them?" — and the answer is computed against live data through ObjectQL.
- Governed automation. Flows and actions read the same data and — where you have enabled writes — write it, with every step audited.
- A generated API and UI. REST endpoints and admin screens come from the same metadata.
- One permission model. The boundary that applies to humans applies identically to AI traffic.
What it is not, yet
Federation is early. Expect the read path to be the mature one, and check Data Sources and the framework's own External Datasources guide for what each datasource protocol supports today. If what you need is a semantic layer that describes many systems without running any of them, that is a different kind of product.
Start here
- Data Sources — connect a database, bind objects, route queries
- AI Agents — declarative agents over your objects
- Permissions — the model AI inherits
- Quickstart — stand up the open runtime in minutes