Eine API, drei Arten von Aufrufer

Es liegt nahe, die UI für das Produkt und Automatisierung für ein Anhängsel zu halten. Scellis ist andersherum gebaut: Die API ist die eigentliche Oberfläche, und die UI ist einer ihrer Clients. Jede Fähigkeit existiert einmal, als typisierte Methode mit einem öffentlichen Verb; die Oberfläche, der Copilot und externe Agenten erreichen dieselbe Methode über dieselben Prüfungen. Diese Umkehrung macht „alles, was du klicken kannst, kannst du einen Agenten tun lassen“ zu einer strukturellen Garantie statt zu einer Feature-Warteschlange — der ganze Vertrag steht auf der API-Seite.

Ein Service, drei Arten von Aufrufer#

Die Verbfläche ist in offene Namespaces gegliedert — catalog, program, run, model, publish, pool, share und mehr — rund dreißig insgesamt. Jedes Verb ist als read, write oder destructive klassifiziert; nichts bleibt unklassifiziert. Eine Fähigkeit hinzuzufügen landet den ganzen Paritäts-Quad in einer Änderung: die typisierte Methode, ihr Verb, das UI-Control und das Copilot-Tool. Ein Verb liest sich gleich, egal welcher Aufrufer es auslöst:

// The same verb the UI button calls — dotted, lower snake_case.
run.start({ workflow: "user/my-workflow", tier: "prod" })

Abb. 1 — Drei Aufrufer, eine Tür. Wer auch fragt — du, der Copilot oder ein Agent außerhalb des Tabs —, die Anfrage läuft durch denselben Service und dieselben Prüfungen. Wer aufruft, ermittelt der Server aus dem Credential selbst; niemand kann sich für jemand anderen ausgeben.

Macht ohne Leine wäre leichtsinnig, also wird jede Anfrage an einem serverseitig erzwungenen Consent-Tier gemessen. Ein Read ist auto-erlaubt. Ein Write braucht ein explizites Consent-Token, das die konkrete vorgeschlagene Operation zeigt — den echten Diff, nie ein blankes „erlauben?“. Eine destruktive Aktion braucht Bestätigung und ein Rate-Limit. Und jede Anfrage trägt eine serverseitig abgeleitete caller_class — eine von ui, copilot, headless, api_key, login_free, mcp —, die kein Client fälschen kann, weil der Server sie daraus ableitet, wie sich die Anfrage authentifiziert hat, nicht aus dem, was der Aufrufer über sich behauptet.

json

// A WRITE needs a consent token that shows the concrete operation —
// never a bare "allow?". The caller_class is server-derived, unforgeable.
{
  "verb":         "model.set_optimizer",
  "class":        "write",              // read | write | destructive
  "caller_class": "copilot",            // ui | copilot | headless | api_key | login_free | mcp
  "diff":         { "optimizer": "training/optimizer/adamw", "lr": 3e-4 }
}

Der Copilot ist ein Client, kein Sonderfall#

Der Copilot denkt über den Katalog nach, schlägt Programm-Transformationen vor und bedient jede Oberfläche — er kann sogar seine eigenen Änderungen mit program.undo zurücknehmen. Seine Writes tragen source=copilot und sind in einer Live-Session einzeln pro Principal rückgängig zu machen, sodass dein Cmd-Z nie den Edit einer Mitarbeiterin zurücknimmt und umgekehrt. Standardmäßig läuft er auf deinem Key — providerunabhängiges BYOK im clientseitigen Credential-Vault — mit einem kostenlosen Onboarding-Kontingent, damit er in der ersten Minute funktioniert. Eine Doktrin hält ihn unter Prompt-Injection sicher: Content, der einem Agenten gezeigt wird (Beschreibungen, Notizen, Tool-Ergebnisse), ist Daten, nie Anweisungen, und nur die Absicht des authentifizierten Nutzers löst ein Tool aus. Der Copilot-Guide zeigt den Alltag, Scellis so zu steuern.

Die MCP-Projektion wird abgeleitet, nicht geschrieben#

