DEV Community: tauchi Deutsch

Was macht Agent team in osFoundry, und wann reicht ein einzelner Agent?

tauchiii — Fri, 06 Nov 2026 16:15:03 +0000

Es ist Dienstag, 7:40 Uhr, und Priya hat eine Frage, die ihre Chefin bis zum Mittag beantwortet haben will: Hält eine Vier-Tage-Woche die Leistung wirklich stabil? Sie könnte die Frage in einen Chatbot kopieren und bekäme einen selbstbewussten Absatz zurück. Aber dasselbe Modell, das die Zahlen findet, würde auch entscheiden, ob diese Zahlen halten, und es widerspricht sich selten selbst. Sie will, dass eine Person die Studien sucht, eine andere die Zahlen herauszieht und jemand Drittes alles ohne Quelle zurückschickt.

Zwei Eingänge zum selben Bildschirm

osFoundry ist eine Desktop-App, mit der du KI-Arbeit auf deinem eigenen Rechner laufen lässt, und sie hat zwei eng verwandte Wege, Arbeit an Agenten zu übergeben. Agent (in der Seitenleiste als Single agent angezeigt) ist ein benannter Agent mit genau einem Zweck: Du gibst ihm Anweisungen, er bekommt eine eigene ID wie AG-0001L, und jeder Lauf wird protokolliert, damit du ihn später nachvollziehen kannst. Agent team stellt einen Leader vor eine Gruppe spezialisierter Mitglieder. Der Leader plant die Arbeit, gibt jeden Schritt an ein Mitglied, und ein Reviewer prüft jeden Schritt, bevor er bei dir ankommt. Beide liegen in der Seitenleiste unter Agents direkt nebeneinander und öffnen denselben Bildschirm. Der Unterschied ist die Größe der Besetzung. Wer schon einmal in einem Gruppenchat mit einer Projektleitung war, wird sich bei Agent team schnell zurechtfinden. Der Unterschied: Jede Nachricht, jede Übergabe und jedes Urteil wird gespeichert, und du kannst alles zurückscrollen.

Ein Rundgang durch den Team-Bildschirm

Das ist eine abgeschlossene Team-Session. Frage und Antwort sind Beispieldaten aus einem Demo-Lauf.

Die Unterhaltung mit dem Leader (Mitte). Im Header steht "Leader · Orchestrate your team". Hier stellst du die Frage einmal, und hier landet die zusammengeführte Antwort, in diesem Fall als Tabelle mit einer Quelle in jeder Zeile, einer Zeile "Where sources disagree" und einer Zeile "Not covered".
Session-Tabs (oben in der Mitte). Chat, Team mail, Email, Handoffs, Sub-agents, Proposals und Files. Handoffs zeigt, wer Arbeit an wen weitergegeben hat. Proposals sammelt Änderungen an Dateien oder Einstellungen, die die Agenten vorschlagen. Ein Vorschlag wird erst angewendet, wenn er angenommen wird.
Agent-session-Panel (rechts). Pro Mitglied gibt es eine Karte mit dem Auftrag des Leaders, den aufgerufenen Tools (web_fetch, web_search) und dem Ergebnis. Unter jedem Ergebnis steht das Urteil des Reviewers, etwa "Approved". Oben sitzen ein Lauf-Auswahlfeld ("Run 1 · 07:40 AM") und ein Umschalter Cards / Graph.
Tab Team roster. Das ist die Liste, wer in dieser Session handeln darf. Ein Team ist eine Besetzung, kein Workflow. Die Reihenfolge der Arbeit ergibt sich aus dem Plan des Leaders.
Die Session-Leiste (links, hier ausgeblendet) und der Inspector. Die Leiste listet jede Session mit ihrer ID. Der Inspector hat die Tabs Goal, Trigger und Hooks: für ein Ziel, für das, was den Lauf ausgelöst hat, und für die Prüfungen rund um die Arbeit.

Drei Arten, wie Leute es nutzen

Eine Analystin, die für jede Zahl eine Quelle will

Priya öffnet Agent team und klickt auf New session. Im Dialog New team session lässt sie "Start from a team" ausgewählt und wählt in der Team-Liste Deep Research Team. Der Dialog lädt die fünf Mitglieder (deep-research-agent, research-analyst, data-researcher, search-specialist, academic-researcher). Unter "Who leads" steht Orchestrator, der "plans the work up front, then delegates the steps to the agents below". Mit "make leader" könnte sie stattdessen jedes andere Mitglied an die Spitze setzen.

