Das Problem war nie das Modell
Erstens: die Breite. Es gibt nicht das Modell, sondern ein Dutzend ernstzunehmende, und sie sind unterschiedlich gut in unterschiedlichen Dingen. Eines schreibt besseren Code, eines liest längere Dokumente, eines erzeugt brauchbarere Bilder, eines ist schlicht zehnmal günstiger für simple Abfragen. Alle im Abo zu haben, ist absurd — man zahlt siebenmal für Kapazität, die man einmal braucht. Auf eines zu setzen, ist riskant.
Und zwar konkret riskant. Als einer der Anbieter sein Standardmodell wechselte, stieg der Token-Preis für dieselbe Arbeit von 3 auf 5 Dollar pro Million Input-Tokens — bei den Ausgaben von 15 auf 25. Über Nacht, per Produktankündigung. Wer seine Arbeitsweise auf ein Chatfenster eines einzelnen Anbieters aufbaut, macht sein Betriebsmodell von dessen Preisliste abhängig. Und Preislisten sind das Einzige an dieser Technologie, das sich noch schneller ändert als die Modelle selbst.
Daraus wurde eine Anforderung an die Gridonic AI Plattform: wir bauen LLM-agnostisch. Ein System, in dem das Modell eine Konfiguration ist und keine Grundsatzentscheidung. Wo man für die Datenabfrage ein günstiges Modell einsetzt und für das Urteil ein teures. Wo ein Preissprung eine kleine Umstellung bedeutet und keine zeitaufwändige Migration.
Zweitens: die Zersplitterung. Am Team-Day hatten zehn Leute zehn Arbeitsweisen gezeigt. Als Lernstand war das grossartig; als Betriebszustand ist das ineffizient und letzlich teuer.
Denn Einzelproduktivität summiert sich nicht automatisch zu Teamproduktivität. Wenn jede Person mit ihrem eigenen Modell, ihren eigenen Prompts und ihrem eigenen Vorgehen arbeitet, entstehen Ergebnisse, die einzeln gut und gemeinsam unbrauchbar sind. Ein Audit ist nicht mit dem des Vormonats vergleichbar, weil das Vorgehen ein anderes war. Zwei Personen bauen dieselbe Vorarbeit doppelt, weil keine von der anderen weiss. Wissen aus einem Projekt bleibt im Chatverlauf dieses Projekts liegen und stirbt mit dem Projektabschluss.
Der Nachbearbeitungsaufwand frisst den Zeitgewinn. Ab einem gewissen Punkt ist unkoordinierte AI-Nutzung aufwendiger als gar keine — man hat dann nämlich beides: die Kosten der Werkzeuge und die Kosten der Abstimmung.
Drittens: der Kontext. Beides zusammen wurzelt im selben Defizit. Jede Konversation begann bei null. Wer eine Offerte schreiben wollte, musste dem Modell erst erklären, wer der Kunde ist, was wir für ihn gemacht haben, wie unsere Positionierung klingt. Wer einen Audit brauchte, kopierte Zugangsdaten und Projektnotizen ins Chatfenster. Das Wissen der Agentur lag in Köpfen, in Asana, in Drive, in DatoCMS — und musste für jeden AI-Einsatz von Hand neu zusammengetragen werden. Genau dieses Zusammentragen war der Teil, den jede Person anders machte.
Mehr Integrationen halfen übrigens nicht. Unser erster Reflex war, alle verfügbaren MCP-Server gleichzeitig zu aktivieren. Das ging schief: Jeder aktive MCP schickt seine kompletten Endpoint-Definitionen mit — bei einem halben Dutzend Integrationen frisst allein die Toolbeschreibung einen erheblichen Teil des Kontextfensters, bevor überhaupt eine Frage gestellt wurde.
Damit war das Ziel definiert, und es hiess nicht "bessere Modelle" oder mehr CPU. Es hiess Orchestrierung : eine Schicht, die weiss, welches Wissen zu welcher Aufgabe gehört, welches Modell sie ausführt und in welchem Ablauf — damit nicht mehr jede Person diese drei Entscheidungen jedes Mal neu und anders trifft.
Was heisst das für uns als Digitalagentur
Im Mai 2026 stand auf der Agenda unseres monatlichen "Gridonic Engine"-Meetings ein Punkt, der ein Jahr zuvor noch nach Science-Fiction geklungen hätte: generative Bildgenerierung in Design-Qualität, daneben Prozessautomatisierung und Caching-Strategien, weil wir gegen API-Limits liefen.
Das war der Moment, in dem klar wurde, wie weit die Modelle gekommen waren. Sie schrieben produktionsreifen Code statt Snippets. Sie lasen ganze Codebasen, statt einzelne Funktionen zu kommentieren. Sie erzeugten Bilder, die es durch eine Designkritik schafften. Und sie fingen an, Werkzeuge selbst zu bedienen, statt nur Text auszugeben. Die Sprünge kamen nicht mehr jährlich, sondern quartalsweise – heute gar monatlich.
Für eine Digitalagentur ist das keine Toolfrage. Es ist eine Existenzfrage.
Projektmanagement, Konzeption, Workshopvorbereitungen, Frontend-Arbeit läuft bei uns inzwischen stark AI-gestützt mit Agents und Skills. Uns wurde klar: Es reicht nicht, diese Systeme zu benutzen. Wer sie einem Kunden gegenüber verantworten will, muss verstehen, wie sie funktionieren — und dafür muss man sie selbst betreiben. Der Unterschied zwischen "wir arbeiten mit AI" und "wir wissen, warum dieser Output so aussieht" entscheidet über Kompetenz. Man lernt nicht, wo ein Modell halluziniert, indem man ein Abo kauft. Man lernt es, indem man den Kontext selbst zusammenstellt, die Kosten selbst trägt und die Fehler selbst aufräumt.
Also haben wir uns reingehängt. Am Team-Day im Juli 2026 zeigte jede Person in fünf Minuten ihr eigenes Setup — zehn Leute, zehn Arbeitsweisen, ein gemeinsamer Lernstand. Wir haben eine eigene Plattform aufgebaut, einen eigenen Wissens-Server betrieben, Agenten-Architekturen durchprobiert und verworfen. Aus Anwendern sind Betreiber geworden. Und aus Betreibern Spezialisten — nicht, weil wir es uns vorgenommen hatten, sondern weil man's nur lernt wenn man es wirklich macht.
Die AI Plattform bei uns
Als neues Agenturmodell basieren wir alles auf unserer AI Plattform "Vela". Vela bietet ein Set Agenten und Skills, damit unsere Kunden in ihren Projekt schneller vorwärts kommen, mehr Wissen zur Verfügung haben und viel selbständiger arbeiten können.
Gebaut haben wir "Mira" in vier Schichten — je eine pro Problem.
1. Vela – die Plattform
Die vielen internen Tool haben wir erst einzeln angebunden (zB Asana, Harvest, Confluence). Von den meisten Tools haben wir uns aber verabschiedet und diese selbst neu gebaut. Seit Ende Juli 2026 heisst sie Vela . Es ist die zentrale Applikation mit gemeinsamem Datentopf. LibreChat bleibt daneben als Chat-Oberfläche für schnelles Experimentieren.
Vela ist an keinen LLM Provider gebunden. Die Entscheidung für LibreChat statt direktem Anbieter-Zugang fiel im Juni 2026 aus drei Gründen — Sicherheit, geteilte Workspaces und zentrale Steuerung der API-Kosten. Welches Modell eine Aufgabe ausführt, ist damit Konfiguration und nicht Architektur. Steigt ein Token-Preis, wird umgestellt, nicht migriert.
Das war Problem eins.
2. Gridonic Knowledge – eine zentrales Warehouse
Seit Juni 2026 läuft unser Knowledge MCP Server . MCP steht für Model Context Protocol — ein offener Standard, über den AI-Systeme auf externe Datenquellen zugreifen. Statt Fakten in Prompts zu kopieren, holen sich die Agenten den Kontext dort ab, wo er kanonisch gepflegt wird.
Die Struktur ist bewusst simpel:
-
Global — Positionierung, Services, Tool-Landschaft, Team
-
Clients — Zielgruppen, Angebot, Proof Points
-
Projects — Kontext, Ziele, Constraints, ope
-
Collections — geordnete Dokumentserien im Projekt
Redaktionell läuft das Git-backed über das Repository gridonic/knowledge . Jeder Schreibvorgang hat eine Dry-Run-Vorschau und braucht eine explizite Freigabe. Das ist unbequem und genau so gewollt: Ein Wissensspeicher, den Agenten unkontrolliert vollschreiben, ist nach drei Wochen Müll.
Das Prinzip dazu haben wir festgehalten:
"Treat client and project knowledge as shared organizational memory, not as agent-specific prompt text."
Das war Problem drei — und die Voraussetzung dafür, dass Schicht 3 überhaupt funktioniert.
3. Mira und ihre Spezialisten – die Orchestrierung
Hier liegt der eigentliche Kern, und die Grafik zeigt ihn von oben nach unten.
Eine Anfrage trifft zuerst auf Mira , die Standard-Assistentin in Vela. Mira besitzt selbst keine Datenquellen. Ihre Aufgabe ist Urteil: die Frage verstehen, entscheiden, welche Quellen es braucht, delegieren, die Rückmeldungen prüfen und daraus eine zusammenhängende Antwort bauen.
Darunter liegen die Spezialisten — je einer pro System: kanonisches Firmenwissen, Asana, DatoCMS, GitHub, Pipedrive, Google Workspace. Wo eine Frage mehrere Systeme berührt, sitzt ein Router dazwischen, der selbst wieder delegiert: für Website-Recherche, für Controlling, für Publikation. Jeder Spezialist arbeitet in isoliertem Kontext und gibt nur sein Ergebnis zurück — nicht seinen Weg dorthin.
Genau das löst das Kontextfenster-Problem. Unser erster Reflex war, alle MCP-Server gleichzeitig zu aktivieren; das ging schief, weil allein die Werkzeugbeschreibungen einen erheblichen Teil des Fensters frassen, bevor eine Frage gestellt war. In der Orchestrator-Architektur, seit Mitte Juli 2026 im Einsatz, sieht jeder Agent nur, was er braucht.
Und sie macht die Anbieterunabhängigkeit erst wertvoll: Datenabfrage und Filterung übernehmen günstige, schnelle Modelle, die Orchestrierung und das Urteil ein High-End-Modell. Man zahlt Spitzenpreise nur für den Teil, der Spitzenqualität braucht.
Das waren die Probleme eins und drei zusammen.
4. Skills: Abläufe, die jedes Mal gleich laufen
Ein Agent, der jedes Mal neu improvisiert, ist zu teuer und langsam. Deshalb liegt unser Verfahrenswissen in Skills — versionierten Arbeitsanweisungen für wiederkehrende Aufgaben. Sie sind die Antwort darauf, dass sieben Leute dieselbe Aufgabe sieben Mal anders gelöst haben.
Der Reifeprozess ist geregelt: Ein neuer Skill entsteht in LibreChat, wird dort erprobt und wandert erst danach ins Repository gridonic/skills . Teamweit sichtbar wird er nur mit Admin-Rolle. Schnelles Experimentieren, kontrollierte Verbreitung.
Der Skill Website-Audit (SEO/GEO/AEO) prüft Suchmaschinen-, Generative- und Answer-Engine-Signale, vergibt Scores, verfolgt Regressionen über Läufe hinweg. Der Performance-Audit Skill ist eine Lighthouse-Messungen mobil/desktop je Seite mit priorisierten Empfehlungen. Der DatoCMS Knowledge Pack Skill s cannt ein CMS-Projekt read-only und legt Schema, Rollen, Plugins, Inventar als wiederverwendbares Wissenspaket ab.
Ein Skill ist damit mehr als ein gespeicherter Prompt: Er legt fest, welche Quellen befragt werden, in welcher Reihenfolge, mit welchem Qualitätsanspruch — und macht das Ergebnis über Monate vergleichbar.
Das war Problem zwei.