What an app is
Prezzando writes quotes with an assistant. It knows how a quote is put together — items, quantities, VAT, totals — but it doesn’t know your trade: it has never priced scrap gold by fineness, and it can’t read a bill of quantities sent by a main contractor.
An app fills that gap. It is a manifest: an object that declares who it is, what it needs, and what it adds.
import { definePlugin, PLUGIN_API_VERSION } from "@prezzando/plugin-sdk";
export default definePlugin({ id: "gold-fix", apiVersion: PLUGIN_API_VERSION, version: "2.0.0", name: "Gold quote", summary: "Today's gold price, applied to what you buy over the counter.", settings: [/* what the shop configures */], tools: [/* what the assistant can call */], jobs: [/* work repeated every day */], prompt: (ctx) => "…", // what the model is told});The rule everything else follows from
Section titled “The rule everything else follows from”An app imports nothing from the host. Not the database, not the ORM, not
the AI client, not the application services. Everything it needs arrives
through the PluginContext it is handed.
That context is a boundary that will one day become a network call, the day third-party apps run somewhere else. Which is why every method on it is async and every argument is serializable, even where in-process it wouldn’t need to be. A shortcut taken today — a direct import, “it’s all one codebase anyway” — is code that has to be rewritten that day.
The same rule explains the part that surprises people most: an app has no user interface. It doesn’t ship components, markup or images. It declares its settings and the host draws them. That’s what keeps app code out of customers’ browsers, and it’s what will make opening up to third parties a review problem rather than a security one.
What an app can add
Section titled “What an app can add”| Extension point | What it does |
|---|---|
settings |
Fields the customer fills in. The host generates the panel and validates them. |
tools |
Functions the model can call mid-conversation, with their JSON Schema. |
jobs |
Work run once a day for the whole platform, not once per customer. |
prompt |
The fragment injected into the system prompt while the app is installed. |
capabilities |
Chat abilities to switch on, like reading photos or documents. |
allowedHosts, secrets |
The only network hosts and credentials reachable at run time. |
Trust levels
Section titled “Trust levels”The manifest declares which one it targets, and the host decides where the app runs accordingly.
- core — written by us, runs in-process, full context.
- verified — third party, reviewed, in-process with a restricted context.
- external — third party, runs elsewhere, reached over signed HTTP.
Today only core exists. All three are in the contract from the start so the
manifest doesn’t have to change shape when the others arrive.