It is assembly, not code generation
The agent does not write application code, and there is no build step where generated source becomes a running program. Nothing here is vibe-coded into existence and then hoped over.
What the agent does is compose typed artifacts from a fixed vocabulary the platform knows how to materialise: a data model, a process, a workbook, a dashboard, a page, a catalogue, an automation, a ledger asset, an agent. Bricks, in the sense that matters: each has a declared shape, the platform validates it the moment it is written, and the platform's own engines execute it, not code somebody generated.
That is what makes an AI-built application reviewable. A generated codebase can only be audited by reading it; a composition can be checked against what the pieces are allowed to be.
Extending the brick set
The vocabulary is not closed. Your own node in the automation palette, your own chart type, your own agent skill, your own catalogue entity - and behind any of them, a service you wrote yourself, in whatever you write with. Once added, it is a brick like the others: reusable across applications, versioned with them, inside the same permissions and the same audit trail. The set grows; everything in it stays typed and validated.
That is the useful place for code; the argument for it is on AIpril vs vibe coding.
What an application is made of
The artifacts cover everything an application consists of - the data model and the catalogues it uses, the processes with their roles, statuses and transition rules, the forms, the workbook columns and their formulas, the dashboards, the pages and the navigation between them, the automations and the connectors that reach outside, the agents and what they are permitted to do, and the references that bind it to other applications.
The repository holds a desired state. Installing is not a script that mutates things in order; it is handing that desired state to a reconciler which works out what the installation must look like and makes it so.
The contract: the agent is not guessing
An agent writing an application has to know what the platform can actually do - not approximately, and not from the version of the documentation it was trained on.
So the platform publishes a contract of itself. Every artifact kind, every widget, every connector capability, every chart and field type declares what it is: the properties it accepts, the shapes that are valid, what it requires and what it refuses. The agent consults that contract before it decides what to build - before it classifies a requirement, before it chooses an artifact kind, before it writes a single property.
Three things make it trustworthy:
- It is derived from the live registry, not maintained as a document. The list of connector capabilities is generated from the connectors that exist; the shapes come from the schemas the compiler actually enforces. It cannot drift from the code, because it is the code, read back.
- It states degree, not just existence. A capability says whether the platform gives you that thing, gives part of it, or does not, so nobody writes a specification against something that half exists and finds out at the prototype.
- And it is checked again on the way in. Writing an artifact validates it against the same shapes: a property that does not exist, a type that is wrong, a reference to something absent - refused at the moment it is written, with a precise reason, instead of failing later in front of a user.
That is the difference between an agent that composes and one that improvises: it works from a machine-readable description of what is possible, and everything it produces is checked against that description twice, once when it chooses and once when it writes.
Gap management
Sometimes what you describe is something the platform cannot do yet. Every product has that boundary. What differs is when you meet it and what happens next.
The usual answer is: late. The gap surfaces in the build, or in acceptance testing, or in production - and then it becomes a support ticket, a feature request, a roadmap conversation and a workaround that outlives all three.
Here it surfaces at the specification, because the same contract the agent consults states degree and not mere existence: the platform gives you that thing, gives part of it, or does not. So a requirement that needs something absent shows it while the requirement is being classified, not when an artifact fails to be written.
What follows from catching it there:
- It is named, not glossed. The specification says which part is not covered, and you approve knowing that. Nobody discovers it in month three.
- It is attached to the requirement that produced it, with the same trace as everything else - so what was wanted, for whom and why is a record, not somebody's recollection.
- It can be raised automatically to the platform administrator, and from there to us, carrying that context with it.
- And where a gap has repeatable value - where it is not one company's peculiarity but something many will need - closing it is ordinary platform work instead of a bespoke customisation built for one customer and maintained forever.
So this is one flow, not four: no letter to vendor support, no ticket disappearing into a queue, no parallel workaround built while waiting. The gap lives attached to the requirement that produced it, in the same place the rest of the application is described.
Everything is YAML, and it reads like it
The artifacts are YAML files: the data model, the process and its transitions, the workbook and its columns, the page, the agent, the solution spec with its requirements.
That choice does two jobs at once.
A person can read it. Open the file and the process is there in words - the statuses, what may follow what, the condition on the transition, who approves. No editor required to find out what the system does, and a diff between two versions is legible line by line instead of a blob that changed.
And a model can read and write it. The same text is what the agent produces, what the reviewer reads, and what the change request shows. There is no translation step between what the AI wrote and what a human approved: they are looking at the same characters.
But YAML is not what runs. Each artifact is materialised into the representation its subsystem uses: a data model becomes a model in the query engine, a process becomes statuses and transitions in the process service, a page becomes the document the page player renders, a ledger artifact becomes assets in the register. You read and review the declarative form; the platform executes its own.
That separation is what lets the readable layer stay readable. It does not have to be efficient, or support every runtime concern, or change shape when an engine changes - it only has to say what is wanted, precisely.
And a registry of requirements
An application does not only carry what was built. It carries why.
Every application holds a solution specification - a registry of its requirements - and the compiler enforces one rule: every artifact and every navigation entry must trace back to a requirement in it. An artifact nobody asked for fails the build. A requirement with nothing implementing it is visible as exactly that.
Two rules keep that registry honest:
- Requirements are derived, not invented. When a generator produces an application it declares one requirement per coherent thing it produced, with the trace it actually emitted - a trace naming an artifact that was never written is a loud failure at generation time, not a mystery at compile time later.
- A requirement's source is a real quotation. What the person said, verbatim, not a paraphrase that drifts a little further from the original with each hop.
From that registry the platform generates the application's business and technical documentation, out of the same description that runs. Nobody writes it afterwards from outside the room, and nothing drifts a week later.
This is the part that has no equivalent in ordinary configuration. When somebody asks in eighteen months why the approval works this way, the answer is not an interview: it is the requirement, its source, the artifacts that implement it, the change request that altered it and the person who accepted that.
Git, and everything that comes with it
Applications are git applications, in the ordinary sense of the word.
- A repository per application, with history, branches and diffs - not a metaphor for versioning, the real thing.
- An explorer over the artifacts, so you can open any one of them and read what it declares.
- A diff between versions that shows what changed.
- External git access, for the teams who would rather work with their own tools.
- Branch moves are compare-and-swap, so two authors advancing the same branch at once cannot silently lose one of the two.
And every step is yours to take by hand. Each artifact has an editor - the process editor, the form editor, the model editor, the dashboard builder, the canvas for pages - so you can change any part directly, in a no-code surface, without asking an agent. Or you can ask the agent. Most work is both, and the two are editing the same thing: there is no "AI mode" that produces something a human editor cannot then open.
Immutable versions
A published version does not change, not for a fix and not for a typo. A change is a new version, so the people using the application today are not standing on something that moved under them, and rolling back is installing a version that still exists instead of reconstructing a state.
Demo data, and profiles to try it on
An application can ship with more than its structure. It declares profiles: base installs the
skeleton - the tables, the processes, the pages, with nothing in them - while a demo profile
brings data with it.
That is what makes an application testable before it is trusted:
- Install the demo profile and the app arrives populated - records to click through, a process with tasks in it, a dashboard with something on it. You can judge it in ten minutes instead of spending a day entering enough data to see whether it works.
- Several profiles for several purposes - a demonstration set, a training set, a set for rehearsing an edge case somebody argued about.
- The same application, empty, for production, from the same description. The data profile is a property of the install, not a different build.
Change requests
Editing a live application goes through a change request instead of straight into the branch: somebody opens it, the agent writes into it, it is classified by what kind of change it is and what it touches, a person confirms it, and it is merged.
The classification step exists so that whoever confirms is told what they are accepting instead of being handed a diff and left to work it out. That flow is what makes an agent a safe author: it can write; it cannot merge unattended.
Publishing, portability and the marketplace
An application is self-contained, with consequences worth stating.
- It installs more than once. Another division, another legal entity, another country's operation - the same version, installed again.
- It moves between organisations. Take an application from the marketplace, install it into yours; take one of yours and publish it. Nothing about it is welded to the place it was built.
- A fork is private. Your copy is yours to change as far as you like, and none of it touches the original or anybody else's copy.
- Publishing to the shared catalogue passes moderation, and there is no flag that skips it: approval is a precondition of publication, not a policy somebody could switch off.
- Authoring is a permission. A holder authors applications their own organisation owns; there is no parameter that registers one under somebody else's ownership.
How it connects to everything else
The artifact kinds are the connection. An application does not integrate with the platform's blocks;
it is expressed in them - a process artifact is the process, a data-model
artifact is the model the engine queries, a ledger artifact declares the assets
the ledger keeps, a cms artifact is the pages people open, an
integration artifact is a connector configuration, and an
agent artifact is the AI employee that works in it.
That is why two applications from different authors share an org structure and a catalogue without anybody arranging it: they are two descriptions materialised into the same platform, not two systems that were made to talk.