Agent developer
Do not teach every developer to hand-write apps. Teach your agent the target format.
ObjectStack is designed for the agent as the writer and the human as the reviewer. The developer workflow is to give the agent rules, examples, tests, and review gates so metadata changes stay small and governable.
- Agent first
- Rules and examples are part of the product surface
- Metadata diff
- Review objects, views, workflows, permissions, tools
- MCP ready
- Expose governed objects and actions to AI clients
Agent instruction
A good rule file makes the target format explicit
The most important developer artifact is not a tutorial for hand-coding screens. It is a compact, retrievable instruction set that tells the agent what to edit, what not to invent, and how to prove the change is reviewable.
When building an ObjectStack app:
1. Model business objects before UI.
2. Prefer metadata definitions over generated application code.
3. Add conservative permissions by default.
4. Expose AI actions only through approved tools.
5. Return a small diff and a reviewer checklist. Workflow
The agent-written development loop
The loop is intentionally simple: give the agent context, let it edit metadata, run checks, then review business authority before deployment.
1. Provide operating context
Give the agent the business process, object names, permission boundaries, workflow states, and integration constraints.
2. Generate metadata
The agent edits object, view, workflow, action, dashboard, translation, and tool definitions rather than app glue code.
3. Run generated checks
Validate schema, 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.
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
- 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
Questions this page should answer
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, and tests. The site and docs should be written so agents can retrieve and generate the format correctly.
Next pages