Für Agenten

Agenten

Ein Agent sollte jemandem eine funktionierende Datenbank geben können, ohne dass ein Mensch ein Dashboard öffnet. Hier ist alles, was wir dafür veröffentlichen.

01

Die Ausgangslage

Ein wachsender Anteil der Projekte wird von einem Agenten begonnen und nur von einem Menschen geprüft. Dieser Agent braucht drei Dinge von einem Datenbankanbieter: einen Weg herauszufinden, was das Produkt ist, einen Weg, auf dem Konto zu handeln, und einen Weg, dem Menschen am Ende etwas Funktionierendes zurückzugeben.

Wir veröffentlichen alle drei. Nichts davon ist eine Demo-Oberfläche - der MCP-Server und die CLI rufen dieselbe API auf wie das Dashboard, mit denselben Berechtigungen und derselben Prüfspur.

02

Auffindbarkeit

  • -/llms.txt - das Verzeichnis, das ein Assistent zuerst liest und das auf alles Weitere verweist
  • -/agents.md - ausführbare Anleitungen, um im Auftrag einer Person eine Datenbank bereitzustellen
  • -/pricing.md, /about.md, /changelog.md - Markdown-Spiegel der Marketingseiten, erzeugt aus denselben Quellen wie das HTML
  • -/webmcp.md - die Werkzeugoberfläche im Browser, die das Dashboard veröffentlicht
  • -Die Dokumentationsseite veröffentlicht ein eigenes Verzeichnis und einen vollständigen Korpus für Retrieval
  • -Ein RSS-Feed für den Changelog, damit ein Agent, der auf Breaking Changes achtet, keine Seite abfragen muss

03

Auf einem Konto handeln

Zwei Oberflächen, dieselbe API. Der MCP-Server passt, wenn der Agent in einem Editor oder Chat-Client lebt; die CLI passt, wenn der Agent eine Shell hat.

Beide authentifizieren sich mit einem organisationsbezogenen API-Schlüssel oder über einen Geräte-Login, den der Mensch im Browser bestätigt. Ein Agent braucht nie ein Passwort und sollte auch nie eines bekommen.

# In a shell
capydb login
capydb create --name my-app
capydb env pull

# In an editor, over MCP
npx -y @capydb/mcp

04

Agenten im Browser

Das Dashboard veröffentlicht eine Werkzeugoberfläche an Browser-Agenten, die sie unterstützen, sodass ein Agent über benannte Werkzeuge handelt statt am DOM zu raten. Destruktive Werkzeuge fragen über dieselbe Oberfläche nach Bestätigung, die auch ein Mensch sähe.

Die veröffentlichte Oberfläche ist unter /webmcp.md dokumentiert und bewusst eine Teilmenge: Wiederherstellungen, die Produktionsdaten überschreiben, sind einem Agenten gar nicht zugänglich.

05

Leitplanken

  • -Destruktives SQL über den MCP-Server verlangt vorher einen Wiederherstellungspunkt
  • -Das Überschreiben der Produktion per Wiederherstellung ist in keiner Oberfläche als Agentenwerkzeug freigegeben
  • -API-Schlüssel sind auf eine Organisation begrenzt und lassen sich im Dashboard sofort widerrufen, wenn ein Lauf entgleist
  • -Preview-Datenbanken haben eine Ablaufzeit, damit ein Experiment nicht still zur Rechnung wird
  • -Jede Aktion eines Agenten erscheint im Prüfprotokoll des Workspace unter dem Schlüssel, der sie ausgeführt hat

06

Warum das hier leicht ist

Weil es keine proprietäre Daten-API zu lernen gibt. Der Agent stellt eine Zelle bereit, bekommt eine normale PostgreSQL-URL und benutzt danach den Treiber, den das Projekt ohnehin hat. Alles, was ein Agent bereits über Postgres weiß, überträgt sich unverändert - und das ist der Unterschied zwischen einer Aufgabe, die im ersten Anlauf funktioniert, und einer, die drei Runden Dokumentationssuche braucht.