AssistantAppsUse CasesPlattformPricingImplementationLog inWaitlist

Open App Platform · Phase 2 alpha

Bau die App, die deine Branche braucht.

Schreib Code in Python oder TypeScript, wir hosten ihn pro Tenant, isoliert, mit Audit-Log und Kosten-Attribution. Der Rest des Linkworld-Stacks — Mail, Kalender, ERP, Reports — steht dir als ctx.tools.call(...) zur Verfügung.

5 Minuten von Null bis Deploy

01

CLI installieren

pip install linkworld
02

App scaffolden

linkworld init my-app --lang typescript --github-owner you

Liefert dir Manifest, Handler-Skelett, Dockerfile und GitHub-Actions-CI.

03

Lokal entwickeln

cd my-app
npm install
npm run dev

Mock-Backends für ctx.tools und ctx.secrets kommen direkt mit. Kein Cloud-Account beim Coden nötig.

04

Mit GitHub einloggen

linkworld login
05

Deployen

git tag v0.1.0 && git push --tags

CI baut das Image, pusht zu GHCR, registriert die Version. Sofort in der Dev-Console sichtbar.

Was du bekommst

Per-Tenant-Container

Jeder Tenant kriegt einen eigenen Container deiner App-Version. Cross-Tenant-Lecks sind im DB-Layer ausgeschlossen. Sleep-on-idle nach 15min.

Verschlüsselte Secrets

Zwei Tiers: Dev-Default (du seedst es einmal) und Tenant-Override (Tenant überschreibt). AES-256-GCM at rest, fail-closed bei Netzfehlern. Keine Anzeige nach Erstellung.

Audit + Cost-Attribution

Jeder Tool-Call landet im Audit-Log. LLM-Tokens und Compute-Sekunden werden pro App pro Tenant in Grafana attribuiert. Bezahl nicht für Code, den du nicht geschrieben hast.

Lifecycle-Hooks

on_install, on_inbound (opt-in fan-out), on_schedule (cron-precision), on_user_added. Handler bleiben async und idempotent — der Rest ist Plattform-Job.

Scope-Modell

Manifest deklariert required_scopes (mail.send, files.read, ...). Tenant grantet beim Install. ToolCallError(scope_denied) ist die einzige Failure-Mode, die du selbst behandelst.

Dev-Console

Versions, Logs, Errors, Usage-Charts (per App), Secrets-CRUD — alles unter /dev/* in Linkworld. GitHub-OAuth-Login, Token-Paste als Fallback für CI.

Zwei SDKs, ein Vertrag

Python

from linkworld_sdk import App

app = App.from_manifest("linkworld.app.yaml")

@app.on_inbound
async def on_inbound(ctx, env):
    await ctx.tools.call(
        "email_send",
        to=env.from_,
        body="Got it.",
    )
Python-Reference →

TypeScript

import { App } from '@linkworld/sdk'

const app = App.fromManifest('linkworld.app.yaml')

app.onInbound(async (ctx, env) => {
  await ctx.tools.call('email_send', {
    to: env.from,
    body: 'Got it.',
  })
})

await app.run()
TypeScript-Reference →

Beide SDKs teilen sich Manifest-Schema und Handler-Vertrag. CI-Tests stellen sicher, dass kein Drift entsteht — was die eine SDK akzeptiert, akzeptiert die andere auch.

Beispiel-Apps

Anatomie einer Linkworld App

Vier Schichten. Ein Geschäftsprozess.

Eine App ist kein Chatbot. Sie ist eine Stack aus deklarativem Manifest, Signature-Workflows, skill-gegateten Tools und einer Channel-/ERP-Abstraktion — der Agent darüber führt aus.

01Manifestdeklarativ02Workflowsprompt-driven03Toolsskill-gated04Channel · ERPtransparent
01

Manifest

deklarativ

Deklaration in einer Datei: was die App ist, welche Triggers/Intents sie kennt, welche Skills sie braucht. Daten, kein Code.

02

Workflows

prompt-driven

Signature-Flows als Daten — Tool-Sequenzen mit harten Regeln (z. B. „NIE Preis halluzinieren, IMMER zuerst lookup“). In den System-Prompt injiziert.

03

Tools

skill-gated

Intent-level Tools wie create_document, render_pdf, deliver_file. Skill-gegated — der Agent sieht nur Tools, für die der Tenant Credentials hat.

04

Channel · ERP

transparent

Abstrahiert WhatsApp/Web/Voice und internal/Odoo/Business Central/lexoffice. Workflows haben kein channel- oder ERP-spezifisches Verhalten.

Prompt-driven Tool-Choreographie. Kein BPMN-Engine.

Status-Übergänge (Draft → sent) sind explizite Tool-Calls, keine zentrale State-Machine. Der Orchestrator routet per Intent zum Specialist; der Specialist führt den Flow aus. Harte Regeln stehen im specifics-Feld jedes Workflows.

Beispiel

Office Assistant — fünf Workflows.

Ein konkretes Manifest aus der Plattform. Fünf Geschäftsprozesse, deklarativ. Keine Halluzination, kein Engine-Code — Tool-Choreographie mit klaren Regeln.

custom_quote_from_positions

User diktiert Positionen → Angebot

business_lookup_pricecreate_documentrender_pdfdeliver_filetransition('sent')
photo_or_sketch_to_quote

Foto/Skizze → Schadens-Erkennung → Angebot

damage_analyze_photoslookup_pricecreate_documentrender_pdfdeliver_file
letter_or_protocol

Briefe/Protokolle, rein Template-basiert

create_documentrender_pdfdeliver_file
show_existing_document

Bestehendes Dokument im aktuellen Channel zeigen

list_documentsget_documentrender_pdfdeliver_file
send_document_via_email

Dokument an Email schicken — mit Approval-Gate

get_documentrender_pdfsend_message_to (Approval)

Bereit zu bauen?

Phase-2-Alpha. Wir werfen 0.x-API-Anpassungen ein, bevor der erste externe Partner in Production geht — danach ist es stabil.