Diese Seite erklaert, warum nemoclaw-deployment.com als Control Plane fuer NemoClaw-basierte Agentensysteme gedacht ist: Peddabot bleibt Produktmarke, waehrend Baukasten, Provider-Keys, Infrastruktur, Runtime, Governance und Subscription hier zusammenlaufen.
nemoclaw-deployment.com ist nicht die Markenflaeche von Peddabot. Es ist die Seite, auf der der operative Unterbau erklaert wird: tenant-aware Provisioning, Infrastructure Targets, Provider-Vault, Runtime-Auswahl, Limits, Connectoren und Betriebslogik.
Jede Instanz bekommt einen klaren Lebenszyklus aus Planwahl, Tenant-Anlage, Blueprint-Auswahl, Workspace-Provisioning und Runtime-Zuordnung.
Die Plattform kennt Produktgrenzen und kann Chat-Sessions, Dokumentenpipelines, Arena-Debatten, Heavy Jobs und Upgrade-Pfade konsistent abbilden.
Nicht jeder Kunde bekommt denselben Stack. Provider-API-Keys, Persona-Sets, Skill Packs, Connectoren und Richtlinien bleiben tenant-aware und kontrollierbar.
Betrieb wird als Produktfunktion mitgedacht: Operational Logs, Statussignale, Hintergrundjobs und Update-Prozesse gehoeren in denselben Systemrahmen.
Die Trennung ist entscheidend fuer Produktisierung: Marken, Builder-Flows und Use Cases koennen wachsen, ohne die Plattformlogik jedes Mal neu zu bauen.
Die Plattformseite macht sichtbar, welche Teile bewusst kundennah sind und welche als kontrollierte Betriebslogik fuer Dokumente, Personas, Provider und Jobs im Hintergrund bleiben.
Workspaces, Dokumenten-Vaults, aktivierte Persona-Raeume, sichtbare Connectoren, Status, Usage-Auszuge und planbezogene Controls gehoeren in die Kundensicht.
Workspace UI, Persona Arena, Self-Service-Optionen, Billing-Hinweise, Status und Logs nach Rolle.
Die Plattform entscheidet, welche Teile freigegeben, verborgen oder eskaliert werden.
Provisioning, Rollouts, Runtime-Scheduling, Secret Injection und tiefergehende Audit-Telemetrie bleiben auf Plattformseite.
Nur das Ergebnis oder ein abstrahierter Status wird sichtbar.
Ops, Support und spaeter automatisierte Policies arbeiten auf dieser Ebene.
Jeder Tenant kann eigene Policies, Limits, Provider-Keys, Connector-Sets, Skill Packs, Persona-Sets und Runtime-Praeferenzen tragen, ohne dass die gesamte Plattform dupliziert wird.
Ausgewaehlte Konfiguration und Rollenrechte.
Die eigentliche Isolation, Freigabe und Durchsetzung der Grenzen.
Die Website selbst ist schon so angelegt, dass sie spaeter in eine echte SaaS-Oberflaeche mit Builder, Provider-Vault und Infrastrukturabstraktion uebergehen kann. Marketing und App bleiben getrennt, Inhalte sind datengetrieben strukturiert.
Die Codebasis trennt Praesentationsrouten und spaetere App-Shells, damit Produktseiten nicht mit kuenftigen Auth- und Dashboard-Pfaden verschmelzen.
Copy, Navigation und strukturierte Plattformdaten liegen zentral, damit Pricing, FAQs oder Runtime-Beschreibungen spaeter ohne Komponentenumbau wachsen koennen.
Die Seitenlogik baut bereits auf konzeptionellen Entitaeten wie Tenant, Plan, Usage, Runtime und Workspace auf. Genau diese Entitaeten sind spaeter an Auth, Metering und Billing anschlussfaehig.
Wenn Builder, Provisioning, Runtime, Provider-Keys und Governance sauber formuliert sind, wird aus einer Agent-Idee ein verstaendliches Produktmodell.