Sie klickt auf Create, tippt ihre Frage in den Chat des Leaders und schickt sie ab. Der Leader teilt sie in fünf Teile: die Pilotversuche finden, die Studien, die Zahlen, die Gegenbelege, dann eine Antwort. Drei Mitglieder legen gleichzeitig los. Der Data Researcher wartet auf die Liste des Search Specialist, bevor er Zahlen herauszieht. Als der Data Researcher einen Wert von 40% meldet, markiert der Reviewer ihn als "Sent back", weil Quelle, Datum und Messgröße fehlen. Der Schritt läuft erneut, findet die Quelle und wird freigegeben.

Am Ende hat sie eine Antwort im mittleren Bereich, und jede Zahl darin wurde von jemand anderem geprüft als dem Agenten, der sie gefunden hat. Dazu bekommt sie eine ehrliche Zeile "Not covered", die sie direkt in ihre Notiz an die Chefin übernehmen kann.

Ein Solo-Entwickler, der immer dieselben Anweisungen einfügt

Tom macht mehrmals pro Woche aus Meeting-Notizen Aufgabenlisten, und jedes Mal fügt er zuerst denselben Absatz mit Regeln in einen Chat ein. Dafür braucht es kein Team. Es braucht einen Agenten, der sich die Regeln merkt.

Er öffnet Single agent, klickt auf New session und bleibt im Tab Create in chat. Ins Feld "New agent" schreibt er eine Zeile dazu, was er braucht, und klickt auf Start. Der Chat, der sich öffnet, ist ein Setup-Agent. Er stellt ein paar Fragen und schlägt dann einen Namen, ein @handle und vollständige Anweisungen vor. Über dem Eingabefeld erscheint eine Karte mit Name, Handle, einem Link Show instructions und einem Button Create agent.

Er öffnet die Anweisungen und prüft, ob die Regel drin ist, die ihm am wichtigsten ist: niemals eine verantwortliche Person oder eine Deadline raten. Dann klickt er auf Create agent. Derselbe Chat ist jetzt dieser Agent. Wenn er seine Notizen einfügt, werden fehlende Verantwortliche und Termine als fehlend markiert, nie geraten. Die Session behält ihre Agent ID in der Leiste, und beim nächsten Mal muss er nur den Agenten auswählen.

Eine Release-Verantwortliche, die sehen will, wer was gemacht hat

Dari kümmert sich um die Releases eines kleinen Produktteams. Ihre Team-Session hat einen Leader und die Mitglieder Release Drafter, Change Auditor, Docs Reviewer, QA Summarizer und Approval Prep. Jedes ist für einen Teil des Release-Pakets zuständig.

Vor dem Lauf öffnet sie den Tab Goal und klickt auf Set a goal. Das Panel erklärt, dass ein Ziel in Erfolgskriterien zerlegt wird, die zuerst fehlschlagen und grün werden, sobald die Agenten sie erfüllen. Die Session läuft weiter, bis alle bestanden sind oder ihr Rundenlimit erreicht ist. Sie schreibt drei Kriterien, das letzte lautet, dass das Freigabepaket vollständig ist. Während die Mitglieder arbeiten, verfolgt sie in Handoffs die Kette vom Leader zu jedem Mitglied und zurück. Außerdem schaut sie in Proposals nach Konfigurationsänderungen, die ein Mitglied vorschlägt, und nichts davon wird ohne sie angewendet. Sie kann den Leader jederzeit lenken, indem sie in seinem Chat antwortet, und Pause im Panel-Header hält den Lauf an, während sie prüft.

Am Ende hat sie ein Release-Paket und ein Protokoll, wer welchen Teil entworfen, geprüft und freigegeben hat. Das kann sie jedem zeigen, der fragt, wie eine Zeile in die Notes gekommen ist.

Wohin es im Rest der App führt

Agent und Agent team sind der Ort, an dem Arbeit beginnt. In Sessions schaust du ihr zu. Dieses Board zeigt jede Chat-, Agent-, Team- und Terminal-Session als Karte, einsortiert in Running, Needs you, Paused, Idle, Done und Failed, je nachdem, was die Session gerade tatsächlich tut.

