Was ist osFoundry und wie ist der KI-Arbeitsbereich für den Desktop aufgebaut?

Montag, 9:40 Uhr, vier Browser-Tabs sind offen: ein Chatbot für Fragen, ein zweiter, weil du dem ersten nicht ganz traust, ein Editor mit Coding-Agent und eine Notiz-App mit der Recherche von letzter Woche. Jedes Tool kennt einen Teil deiner Arbeit, keines kennt den Rest. Bis zur Mittagspause hast du denselben Absatz Kontext in drei verschiedene Fenster kopiert.

Eine App statt fünf Tabs

osFoundry ist ein KI-Arbeitsbereich für den Desktop: eine App, in der du mit KI-Modellen chattest, Arbeit an Agenten und Agenten-Teams abgibst, Notizen und durchsuchbares Wissen ablegst, offene Modelle auf deinem eigenen Rechner laufen lässt und kleine Apps für dein Team baust. Die Modelle können aus drei Quellen kommen: von deinem eigenen Rechner, von Cloud-Anbietern über deine eigenen API-Keys oder von gemieteten Cloud-GPUs. Die App ist in Kategorien gegliedert, und jede Kategorie enthält mehrere Screens. In Chat sprichst du mit Modellen (Maestro, Multi chat, Branchspace und weitere). In Workstation erledigen Agenten längere Aufgaben (Code, Agent, Agent team, Loop, Terminal). Knowledge enthält deine Texte und das, was sich die KI merkt. Local Model dient zum Finden, Installieren und Testen offener Modelle. Custom App ist für interne Tools gedacht, Discover für Webrecherche und News. Wer VS Code kennt: Am ehesten vergleichbar ist ein Editor mit Activity Bar, in der jedes Icon ein anderes Tool öffnet, nur dass die Tools hier KI-Oberflächen sind und sich dieselben Projekte, dasselbe Gedächtnis und dieselben Modelle teilen.

Wie ein typischer Screen aussieht

Mit der Kategorie Chat fangen die meisten an, deshalb eignet sie sich gut, um zu verstehen, wie die Screens von osFoundry aufgebaut sind. Das hier ist Multi chat im Council-Modus mit Beispieldaten: Drei Modelle haben dieselbe Frage bekommen und danach die Antworten der jeweils anderen bewertet.

• Die Tab-Leiste oben (Maestro, Model chat, Multi chat, Research, Wiki, Code) wechselt zwischen den Oberflächen des Chat-Bereichs: dem vollständigen Maestro-Agenten, einem einfachen Frage-Antwort-Chat mit Quellenangaben, mehreren Modellen gleichzeitig, Deep Research, Code-Dokumentation und Coding-Agenten.
• Der Schalter Compare / Council legt fest, wie die Modelle zusammenarbeiten. Compare stellt die Antworten nebeneinander, damit du selbst urteilst. Bei Council antworten sie getrennt, bewerten sich gegenseitig blind, und am Ende wird eine Synthese geschrieben.
• Jede Spalte ist ein Modell mit Anbieter-Tag: hier Anthropic, Ollama (lokal) und OpenAI. Cloud- und lokale Modelle lassen sich auf demselben Screen mischen.
• Die rechte Leiste zeigt die Phasen des Laufs (Answers, Ranking, Synthesis) und das Peer-review-Raster. So siehst du, wer was wie bewertet hat, statt nur eine fertige Antwort zu lesen.
• Der Run-Button zeigt schon vor dem Klick, wie viele Modellaufrufe der Lauf braucht (hier "Run · 7 calls"). Schaltest du das Peer-Ranking ab, sinkt die Zahl.

Viele Screens in osFoundry folgen diesem Muster: links eine Liste, in der Mitte die eigentliche Arbeit und rechts ein Inspector, der zeigt, wie ein Ergebnis zustande kam.

Die erste Woche eines Solo-Entwicklers

