Built by AI, approved by you

The whole path

Nothing is built before the specification is approved, and nothing goes live before a version is published. Those two gates are the reason this is not "the AI wrote something into our system".

Stating what you need

You do not write requirements. You describe the situation: what the request is, who raises it, who signs it off, what makes it urgent, what happens when it is refused, what the report at the end has to show.

The AI assistant asks back. This is the part that decides everything downstream, and it is where a good analyst earns their fee: what happens when the approver is away, what if the amount changes after approval, does a rejected request come back or start again, who may see the price.

What the AI assistant produces is a specification: the entities and their fields, the processes and their statuses, the roles, the screens, the reports, and the rules on all of it - written down in a form a person can read and argue with.

And you approve it. What you read is the description of what is about to be built, not a summary of what already was. Change it, cut it, add the thing you forgot; it is cheaper here than anywhere later.

It starts from what you already have

The reason those questions are good ones is that the assistant is not working from your sentence alone. Before it proposes anything it reads what already exists:

• Your catalogues, your data models, your org structure - so a field it proposes points at your real warehouses and your real positions, not at invented ones.
• Your existing processes, and the ones in your other applications - a purchase approval starts from how approvals are already built here, so a new app fits the ones beside it instead of introducing a second way of doing the same thing.
• Your knowledge base - the documents, rules and decisions your company has put there, retrieved by meaning, not by exact wording. See Knowledge.
• What the platform can do - the capabilities available to build with, so the specification describes something buildable instead of something that fails three stages later.
• And how this is usually done. It has seen a great many purchase approvals, service desks and onboarding flows, so what comes back includes the parts your description did not mention: the rejection path, the escalation, the status everybody forgets until March.

That is the difference between an assistant that transcribes what you said and one that gives you a first draft worth arguing with.

Building, through gates

Approval starts the build, and it advances through stages, not in one leap.

The prototype stage is the one that matters in practice. Reading a specification tells you whether it is right in principle; filing an actual request through it tells you whether it is right.

The canvas

The prototype opens on a canvas, and this is where most of the real design happens.

If you have used Figma, you already know the feel: the thing itself in front of you, select and drag, comments pinned where the problem is rather than described from memory. Two things differ here. This is the application itself, running on your data, and you are not the only one who can move it: you can edit by hand, or you can ask the agent.

You move it yourself. Select a block, drag it, resize it, snap it to the grid, change what it shows, undo when that turned out worse. Layout is the thing nobody can judge from a description and everybody can judge from a screen - so "the amount should be beside the status, not under it" gets fixed by the person who thinks so, in the ten seconds it takes, instead of becoming a ticket that comes back in a fortnight.

Or you ask for it. Select a block and say what should change - "put the totals on the right", "make the status a coloured chip", "this list should show the owner as well". The agent edits the same definition you would have edited by hand, and you see the result where you are looking. Point when pointing is faster; describe when describing is faster. Most sessions are both, alternating.

You discuss it on the thing itself. Pin a comment to a block and the conversation is attached to what it is about, not to a screenshot pasted into a chat where nobody can tell which version it was or whether it was ever addressed. Mention the person who needs to answer and it reaches them through their own channel; resolve the thread when it is done.

And what you moved is a change to the description. This is what separates it from every drag-and-drop builder: the canvas edits the application's own definition, so the arrangement is part of the version, ships with it, installs with it, and can be diffed against the last one. Nothing is a local tweak that somebody has to remember to redo.

So the review that usually costs two weeks of screenshots and comment threads becomes an afternoon around one screen: the people who will use the app push a request through it, say what is missing, and watch it change while they are still in the room.

The same canvas is how pages are built and changed afterwards - see Portals and pages.

Validation runs throughout, not at the end: the platform refuses an artifact that does not fit its own rules at the moment it is written, with a precise reason, instead of failing later in front of a user.

Changing an app that is already live

The second path gets used far more often, and it is deliberately more formal.

The important box is the one that says a person confirms. A change to a live application is not applied because an AI agent believed it was right; it is proposed, described, classified by what it affects, and merged by somebody who accepts it.

And because the running version is immutable, none of that disturbs the people using the app today. They keep using the version they have until the new one is installed.

What you can see at every point

• The description, in readable form - what this application is, not what it does when you poke it.
• The difference between two versions - what changed, not a changelog somebody remembered to write.
• Its documentation, generated from the description, so no document drifts out of date.
• The history: who changed what and when, on the same footing as any other record.

Who is allowed to do this

Authoring is a permission, not a role everybody gets by accident. Someone with it can author applications their own organisation owns; nobody can grant themselves an app belonging to another one. Publishing to a shared catalogue is a separate step again, and passes moderation before anyone else can install it.

What you end up owning

Two things, and they are what the whole conveyor is for.

A versioned asset, not a system somebody configured. Every version is kept. What changed between March and now is a question with an answer instead of an archaeology exercise; rolling back is installing the previous one; and the version people are working in today does not move because somebody edited something this afternoon. One department can stay where it is while another tries the next version. And because the application is a description a person can read, the knowledge of how your operation works stops living in the heads of three people and starts living in something the company owns.

And it can travel. An application is self-contained, so it installs more than once - another division, another legal entity, another country's operation - and it can be published to a catalogue. Your own, for reuse inside the group, or the shared marketplace, where somebody else can install it. Publishing there passes moderation instead of going live because its author pressed a button.

It works in the other direction too: take an application somebody else built, install it, and make it yours. Your copy is a fork - private to you, changed as far as you like, and none of it touches the original or anyone else's copy. What is already published is catalogued under Solutions.

That is what gives internal work a shelf life. The process you finally got right is a product you can hand to the next division, or to somebody else's company.

Next

Under the hood - what an application is as an object, and what makes installing and upgrading one safe. And Company knowledge base - what it means that the description is the system, and why that is the point and not a side effect.