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 den Preis für ein bestehendes Modell erhöhte, stiegen die Kosten für dieselbe Arbeit von 3 auf 5 Dollar pro Million Input-Tokens — und von 15 auf 25 Dollar pro Million Output-Tokens. Ü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 letztlich 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 Projektinformationen und Notizen 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 die Aufgabe übernimmt 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: AI-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 und Frontend-Arbeit laufen 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 aus fremden Modellen ein eigenes Werkzeug machen. 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
Vela ist das Fundament unserer neuen Arbeitsweise als Agentur. Die Plattform bringt unser Wissen, unsere Werkzeuge und unsere Abläufe zusammen. Damit kommen unsere Kunden in ihren Projekten schneller voran, können auf unser Wissen zugreifen und mehr selbst in die Hand nehmen.
Unsere AI-Plattform besteht aus vier Bausteinen: Vela als zentrale Anwendung, Knowledge als gemeinsame Wissensbasis in Vela, Mira für die Orchestrierung und Skills für wiederkehrende Aufgaben.
1. Vela – die Plattform
Zuerst haben wir unsere internen Tools einzeln angebunden – darunter Asana, Harvest, Confluence und Pipedrive. Dann gingen wir einen Schritt weiter: Wir bauen unsere Werkzeuge selbst, zugeschnitten auf unsere Bedürfnisse und vereint in einer eigenen Anwendung. Seit Ende Juli 2026 heisst sie Vela und bringt unsere Prozesse und Daten an einem Ort zusammen. LibreChat ist über MCP mit Vela verbunden und macht diese direkt im Chat zugänglich – für Abfragen, Auswertungen und die Arbeit mit unseren Agenten.
Für LibreChat haben wir uns im Juni 2026 entschieden: wegen der Sicherheit, der geteilten Workspaces und der zentralen Steuerung der API-Kosten. Unsere Plattform bleibt dabei an keinen einzelnen Modellanbieter gebunden. Welches Modell eine Aufgabe übernimmt, entscheiden wir per Konfiguration. Steigt ein Token-Preis, können wir wechseln.
Das war Problem eins: die Abhängigkeit von einzelnen Modellanbietern.
2. Knowledge – Wissen organisieren und verfügbar machen
Seit Juni 2026 organisieren wir unser Firmen-, Kunden- und Projektwissen als gemeinsame Wissensbasis. Was als eigenständiger Knowledge-Service begann, ist heute Teil von Vela. Über den Vela-MCP greifen unsere AI-Tools auf dieses Wissen zu. MCP steht für Model Context Protocol – ein offener Standard, der AI-Systeme mit externen Daten und Werkzeugen verbindet.
Die Struktur ist bewusst simpel:
-
Global — Positionierung, Services, Tool-Landschaft, Team
-
Clients — Zielgruppen, Angebot, Proof Points
-
Projects — Kontext, Ziele, Constraints
-
Collections — geordnete Dokumentserien im Projekt
So greifen alle auf dieselbe Wissensbasis zu, und Aktualisierungen müssen nur an einer Stelle vorgenommen werden. 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:
«Kunden- und Projektwissen gehört ins gemeinsame Gedächtnis des Unternehmens, nicht in die Prompts einzelner Agenten.»
Das war Problem drei: der fehlende Kontext
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. Sie steuert die Zusammenarbeit der spezialisierten Agenten: Sie versteht die Anfrage, entscheidet, welches Wissen und welche Werkzeuge gebraucht werden, und verteilt die Aufgaben. Anschliessend prüft sie die Rückmeldungen und führt sie zu einer zusammenhängenden Antwort zusammen.
Die Spezialisten übernehmen klar abgegrenzte Aufgaben und greifen auf die dafür nötigen Systeme zu – etwa Vela, DatoCMS, GitHub oder 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.
So bleibt der Kontext überschaubar: Jeder Agent erhält die Informationen und Werkzeuge, die er für seine Aufgabe braucht. Diese Orchestrator-Architektur setzen wir seit Mitte Juli 2026 ein.
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: Anbieterabhängigkeit und fehlender Kontext.
4. Skills: gemeinsame Standards für wiederkehrende Aufgaben
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.
Unsere Skills werden zentral gepflegt und im Team weiterentwickelt. Wenn jemand einen Ablauf verbessert, profitiert das ganze Unternehmen davon. Wir synchronisieren die Skills mit den eingesetzten AI-Tools, damit alle auf derselben Grundlage arbeiten – unabhängig davon, welches Tool sie für eine Aufgabe nutzen.
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 umfasst Lighthouse-Messungen für Mobilgeräte und Desktop je Seite mit priorisierten Empfehlungen. Der DatoCMS-Knowledge-Pack-Skill scannt 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: die zersplitterten Arbeitsweisen im Team.