Ken betreibt allein einen kleinen Webshop. Er will eine KI, die seine Codebasis kennt, und einen Teil der Arbeit möchte er gern auf seinem Laptop behalten.

Am Montag öffnet er Local Model und dann Explore. Der Screen liest zuerst seinen Rechner aus (in diesem Beispiel 16 GB Arbeitsspeicher) und versieht jedes offene Modell mit einem Badge: Fits, Tight oder Too big. Er installiert ein Modell mit grünem Badge und stellt ihm in Playground ein paar Fragen. Playground schickt denselben Prompt an zwei Modelle nebeneinander und zeigt, wie schnell jedes mit der Antwort angefangen hat.

Am Dienstag muss er eine Funktion zur Preisformatierung ändern und weiß nicht genau, was alles davon abhängt. Er öffnet das Projekt in der IDE, klickt mit rechts auf die Funktion und wählt Show Code Graph.

Das Panel listet alle Aufrufer auf, markiert, welche Verbindungen direkt aus dem Code gelesen und welche nur abgeleitet wurden, und fasst unter Impact of change zusammen, wie viele Symbole, Dateien und Tests betroffen sein könnten. Ein Klick auf einen Aufrufer springt zur passenden Zeile, und mit Send to chat holt er den Graphen in eine Unterhaltung mit Maestro.

Ab Donnerstag gibt er kleine Aufgaben an Coding-Agenten ab. Im ADE-Screen bekommt jede Aufgabe ihren eigenen Worktree, und der Tab Changes zeigt den Diff. Er klickt in die Leiste neben einer Zeile, mit der er nicht einverstanden ist, tippt eine Notiz und schickt alle noch nicht gesendeten Notizen auf einmal an den Agenten. Am Ende der Woche hat er ein lokales Modell, dem er bei schnellen Fragen vertraut, und die Gewohnheit, vor jedem Refactoring die Auswirkungen zu prüfen.

Die erste Woche einer Teamleiterin

Aiko leitet vier Leute und liefert alle zwei Wochen ein Release aus. Ihr Problem ist nicht das Code-Schreiben, sondern der Überblick darüber, woran alle gerade arbeiten, egal ob Mensch oder Agent.

Sie beginnt in Message, dem Team-Chat. Channels und DMs funktionieren wie in Slack, mit einem Unterschied: KI-Agenten sind Mitglieder der Channels. Jemand erwähnt einen Agenten mit @ in #release, und seine Antwort samt Lauf landet wieder im Channel, wo alle sie sehen.

Als Nächstes richtet sie in Workstation ein Agent team ein. Ein Leader-Agent koordiniert spezialisierte Mitglieder, und der Screen trennt Team mail, Handoffs, Sub-agents und Proposals in eigene Tabs. So kann sie nachvollziehen, wer was an wen übergeben hat. Für die Prüfungen, die bei jedem Release anfallen, macht sie aus dem Team einen Loop: einen Trigger (zum Beispiel werktags morgens), Grenzen für Runden und Wiederholungen sowie Erfolgskriterien. Der Loop läuft in Runden, bis die Kriterien erfüllt sind, und führt Buch darüber, welche in welcher Runde bestanden wurden.

Arbeiten mehrere Agenten am selben Repository, nutzt sie Code. Jeder Agent bekommt seinen eigenen Branch und Worktree, und nichts wird von selbst gemergt. Sie wählt zwei fertige Läufe aus, klickt auf Preview combined merge und sieht, welche Dateien kollidieren, bevor irgendetwas den Main-Branch berührt.

Für Reviews auf Zeilenebene nutzt sie dieselben Notizen wie Ken: eine an den Code angeheftete Notiz, die mit Datei, Zeile und Code an den Agenten geht. Am Ende der Woche hat sie einen Channel, in dem die Arbeit der Agenten auftaucht, einen Release-Check, der von allein läuft, und einen Review-Schritt, der vor dem Merge stattfindet und nicht erst danach.

Die erste Woche einer Researcherin und Autorin