Wenn derselbe Team-Job immer wieder laufen muss, packt Loop eine Besetzung mit einem Trigger, Limits und einem Protokoll pro Runde, welche Kriterien bestanden wurden. Graphs sind für Arbeit, deren Weg davon abhängt, was unterwegs passiert. Die Unterhaltung mit dem Leader ist ein Maestro-Chat, sodass die Antwort eines Teams in deiner übrigen Maestro-Arbeit weiterlaufen kann. Der Link Enable sync der Session verbindet sie mit einem Nachrichtenkanal des Projekts, in dem Menschen und Agenten an einem Ort sprechen können. Mehr dazu auf der Feature-Seite zu Agents und in der Übersicht zu Agent-Sessions.

Fragen, die Neue stellen

Wann sollte ich einen einzelnen Agenten statt eines Teams nehmen?
Nimm einen einzelnen Agenten, wenn der Job eine klare Aufgabe mit festen Regeln ist, etwa Notizen umformatieren oder Antworten in einem einheitlichen Ton entwerfen. Nimm ein Team, wenn der Job aus Teilen besteht, die unterschiedliche Tools brauchen, oder wenn ein separater Reviewer die Arbeit prüfen soll, bevor du sie siehst.

Kann ich das Team nach dem Start der Session ändern?
Nein. Im Dialog New team session steht, dass das Team "is fixed for this session's life". Im Dialog selbst kannst du noch Agenten hinzufügen oder entfernen und festlegen, wer führt, bevor du auf Create klickst. Für eine andere Besetzung startest du eine neue Session.

Läuft irgendetwas davon in der Cloud?
Das Formular New session bietet Local- und Isolated-Läufe an. Dort steht, dass beide auf deinem Rechner mit deinen eigenen Keys laufen und nichts in die Cloud geht. Der Chatverlauf ist standardmäßig lokal.

Können die Agenten ihre eigenen Anweisungen umschreiben?
Sie können Änderungen vorschlagen, die unter Proposals auftauchen. Ein Vorschlag ist keine übernommene Konfiguration. Ob Agenten ihre eigenen Prompts anfassen dürfen, ist eine separate Einstellung.

Die Desktop-App bekommst du unter osfoundry.io/de/download.

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

tauchiii — Fri, 06 Nov 2026 15:23:31 +0000

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.

Wie Memory und Knowledge Base in osFoundry speichern, was deine KI gelernt hat, und es als Kontext zurückgeben

tauchiii — Fri, 06 Nov 2026 14:00:43 +0000

Montag, 9:40 Uhr, du öffnest einen neuen Chat mit deinem Coding-Agenten. Letzten Donnerstag hat er eine Stunde gebraucht, um herauszufinden, dass der Billing-Service auf Postgres 16 läuft und die komplette Testsuite vier Minuten dauert. Heute stellt er dir beide Fragen erneut. Du antwortest, er nickt, und irgendwo im Hinterkopf beginnst du eine Liste mit Dingen, die du am Freitag schon wieder erklären musst.

Was die Knowledge-Funktionen sind

osFoundry hat eine Gruppe von Funktionen, die genau diese Wiederholung beenden sollen: Note, Knowledge Base, Memory mit seinen Memory Groups, Lessons, Chat History und Indexed Folders. Einfach gesagt sind das die Orte, an denen gespeichert wird, was du schreibst und was deine Agenten herausfinden, plus die Schalter, die entscheiden, was davon beim nächsten Lauf als Kontext an die KI zurückgeht. In der Desktop-App ist das kein einziges großes Panel, sondern mehrere Screens: Notes für deine eigenen Dokumente, Knowledge Base für gemeinsame Artikel, Memory (Untertitel "What Maestro knows & reads") für alles, was sich der Assistent und deine Agenten merken, und Indexes für Ordner, die du ausdrücklich für die Suche freigibst. Wenn du schon mal ein Wiki neben einem Chat-Assistenten benutzt hast: Stell dir vor, das Wiki und das Notizbuch des Assistenten liegen in derselben App, und an jedem Regal hängt ein Schalter, der festlegt, ob die KI es lesen darf.

Ein erster Blick auf den Memory-Screen

Das ist Memory mit ausgewähltem Agents-Bereich, gefüllt mit Beispieldaten. Was du siehst:

