Define an App
An App is the work you name, save and come back to: you build it, run it, schedule it, edit it and share it, and it never carries your passwords or permissions.
An App is the thing you name, save, and come back to. It is the unit of work the rest of this site talks about: you build one, you run it, you schedule it, you edit it, you hand it to someone else.
An App does not contain your data, your passwords, or your permissions. It names what it uses — a prompt, a tool, a credential — and says how you want the run to go. Everything that could actually let something happen is resolved by Kortecx, from your own permissions, at the moment you run it.
The two kinds of App
| Automation App | Web App | |
|---|---|---|
| What it holds | a workflow — the step graph agents run | a project file tree plus a framework choice |
| What it is for | work that runs on a trigger or on demand | a page the runtime serves and you open in a browser |
| Can it be a schedule target | yes | no |
Which kind an App is comes from the document itself, not from a switch you set later, so adding the web kind moved no saved App and changed no existing App's identity. Validation enforces the split rather than trusting it: an automation App must carry a workflow and no web configuration, and a web App must carry a web configuration and its project tree and no workflow.
A web App cannot be scheduled
A web App carries no runnable plan, so there is nothing for a schedule to run. The runtime refuses it when the trigger fires, and after three refused fires in a row it stops the trigger and says why, instead of collecting silent failures.
Most of this site is about the automation kind — see Scheduled apps.
What is inside an App
An App is saved as a small JSON document, called its envelope. Here is a minimal automation App, in its canonical form — sorted keys, compact, no decimals:
{"blueprint":{"steps":[]},"name":"x","schema":"kortecx.app/v1","version":"1"}Everything else is optional and is omitted when unset, which is why that document is so short. A fuller App adds four groups:
References — the by-name, by-pointer rail. Context items, tool ids, connection descriptors, dataset references, and a small artifact rail of prompts, rules, memory notes, and skills. A reference is a label plus a pointer to text you stored, or a registry id. Bodies are never inlined: the text is stored once and the App only names it.
Steering config — four axes of intent. The server re-resolves the model and tools when you run; an automation App's run is refused today if it declares context, datasets, network or filesystem scope, or secret names:
reach selector.Re-run intent — per step, whether a re-run should reuse what that step produced last time or do the step fresh.
Branch handle — the name of the App's own project file tree, when it has one.
The same App, whichever surface you used
The envelope is canonical JSON: sorted keys, compact, integers only — floats are rejected outright. An App authored in the console, from the command line, or from either SDK is the same document, so its identity does not depend on which one you used.
An App carries no authority
This is the property the whole design hangs on, so it is worth stating plainly.
There is no grant, no secret value, no password, no API key, and no run identity anywhere in an
envelope. There is nowhere to put one: a document that tried would be rejected when you saved it.
What the envelope can carry is a credential name — the string KX_SLACK_CREDENTIAL, not
the token. A run of an App that names one is refused.
Two more guards sit on the same boundary:
- A connection descriptor is rejected if it smuggles credentials into a URL.
user:pw@hostfails validation whether or not it has ascheme://in front of it. - Every declared tool id must be a well-formed id and every tool version must be a whole number, so a hand-edited envelope cannot display a capability it never legitimately requested.
The consequence for you: saving an App, importing someone else's App, or running an App can never widen what you are allowed to do. The worst a bad envelope can do is ask for something and be refused — see what you can rely on.
Wanting is not having
An App declares a request for capability. The runtime grants only the intersection with what you — the person running it — can actually do. The intersection only ever narrows. A wish never becomes authority.
Reach. The tools axis carries a reach selector. explicit is the default: the App gets
exactly the tools it enumerated, intersected with your policy. inherit_principal instead asks
for the whole set of tools you are allowed to fire — convenient for a personal App that should
adapt to whatever you have set up, and still bounded by your policy, never wider.
Model route. If an App names a model route and this instance does not serve it, the run fails closed with a clear error rather than quietly running somewhere else. The manifest flags that before you run.
Registering a tool is not the same as having a working integration.
Working with Apps
Author an App, save it to the catalog, and run it.
Open Apps and describe the work in plain language — "every Monday, read last week's support tickets and draft a summary for the team". The console comes back with a proposed App: a name, the steps it would run, the tools each step wants, and any limits it had to note. Nothing is saved until you say so.
Edit any part of that proposal — rename it, cut a step, change a tool, adjust the budgets — then save it and run it from the same screen. A saved App is listed, re-openable, and editable later.
Freeze an App
Once an App does what you want, you can stop it changing. A lock freezes both halves of it: file
edits inside the App's project tree, and structure saves from the editor. Both are refused with
the code app_locked.
A lock guards against accident, not tampering, and only you can set or lift it on your own App. If the lock cannot be read, a change is refused rather than let through. The console pre-disables the write controls on a locked App, but the runtime is the gate that counts.
One App at a time
Chaining happens inside one App: its workflow is a graph of agent steps that hand off to each other. See Workflows.