Products and surfaces
How a Kwern product is created from one URL, what a surface unlocks, and which documents every agent reads before it writes a word.
A product starts from one URL
You give Kwern the address of what you built. An App Store listing makes an App Store surface, a Google Play listing (play.google.com/store/apps/details?id=…) a Google Play surface, and anything else a Site surface. An Android app needs nothing more than its Google Play URL: Kwern reads its name and icon off the public listing page. That URL is kept as the product's origin and nothing more: what a product can do is decided by its surfaces, not by where it came from.
Everything in Kwern is scoped to one product. One account may have several.
Surfaces
A product has one to three surfaces, one of each kind:
- App Store — an App Store id and a storefront
- Google Play — a package name and a storefront
- Site — a URL
What the product unlocks is the union of what its surfaces allow: which agents exist, which Analytics tabs appear, which tools a run may read with. A maker with an iPhone app, an Android app and a landing page keeps one foundation doc, one growth plan and one memory across all three.
Missing surfaces are proposed from what your product already says about itself, and each is added only once you confirm it. An App Store or Google Play listing proposes the site it names for its developer. A site proposes the App Store app of its Smart App Banner, and the Google Play app it declares: its /.well-known/assetlinks.json first, then its web manifest's related_applications, then a Google Play badge link. Kwern never guesses one store's app from the other's name. Removing a surface takes its agents, their proposals, its connectors and its snapshots with it, keeps the accounts you connected, and never rewrites the foundation doc. The last surface stays.
The foundation doc
The stable description of the product: positioning, who it is for, the voice, the competitors. Every skill reads it before acting, which is what keeps a LinkedIn post and an App Store subtitle sounding like the same company.
Kwern writes the first version from the URL — the site or the listing — and you edit it directly, with version history. It can also be replaced over the MCP server.
The growth plan
The goals, bets and channels the product is currently executing, written right after the foundation doc and refreshed monthly. Every agent reads it whole alongside the foundation doc, and runs without it if it is missing. Agents never write to it.
Product memory
The dated lessons the product has learned: what to do, what to avoid, what was observed. It is what stops an agent proposing again the thing you rejected last month.
Connectors
A connector is the product's binding to one resource inside an account you connected: an app, a project, a repository, a property, a handle. The account lives in Settings; the binding lives on the product's Apps page, and one account can serve several products.
Each connector syncs once a day. The sync leaves a snapshot — the last data the service returned — and extends the connector's series, the day-by-day metrics that are never windowed: every day ever seen is kept, and a day the source restates is overwritten.
Kwern documentation
How to connect a service to Kwern, what each agent reads and proposes, and how to drive the whole workspace from an MCP client.
Image generation
How to give Kwern an image model and a key of its own, which models it offers per provider, and how the key is checked before anything is stored.