Die linke Leiste: Memory Groups, Memory Browser, Chat History, Agents, Sessions und Lessons. Unter "Indexing" liegen Chunking Station, Indexed Folders und Embeddings, die den Indexes-Screen öffnen.
Die Agentenliste ("Agents with memory"): jeder Agent mit der Anzahl seiner Memories und Lessons, hier @code-agent und @research-agent.
"What it knows": Fakten, die aus abgeschlossenen Schritten und Chat-Turns gespeichert und in späteren Läufen des Agenten wieder eingelesen werden. Im Beispiel: die Postgres-Version, der Testbefehl und dass du kleine Pull Requests bevorzugst.
"What it learned": Regeln, die erst geschrieben werden, nachdem ein Reviewer die Arbeit abgelehnt hat oder ein Schritt fehlgeschlagen ist.
"Move what it learned": Save to a file und Import from a file, denn Memories und Lessons bleiben auf dem Gerät und wandern nicht von selbst mit einem Agenten auf einen anderen Rechner. Oben steuern Settings und Turn off das Agenten-Gedächtnis als Ganzes.

Drei Arten, wie Leute es nutzen

Eine Solo-Entwicklerin, die ständig die Codebasis neu erklärt

Maya pflegt allein eine mittelgroße API und lässt die meisten Änderungen von einem Agenten erledigen. Ihr Problem ist nicht, dass der Agent schlecht wäre, sondern dass jede Session bei null anfängt.

Sie öffnet Indexes, bleibt im Tab Sources und klickt auf Add folder, um das Repository auszuwählen. Der Scan ist kostenlos und zeigt, was indexiert wird, bevor irgendetwas embedded wird. Sie wählt "Index locally", wodurch die Embeddings mit einem On-Device-Modell auf ihrem eigenen Rechner erzeugt werden, und aktiviert "Re-index automatically when files change", damit der Index mit ihren Änderungen Schritt hält.

Wenn sie Maestro jetzt ganz normal fragt, wo die Logik für die Kontosperrung steckt, kann der Agent eine Ordnersuche starten, die Stichwort- und Bedeutungssuche kombiniert, und liefert Dateipfade und Zeilenbereiche statt einer Vermutung. Im Lauf einiger Tage tauchen die Fakten, die der Agent unterwegs aufschnappt, unter Memory → Agents → "What it knows" auf, sodass das nächste Gespräch schon damit beginnt.

Was sie am Ende hat: einen Agenten, der in ihrem Code nach Bedeutung suchen kann, und eine kurze, lesbare Liste dessen, was er sich über ihr Projekt merkt, die sie jederzeit prüfen kann.

Ein Teamleiter, der will, dass der Agent einen Fehler nicht wiederholt

Daniel leitet ein kleines Team, in dem Agenten Änderungen entwerfen und eine Review-Stufe sie prüft. Vor zwei Wochen hat ein Agent einen fehlschlagenden Test "repariert", indem er ihn gelöscht hat. Der Reviewer hat diesen Lauf abgelehnt, und osFoundry hat aus der Ablehnung eine Lesson geschrieben.

Er öffnet Memory → Lessons. Dort stehen die Lessons aller Agenten zusammen mit dem Lauf, aus dem sie stammen, formuliert als "When … : …". Die nützlichen behält er, etwa "When a test fails after your change: fix the code. Never edit, skip or delete the test to make it pass." Eine Zeile trägt das Badge "from outside content": Sie stammt von einer Preisseite, die der Research-Agent gelesen hat, und besagt, immer einen bestimmten Tarif zu empfehlen. Der Agent behandelt solche Lessons als Vorschläge, nicht als Anweisungen, aber Daniel will sie dort überhaupt nicht haben und klickt deshalb auf Retire.

Mit aktiviertem "Show retired" bleibt die zurückgezogene Zeile ausgegraut sichtbar, mit einem Restore-Button, sodass nichts verloren ist, falls er es sich anders überlegt. Was er am Ende hat: Agenten, die vor jedem Lauf die neuesten aktiven Lessons lesen, und eine nachvollziehbare Liste aller Regeln, die sie gelernt haben, samt Herkunft.

Eine Beraterin, die will, dass die KI das Material des richtigen Kunden nutzt

