Funktionen
Die Runtime ist der Teil,
den du nicht zweimal bauen willst.
Drei Säulen. Jede ist etwas, das Demos schaffen und Production nicht. Wir haben die Production-Hälfte gebaut, damit dein Team das agentische Erlebnis shippen kann.
Erreicht deine Daten
Antwortet aus öffentlichen Docs.
Liest durch dein Backend — PocketBase, Supabase, dein eigenes Go. MindVM besitzt keine Kopie deiner Daten; der Agent ruft deine APIs per MCP auf, gescoped auf dein Project.
Ein Project ist die Isolationseinheit. Memory, Secrets und Audit sind automatisch darauf gescoped; du gibst keinen Customer-Ref bei jedem Call mit.
Exponier dein Backend als MCP-Server; der Agent greift über die Tools, die du veröffentlichst, auf deine Daten zu — gegated durch deine Auth. Referenz-Adapter für PocketBase und Supabase liefert MindVM.
Pro-Project-Vaults mit Envelope-Encryption. Der Agent liest Provider-Keys / Webhook-Secrets / SaaS-Tokens via secret(name) in der Sandbox. Die Plattform gibt nie Klartext über die Wire zurück.
Jedes Project bekommt einen isolierten Memory-Store, den der Agent mit remember() / recall() liest und schreibt. Überlebt das Session-Ende; isoliert von anderen Projects.
Handelt in deiner Project
Gibt einen String zurück.
Erstattet Beträge, aktualisiert Datensätze, öffnet Tickets — über deine APIs, mit Approval-Flows für brisante Aktionen.
Der Agent will $847 an customer_4f2a erstatten.
Grund: Bestellung #38291 nie versendet Policy: §4.2 (über $500 → Human Review) Project: acme · Auslöser: agent.refund-flow
Deklariere deine APIs als Tools. MindVM übernimmt Calling-Loop, Retries und Strukturparsing.
Jedes Tool kann ab einem Schwellwert menschliche Freigabe verlangen. Agent pausiert; Operator bestätigt; Run läuft weiter.
Jeder Tool-Call trägt einen Key. Retries laden nicht doppelt ab, erstatten nicht doppelt, legen nicht doppelt an.
Wenn das Modell JavaScript schreibt statt Tools aufzurufen, läuft es in einer gehärteten JS-Sandbox — kein Netzwerk, Memory-Cap.
Beurteilbar, nicht Bauchgefühl
Sieht richtig aus.
Zeigt den JS-Code, den der Agent ausgeführt hat, die aufgerufenen Tools, die berührten Daten. Replay für jeden Turn. Eval-geprüft vor dem Deploy.
Klick einen Production-Turn; sieh exakten Plan, Tool-Calls, Modell-Outputs und Daten, die der Agent gesehen hat. Step-by-Step durchgehen.
Definiere Eval-Fälle als evals/*.json-Dateien in deinem mindvm/-Ordner. Lass sie in CI laufen. Verfolge Regression-Scores pro Deploy.
Sample Production-Traffic, fahr ihn durch deine Evals, alert, wenn die Live-Verteilung vom Eval-Set abweicht.
Jeder Plan, Tool-Call und Datenzugriff wird pro Project geloggt. Suchbar. Exportierbar. SOC-2-ready.
Auch dabei
Alles andere, was du
vor dem Launch gebaut hättest.
Die langweilige Infrastruktur darunter. Nichts davon ist für sich genommen spannend. Alles ist nötig, um einen Agent vor Kunden zu bringen.
OpenAI-kompatibles /chat/completions auf derselben Provider-Registry, die die Agenten nutzen. Eine MindVM-Rechnung über Agent- und Non-Agent-LLM-Calls. Provider-Abstraktion, Audit, Policy-Gating.
Token-by-Token-Streaming mit sauberer Cancellation. Stopp einen 30-Sekunden-Run mitten im Flug, ohne Tool-Calls zu leaken.
Schnelle Pfade auf kleine Modelle, harte Fälle auf große. Pro-Project Provider-Auswahl über agent_versions.provider.
Schema-validierte JSON-Antworten mit Retries bei Parse-Failures. Das Modell bekommt den Diff und probiert erneut.
sendEmail() in der Agent-Runtime — MindVM-gemessen oder BYOK gegen deinen Resend- / Postmark- / SES-Key im Secret-Vault.
First-Class-Clients für beide. Gleiche Oberfläche, gleiche Primitive, gleiche Docs.
MindVM in unserer Cloud oder deiner. Gleiche Binary. Gleiche App. Bring-Your-Own-VPC verfügbar.
Jeder Plan, Tool-Call und Modell-Aufruf emittiert OTel-Spans. Direkt in deinen bestehenden Observability-Stack.
Agenten als Code definieren. Versionieren. Diffen. Rollback. So, wie du den Rest deiner Infra ausrollst.
Lies die Docs — oder installier einfach die CLI.
Drei Befehle — mindvm init, mindvm dev, mindvm deploy — und dein erster Agent läuft.