Lena schreibt lange Berichte über Arbeitsplatzrichtlinien. Sie braucht Quellen, die sie überprüfen kann, und hat schon schlechte Erfahrungen mit selbstsicheren KI-Antworten gemacht.

Bei Fragen, bei denen die Antwort eines einzelnen Modells nicht reicht, nutzt sie Multi chat im Council-Modus, also den Screen aus der Tour oben. Wenn zwei Reviewer eine Antwort schlecht bewerten, weiß sie, dass sie genauer nachgraben muss.

Für größere Fragen öffnet sie Agents, klickt auf New session und wählt das fertige Deep Research Team. Der Leader zerlegt die Frage in Teile und gibt jeden an ein Mitglied, etwa einen Data Researcher oder einen Search Specialist.

Ein separater Reviewer prüft jeden Schritt, bevor er bei ihr ankommt, und ein Schritt ohne Quelle wird zurückgeschickt und neu ausgeführt. Die finale Antwort kommt als Tabelle mit einer Quelle in jeder Zeile, dazu eine kurze Notiz, wo sich die Quellen widersprechen und was nicht abgedeckt wurde (Beispieldaten im Screenshot).

Das eigentliche Schreiben passiert in Knowledge. In Paper markiert sie einen Satz in ihrem Entwurf und hängt einen Denkraum daran, mit Tabs wie Academic search, Browser oder einer Maestro-Session, die nur diese Passage bespricht. Begleitdateien und Kommentare liegen in einer Note. In Discover speichert sie Suchen in Browser und folgt Keyword-Channels in News, sodass die Lektüre für einen Bericht auch beim nächsten noch da ist.

Wie die Bereiche sich die Arbeit übergeben

Die Kategorien sind keine getrennten Produkte, sie reichen die Arbeit weiter. Local Model ist die Schicht darunter: Ein Modell, das du über Explore installierst, taucht in den Modellauswahlen von Maestro, Multi chat und den Agenten-Sessions auf.

Knowledge versorgt Chat: Memory zeigt, was Maestro über deine Arbeit weiß, und unter Indexed Folders legst du fest, welche Ordner Agenten durchsuchen dürfen. Agenten-Sessions, Agent-team-Läufe und Loops berichten in Message-Channels. Workstation (der Screen mit diesem Namen) öffnet einen Channel, eine Notiz, eine Datei und eine Agenten-Session nebeneinander in einem Layout. Soll etwas, das du mit Agenten gebaut hast, ein Tool fürs Team werden, wandert es nach Custom App, wo ein Room die Apps eines Teams neben dessen eigenem Maestro-Chat bündelt. Keys und Anbieter für all das liegen in Configuration. Die Plattformübersicht listet jeden Screen auf, falls du die ganze Karte sehen willst.

Fragen aus der ersten Woche

Muss ich das alles nutzen?
Nein. Die meisten fangen mit einem Bereich an, meist Maestro in Chat oder Explore in Local Model, und nehmen weitere dazu, wenn eine Aufgabe es verlangt. Die Kategorien teilen sich Projekte und Gedächtnis, also musst du nichts, was du am Anfang machst, später neu aufsetzen.

Verlassen meine Daten meinen Rechner?
Nicht, wenn du lokale Modelle nutzt; die laufen auf deinem Gerät. Cloud-Modelle, die du über deine eigenen API-Keys anbindest, sehen, was du ihnen schickst, und diese Nutzung rechnet der Anbieter ab. Die Seite zu Local-first erklärt, wie beides getrennt ist.

Ist das nur für Entwickler?
Nein. Code, IDE und Terminal sind Entwickler-Tools, aber Message, Paper, Note, Research, Multi chat und Discover sind genauso für Autorinnen, Analysten und Teamleiter gebaut.

Was kostet es?
Die Desktop-App ist kostenlos zum Download, und für lokale Modelle fallen keine Nutzungsgebühren bei osFoundry an. Du bekommst sie auf der Download-Seite.