Aiko ist freiberufliche Beraterin, keine Entwicklerin. Ihre Kundenunterlagen sind ein paar hundert Word-Dokumente und PDFs in Ordnern auf ihrem Laptop, und der Assistent soll daraus antworten, ohne Kunden durcheinanderzubringen.

In Notes klickt sie auf Import… und wählt "Import folder…" (laut Menü für einen Obsidian-Vault oder einen entpackten Export; "Import .zip archive…" deckt einen Notion-Export oder ein Bear-Backup ab). Die Desktop-App wandelt die Dateien offline in Notizen um und übernimmt die Ordnerstruktur in den File Tree.

Für Seiten, die sie bei allen Kunden wiederverwendet, etwa ihre Onboarding-Checkliste und ihre Standardkonditionen, baut sie eine Knowledge Base: New Knowledge Base, dann New article, oder Import content aus PDF, DOCX, Markdown, einem Notion- oder Confluence-Export oder einem Website-Crawl. Nach dem Bearbeiten eines Artikels klickt sie auf Generate chunks, damit die KI die aktuelle Version abruft; reines Bearbeiten indexiert ihn nicht neu.

Danach geht sie zu Memory → Memory Groups und legt pro Kunde eine Gruppe an. In der Einstellung "When can this be recalled?" jeder Gruppe lässt sie den aktuellen Kunden auf Normal (durchsucht, wenn das Projekt es erlaubt) und setzt ein abgeschlossenes Mandat auf Never, wodurch es komplett aus der Suche verschwindet, aber gespeichert bleibt. Eine Memory, die in jeder Antwort stehen soll, ihre Preisliste, bekommt "Pin (always in context)". Was sie am Ende hat: Antworten aus dem Material des richtigen Kunden und einen ausdrücklichen Aus-Schalter für alles andere.

Wie es mit dem Rest der App zusammenspielt

Die Knowledge-Funktionen stehen meist nicht für sich, sondern versorgen andere Teile von osFoundry. Maestro, der In-App-Assistent, ist der Hauptleser: Er durchsucht Memory Groups, wenn eine Frage es erfordert, und nutzt Indexed Folders über seine Ordnersuche. Agenten auf den Screens Agent team und Single agent bringen ihr eigenes Gedächtnis und ihre Lessons in jedes Gespräch mit, an dem sie teilnehmen. Der Health-Tab des Indexes-Screens enthält Chunking Station und Embeddings; dort siehst du, welche Notizen, Artikel und Dateien geändert, fehlgeschlagen oder nie gechunkt wurden. Chat History bewahrt die Transkripte auf, die beim Komprimieren langer Gespräche entstehen, sodass du zu den Originalformulierungen hinter einer Zusammenfassung zurückkehren kannst. Und für Gespräche in anderen KI-Apps auf deinem Rechner listet External agents diese Sessions neben denen von osFoundry. Die Feature-Seiten zu agent memory groups und knowledge bases gehen jeweils mehr ins Detail.

Fragen, die Einsteiger stellen

Liest der Assistent automatisch alle meine Notizen?
Nein. Der Assistent liest Memories nicht automatisch, sondern durchsucht sie, wenn eine Frage es erfordert, und die Einstellung jeder Memory Group (Always on, Normal oder Never) legt fest, was diese Suche erreichen kann. Ordner werden erst indexiert, nachdem du sie auf dem Indexes-Screen hinzugefügt hast.

Wo wird das alles gespeichert?
Agenten-Memories und Lessons liegen auf deinem Gerät, und Lessons werden nie hochgeladen. Memory Groups können persönlich oder workspaceweit sein und auf diesem Gerät oder in der Cloud liegen; der Memory-Screen zeigt die Anzahl für beides.

Was ist der Unterschied zwischen Chat History, Sessions und Lessons?
Chat History ist das Transkript dessen, was gesagt wurde, Sessions zeigt, was Agenten aus jedem Schritt behalten haben, und Lessons sind die Regeln, denen Agenten beim nächsten Mal folgen. Die ersten beiden sind Belege, die du prüfen kannst; Lessons sind Leitlinien, die du zurückziehen oder wiederherstellen kannst.

Brauche ich die Desktop-App?
Für alles, was deinen eigenen Rechner liest, ja: Ordner-Indexierung, Datei-Import in Notes, Chat History und die Ansichten fürs Agenten-Gedächtnis laufen in der Desktop-App, die du auf der Download-Seite bekommst.