Da sich die LLM-Fähigkeiten schnell weiterentwickeln, benötigen wir ein Framework, um zu entscheiden, wo wir Engineeringaufwand investieren und wo wir stillhalten sollten.
Entscheidung
Wir klassifizieren jede Funktion nach ihrer Beziehung zum LLM-Fortschritt und ordnen die Ressourcen entsprechend zu.
Faustregel: Wenn eine Funktion das Problem „wie man das Modell intelligenter macht” löst, wird sie absorbiert. Wenn sie das Problem „wie man das Modell sicher mit der realen Welt verbindet” löst, ist sie orthogonal.
Analyse
Warum die Connector-Plattform vollständig orthogonal ist
Modelle werden niemals nativ:- API-Anmeldedaten speichern und verschlüsseln (AES-GCM)
- OAuth-Flows verwalten (Autorisierungsseite → Callback → Refresh-Token)
- Sich mit einer Kingdee/金蝶 ERP-Datenbank eines Kunden verbinden
- Benachrichtigungen an Lark/飞书 oder WeCom/企微 senden
- RBAC für die Kontrolle durchsetzen, wer welchen Connector nutzen kann
- Jeden Tool-Aufruf für Compliance-Audits protokollieren
Warum AI Connector Builder “tailwind” ist und nicht “absorbiert” wird
Der Builder-Agent nutzt Modellintelligenz, um verwaltete, persistente Connector-Entitäten zu erstellen — gespeichert in der DB, wiederverwendbar über Agenten hinweg, mit Credential-Management und Audit-Trails. Das verbesserte API-Verständnis des Modells führt dazu, dass der Builder bessere Connectoren produziert, nicht dass der Builder überflüssig wird. Analogie: Cursor nutzt Claude zum Schreiben von Code. Wenn Claude intelligenter wird, wird Cursor besser, nicht redundant, weil Cursor Engineering-Wert bietet (Projektmanagement, Dateiorganisation, Versionskontrolle), den das Modell nicht ersetzt.Warum v0.1–v0.5 Features „eingefroren” sind
Diese Features sind nicht schlecht — sie wurden ausgeliefert, sie funktionieren, sie machen das Produkt heute funktionsfähig. Die Entscheidung ist einfach, sie nicht weiter auszubauen und die Anstrengungen umzuleiten.
Warum Multi-Agent-Orchestrierung aufgeschoben wurde
LLM-Anbieter bauen Orchestrierung nativ auf:- OpenAI Swarm: Multi-Agent-Framework mit Handoff-Protokollen
- Anthropic Claude Code Teams: Leader/Worker-Agent-Pools mit Task-Graphen
- Google A2A (Agent-to-Agent): Inter-Agent-Kommunikationsprotokoll
Warum Semantic Memory und Memory Lifecycle aufgeschoben wurden
- Kontextfenster wachsen schnell, was die Notwendigkeit für sitzungsübergreifendes Speicherabrufen verringert
- Anbieter fügen native Speicherfunktionen hinzu (ChatGPT Memory, Claude Projects)
- Die Engineeringkosten für den Aufbau eines zuverlässigen Speichersystems (TTL, Importance Scoring, semantisches Abrufen) sind hoch im Verhältnis zur schrumpfenden Lücke, die es füllt
Klassifizierung auf Funktionsebene
Orthogonal (v0.6+)
Tailwind
Frozen (shipped, maintain only)
Überlegung (auf unbestimmte Zeit aufgeschoben)
Auswirkungen
- Nicht zu v0.5-Funktionen zurückkehren. Fehlerbehebungen ja, neue Funktionen nein.
- Connector-Plattform ist die Kernanlage. v0.6–v0.8 sollten die Mehrheit der Entwicklungszeit erhalten.
- Enterprise-Engineering (RBAC, Audit, Sicherheit, Bereitstellung) ist der Wettbewerbsvorteil. Diese sind langweilig, aber verteidigbar.
- Jährlich neu bewerten. Wenn der Modellfortschritt stagniert oder eine „eingefrorene” Funktion sich als noch mit erheblichen Lücken herausstellt, überdenken Sie dies.