Agent developer
Do not teach every developer to hand-write apps. Teach your agent to write the ontology.
One executable business ontology. AI writes it, the runtime runs it, agents operate it, you own it. The ontology is what the agent writes — AI-writable, in the README’s four promises — and you are the reviewer: the scaffolder writes an AGENTS.md so the agent starts with the protocol’s rules loaded, Strict TypeScript, Zod schemas, and os validate reject invalid output before it reaches the runtime, and the whole app stays small enough for AI to hold whole.
- AGENTS.md
- Written by the scaffolder, so the agent starts with the protocol’s rules loaded
- 4 gates
- Typed, validated, reviewed, governed — between the agent and your users
- Held whole
- Apps small enough for AI to hold whole — the bundled CRM loads end-to-end
The README path
Three commands, and your agent has the rules
The scaffolder installs the AI skills bundle and writes an AGENTS.md, so the agent starts with the protocol’s rules already loaded — not with generic “write me some TypeScript” priors. Describe the requirement in Claude Code, Cursor, or Copilot; the agent writes typed metadata, not a codebase, and the gate rejects what would fail silently at runtime. Then preview the real app in the browser and ask for the next change on a diff you can read.
# 1 · Create a project: installs the AI skills bundle, writes AGENTS.md
npm create objectstack@latest my-app && cd my-app
# 2 · Open it in Claude Code (or Cursor, Copilot, ...) and describe the need:
# "Build a support desk. Add a ticket object with subject, description,
# a priority select and a status select. Add a Resolve action that only
# shows on tickets that aren't already resolved. Add an Open tickets
# list view and a Support nav group. Run npm run validate when done."
# 3 · Preview in the browser
npx os dev --ui # -> http://localhost:3000/_console/Workflow
The agent-written development loop
The loop is intentionally simple: give the agent the complete current definition and operating context, let it edit typed metadata, run the validation gate, then review business authority before deployment.
1. Provide operating context
Give the agent the business process, object names, permission boundaries, workflow states, integration constraints, and the complete current definition. The app stays small enough for AI to hold whole — the README’s bundled CRM loads end-to-end — so it can be inspected as a whole instead of reconstructed from fragments.
2. Write the ontology
The agent edits the ontology — objects and fields, relations, actions, permissions, flows, and tool definitions — and its projections — views, dashboards, translations — as Strict TypeScript rather than generating app glue code.
3. Pass the validation gate
Compile in Strict TypeScript mode, validate every definition against its Zod schema, then check permissions, required labels, sample data, object queries, and workflow transitions.
4. Review authority
Humans review what authority changed: data access, write power, approval bypasses, exports, and AI tool exposure.
Patterns
What the agent should generate
The best generated change names business concepts clearly and keeps runtime power explicit.
Objects and fields
Use business names, relationships, validations, indexes, and lifecycle rules that map to real operations and conform to the published Zod schemas.
Views and actions
Generate list, form, kanban, dashboard, and action metadata from the object model, not one-off screens.
Workflows and approvals
Define transitions and approval gates explicitly so the runtime can enforce them for people and agents.
Agent tools
Expose only bounded object queries and actions through MCP, with policy checks and audit-friendly names.
Decision surface
What changes, who reviews it, what runs
| Old developer surface | Agent-written ObjectStack surface | Reviewer question |
|---|---|---|
| Controller code | Object action metadata | Who can invoke this action? |
| Custom auth checks | Object, row, and field permissions | What data authority changed? |
| Hand-built screens | View and form metadata | Which workflow does this screen support? |
| Ad hoc AI prompt | Policy-aware tool contract | What can the model read or mutate? |
Review checklist
Diff review checklist for agent-written ObjectStack
- Did the agent inspect the whole current application instead of inferring missing state from fragments?
- Does the change pass Strict TypeScript compilation, Zod schema validation, and the validation gate?
- Does the diff change business authority or only presentation?
- Are object and field names stable and domain-specific?
- Are defaults conservative for reads, writes, exports, and tools?
- Are approval gates explicit for sensitive actions?
- Can tests or sample data demonstrate the workflow?
- Can a future agent retrieve and reuse the same pattern?
FAQ
Frequently asked questions
Should developers still understand ObjectStack?
Yes, but the primary developer task changes. Humans design boundaries, review diffs, write tests, and curate examples; agents do more of the repetitive metadata authoring.
Can any coding agent write ObjectStack?
Any strong coding agent can work with the format if it has clear docs, examples, rules, tests, and access to the whole current definition. Strict TypeScript, Zod schemas, and the validation gate provide deterministic feedback before the same validated app is either self-hosted on ObjectStack or operated through ObjectOS, which runs the same open runtime.
Next pages