Externe Agenten — Claude Code, Claude Desktop, jeder MCP-konforme Client — sind der dritte Konsument derselben Oberfläche, und dieser Teil wird gerade gebaut: Das Design steht, der Endpoint ist noch nicht ausgeliefert. Was ihn präzise beschreibenswert macht: Seine gesamte Tool-Liste wird aus der Live-Verb-Registry generiert, ohne handgeschriebene Tools; eine neue Fähigkeit erscheint bei der nächsten Regenerierung automatisch in der Agent-Oberfläche, nie dadurch, dass sich jemand ans Schreiben eines Wrappers erinnert. Die Ausführung teilt sich auf zwei Orte — serverbeantwortbare Reads funktionieren ohne offenen Tab, während Engine-Aufrufe, lokaler Zustand und Writes an deinen einen gepaarten Live-Tab weitergereicht werden — und Ressourcen lassen einen Agenten einen Trainingslauf beobachten, ohne zu pollen.

text

# Every tool is GENERATED from the live verb registry — none hand-written.
# Resources let an agent watch a run WITHOUT polling:
scellis://run/8f2ac1/metrics        # live loss + metric stream, read-only
scellis://catalog/search?q=optimizer
# Money verbs are absent from this surface — excluded at generation time.

Geld ist auf zwei unabhängigen Ebenen versperrt#

Die eine bewusste Asymmetrie ist kommerziell: Kein Nicht-UI-Aufrufer darf Geld bewegen. Das ist keine Policy, die ein Config-Flip lockern könnte; es wird zweimal erzwungen, unabhängig. Geldbewegende Verben werden zur Generierungszeit aus der Agent-Projektion ausgeschlossen, sodass die Tool-Liste eines externen Agenten schlicht kein Kauf-Tool zum Aufrufen hat. Und beim Dispatch verweigern sie jeden Nicht-UI-Aufrufer — Copilot, Headless, API-Key, Login-frei, externes MCP — und binden stattdessen an eine serverseitig geprägte, einmalige Human-Interaction-Nonce, die nur eine echte UI-Geste erzeugt. Die Scope-Grammatik eines Agent-Grants kann nicht einmal einen Commerce-Scope konstruieren, es gibt also nichts zu über-gewähren.

Abb. 2 — Ein Agent kann nichts kaufen — gleich doppelt. In der Tool-Liste, die er bekommt, steht überhaupt nichts, womit sich Geld ausgeben ließe — und eine trotzdem gefälschte Anfrage wird an der Tür verweigert, weil der Server weiß, wer aufruft. Nur ein echter Klick von dir kommt durch beides.

Grants, Pairing und Widerruf#

Der Rest des Externe-Agenten-Sicherheitsmodells reimt sich auf diese Vorsicht: OAuth 2.1 mit PKCE, audience-gebundene Kurz-TTL-Tokens an einem dauerhaften, widerrufbaren Agent Grant (ein Datensatz aus Nutzer × Client × Scope × Ablauf), Pairing als explizite In-Tab-Geste, ein persistenter „Agent verbunden“-Indikator mit Live-Aktivitätsfeed pro Aufruf und Ein-Klick-Widerruf und — die tragende Regel — kein Tab, nichts über Read. Grant-Freigabe ist nur per Human-UI; ein Agent kann sich nie selbst eskalieren. Dieselbe Kauf-Sperre gilt im Marketplace: Der Copilot darf stöbern und nie kaufen.

Inhaltsadressierte Receipts machen die Oberfläche prüfbar#

Weil alles über eine Verbfläche läuft, ist alles, was ein Agent tut, so inspizierbar und reproduzierbar wie das, was ein Mensch tut. Writes fließen durch die Provenienz; ein committeter Lauf oder eine Entität projiziert einen kanonischen, inhaltsadressierten Zitationsdatensatz — Autor, Version, Content-Hash, Engine-Version, Snapshot-URL —, den jeder exakt wieder auflösen kann. Und trägt ein Agent zu einer gepoolten Berechnung bei, prägt jede akzeptierte, verifizierte Arbeitseinheit ein hash-verkettetes ContributionReceipt mit planer-abgeleiteten Kosten, sodass das Ledger von wer-was-berechnet-hat eine Kette von Receipts ist statt einer Behauptung. Ein Agent ist hier ein Peer des Plattform-Teams — dieselben Verben, dieselben Prüfungen, dieselbe Audit-Spur, minus der Fähigkeit, dein Geld auszugeben — und die Vertrauensgrenze, in der er lebt, ist Thema von Sicherheit und Privatsphäre.