> ## Documentation Index > Fetch the complete documentation index at: https://docs.fim.ai/llms.txt > Use this file to discover all available pages before exploring further. # Orthogonalitätsstrategie > Architecture Decision Record — Klassifizierung von Funktionen nach ihrer Beziehung zum LLM-Fortschritt. > 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. | Kategorie | Strategie | Investition | Beispiele | | --------------- | -------------------------------------------------------------------------------------- | -------------------------------------- | ------------------------------------------------------------------------------ | | **Orthogonal** | Intelligentere Modelle schmälern diese nicht — reine Engineering-/Integrationsprobleme | Vollständige Investition | Konnektoren, Anmeldedaten, OAuth, Audit, RBAC, Sicherheit, Bereitstellung | | **Tailwind** | Modellverbesserungen machen diese *besser*, nicht überflüssig — symbiotische Beziehung | Investieren (Vorteile verstärken sich) | AI Connector Builder (intelligenteres Modell = höherwertige Connector-Ausgabe) | | **Eingefroren** | Bereits ausgeliefert, funktioniert gut — aber Modelle absorbieren diese Funktionen | Nur Wartung, keine neuen Funktionen | ReAct-Schleife, DAG-Planung, RAG-Pipeline, Memory, Grounded Generation | | **Überdenken** | Anbieter bauen nativ auf Plattformebene — hohes Redundanzrisiko | Auf unbestimmte Zeit aufgeschoben | Multi-Agent-Orchestrierung, semantisches Memory, Memory-Lebenszyklus | **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 Dies sind Engineering-Probleme, keine Intelligenzprobleme. Ein 10x intelligenteres Modell kann diese Dinge ohne Infrastruktur immer noch nicht tun. ### 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 | Feature | Was in der Branche passiert | | ------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | ReAct loop | Modelle haben natives Tool Calling (OpenAI, Anthropic). Die externe Reasoning Loop bietet weniger Mehrwert, da Modelle dies internalisieren. | | DAG Planning | Die Reasoning-Fähigkeiten von Modellen verbessern sich schnell. Komplexe Task-Zerlegung, die externe Planer benötigte, wird zu einer Single-Shot-Fähigkeit. | | Memory management | Context Windows wachsen schnell (Gemini 2M+, Claude 200K+). Der Bedarf für externes Window Management, Zusammenfassung und Komprimierung schrumpft. | | RAG pipeline | Anbieter bauen Retrieval in ihre Plattformen ein (OpenAI file\_search, Google NotebookLM, Gemini Search Grounding). Für öffentliches Wissen wird die traditionelle Chunk-Embed-Retrieve Pipeline ersetzt. | | Grounded Generation | Modelle werden besser darin, Quellen nativ zu zitieren. Die 3-stufige Grounding Pipeline, die wir gebaut haben, bietet abnehmenden Mehrwert. | **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 Der Aufbau einer konkurrierenden Orchestrierungsschicht würde bedeuten, gegen First-Party-Implementierungen mit tieferer Modellintegration anzutreten. Dies ist kein nachhaltiger Differenziator. ### 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+) | Feature | Version | Why orthogonal | | ------------------------------------------- | ------- | --------------------------------------------- | | Connector-Entität + CRUD | v0.6.1 | Enterprise-Integration, reine Technik | | Benutzer-spezifische Anmeldedaten (AES-GCM) | v0.6.2 | Sicherheitsinfrastruktur | | Confirmation Gate | v0.6.2 | Sicherheitsmechanismus für Schreibvorgänge | | Connector Export/Import/Fork | v0.7 | Verteilungsmechanismus | | OAuth 2.0 | v0.7 | Protokollimplementierung | | MCP Server Export | v0.7 | Interoperabilität (abhängig von MCP-Adoption) | | Datenbank-Connector | v0.8 | Direkter DB-Zugriff, Connection Pools | | Message Push | v0.8 | Benachrichtigungskanäle | | RBAC | v0.8 | Zugriffskontrolle, Governance | | Operation Audit Log | v0.8 | Compliance | | Sandbox Hardening | v0.9 | Sicherheitsisolation | | Observability (OTel, Circuit Breaker) | v0.9 | Produktionsbetrieb | | Connector Analytics | v0.9 | Nutzungsverfolgung | | Docker Compose | v0.9 | Bereitstellung | | Admin Dashboard | v1.0 | Management-UI | | Scheduled Jobs / Webhooks | v1.0 | Automatisierungs-Trigger | | Batch Execution | v1.0 | Enterprise-Scale-Verarbeitung | | Embeddable Widget / iframe | v1.0 | Liefermodus | | Enterprise Security | v1.0 | Compliance (Verschlüsselung, IP-Whitelisting) | ### Tailwind | Feature | Version | Relationship | | --------------------------------- | ------- | ----------------------------------------------------------------------------------------- | | AI Connector Builder | v0.6.3 | Intelligentere Modelle → bessere Builder-Ausgabe | | AI Connector Generation (OpenAPI) | v1.0 | Gleich — Modelle verstehen API-Spezifikationen besser → genauere automatische Generierung | ### Frozen (shipped, maintain only) | Feature | Version | Status | | ------------------------------------------------------------------ | ---------- | ---------------- | | ReAct Agent | v0.1 | Shipped, working | | DAG Planning / Re-Planning | v0.1, v0.5 | Shipped, working | | Memory (Window, Summary, Compact) | v0.2, v0.5 | Shipped, working | | RAG pipeline (embedding, vector store, chunking, hybrid retrieval) | v0.5 | Shipped, working | | Grounded Generation | v0.5 | Shipped, working | | ContextGuard / Pinned Messages | v0.5 | Shipped, working | ### Überlegung (auf unbestimmte Zeit aufgeschoben) | Funktion | Ursprüngliche Version | Grund für Aufschub | | -------------------------- | --------------------- | ------------------------------------------------------------- | | Multi-Agent-Orchestrierung | v1.0 | Anbieter bauen nativ | | Semantischer Speicher | Backlog | Kontextfenster wachsen; Anbieter fügen nativen Speicher hinzu | | Speicher-Lebenszyklus | Backlog | Wie oben | ## Auswirkungen 1. **Nicht zu v0.5-Funktionen zurückkehren.** Fehlerbehebungen ja, neue Funktionen nein. 2. **Connector-Plattform ist die Kernanlage.** v0.6–v0.8 sollten die Mehrheit der Entwicklungszeit erhalten. 3. **Enterprise-Engineering (RBAC, Audit, Sicherheit, Bereitstellung) ist der Wettbewerbsvorteil.** Diese sind langweilig, aber verteidigbar. 4. **Jährlich neu bewerten.** Wenn der Modellfortschritt stagniert oder eine „eingefrorene" Funktion sich als noch mit erheblichen Lücken herausstellt, überdenken Sie dies.