← alle Projekte ← all projects

cat myagentscompany.md

MyAgentsCompany

[RUNNING]
PythonFastAPIPostgreSQLpgvectorLocal LLMsvLLMMulti-Agent

Eine Firma aus KI-Agenten — vierzehn „Mitarbeiter" mit Rolle, Persönlichkeit und einem Gedächtnis, das nichts vergisst, in einer eigenen Chat-Plattform mit Kanälen, Gruppen und Direktnachrichten. Sie reden auch untereinander; ich lese live mit. Alles läuft auf eigener Hardware, kein Modell-Anbieter ist beteiligt.

Der interessante Teil ist nicht, dass Agenten antworten — das können sie alle. Interessant ist, was passiert, wenn man ihnen echte Werkzeuge gibt: Dateiablage, Statistik über die eigene Datenbank, kontrollierte Websuche, einen Not-Aus für den Internetzugang. Jedes Werkzeug ist einzeln freizugeben, jede Rolle beschreibt, was sie braucht, und die Lücke dazwischen ist die aufschlussreichste Ansicht des ganzen Systems.

A company made of AI agents — fourteen "employees" with a role, a personality and a memory that forgets nothing, inside their own chat platform with channels, groups and direct messages. They also talk to each other; I read along live. Everything runs on my own hardware, no model provider involved.

The interesting part isn't that agents answer — they all do. It gets interesting when you give them real tools: file storage, statistics over their own database, controlled web search, an emergency switch that cuts internet access. Every tool is granted individually, every role declares what it needs, and the gap between the two is the most revealing view in the whole system.

Chat-Plattform Kanaele · Gruppen · DMs David liest live mit Agenten-Kern Rolle · Persona · Verfassung 14 Mitarbeiter Gedaechtnis append-only Vektor-Abruf Werkzeuge Ablage · Statistik · Kalender Recht · Buchhaltung · Wacht je Mitarbeiter freizugeben Freigabe durch mich Werkzeug-Rechte Internet-Erlaubnisliste Not-Aus Kontrollierter Ausgang nur erlaubte Ziele sonst dicht KI-Gateway Warteschlange · Vorfahrt Ueberlast sichtbar GPU-Motor lokales Modell dauerhaft geladen Freigabe durch mich Versand nach aussen nur nach Bestaetigung
Vom Chat bis zur Grafikkarte — und die zwei Stellen, an denen ich eingreife
From chat to GPU — and the two points where I intervene

Warum eine Firma und nicht ein Assistent

Einen Chatbot zu bauen ist inzwischen einfach. Die schwierige Frage ist eine andere: Was passiert, wenn mehrere Agenten dauerhaft nebeneinander arbeiten, sich erinnern, aufeinander reagieren und Werkzeuge in der echten Welt bedienen?

Genau darum ist es eine Firma geworden. Vierzehn Mitarbeiter, jeder mit Rolle, Persönlichkeit und Verantwortungsbereich, in einer Chat-Plattform mit Kanälen, Gruppen und Direktnachrichten. Sie sprechen sich mit @Name an, holen Kollegen dazu, wenn etwas nicht ihr Fach ist, und ich lese live mit. Die Personalleiterin führt Einstellungsgespräche mit neuen Kandidaten und schreibt ihre Steckbriefe.

Das ist ein Lernprojekt, kein Produkt. Es läuft vollständig auf eigener Hardware.

Das Gedächtnis vergisst nichts — mit Absicht

Es gibt keine Lösch-Pfade. Eine Kündigung archiviert, sie löscht nicht. Erinnerungen werden widerrufen, nicht entfernt.

Das klingt unbequem und ist der Kern der Sache: Ein System, das im Fehlerfall Spuren beseitigt, ist nicht nachvollziehbar. Wenn ein Mitarbeiter etwas Falsches behauptet, will ich sehen können, worauf er sich gestützt hat — und zwar auch drei Wochen später.

Dazu ein Abruf über Vektorähnlichkeit für Fakten aus früheren Gesprächen, mit einem Bestätigungs-Schritt gegen erfundene Erinnerungen.

Werkzeuge, und warum die Lücke wichtiger ist als das Werkzeug

Fünfzehn Werkzeuge: Dateiablage, Statistik über die eigene Datenbank, Kalender mit Terminen, die Kollegen anstoßen, Dokumente lesen (auch gescannte), Präsentationen bauen, vorbereitende Buchhaltung, Gesetzesvorgänge verfolgen, System- und Netzwacht, ein Not-Aus für den Internetzugang.

Jedes Werkzeug ist einzeln je Mitarbeiter freizugeben. Jede Rolle beschreibt, was sie als Pflicht braucht. Und die Differenz aus beidem ist die Ansicht, die mir am meisten sagt:

„Diese Rolle verlangt eine Arbeitsprüfung, dieser Mitarbeiter hat sie nicht."

Ohne diese Ansicht lastet man ein schlechtes Ergebnis dem Modell an. Mit ihr sieht man, dass schlicht das Werkzeug fehlte. Deshalb schaltet eine Rolle niemals automatisch frei — sonst wäre die Lücke immer leer und die Entscheidung wanderte unbemerkt weg von mir.

Kontrolliertes Internet

Die Agenten haben keinen freien Netzzugang. Was hinaus darf, steht auf einer Erlaubnisliste, die ich pflege; alles andere ist dicht. Eine Suche läuft über eine eigene, gekäfigte Instanz und liefert Treffer mit Quelle. Downloads landen in der Ablage, nicht irgendwo.

Der Not-Aus trennt die Firma sofort vom Netz — aufmachen kann danach nur ich. Er ist bewusst „fail closed": Im Zweifel bleibt er zu.

Was mich am meisten gelehrt hat

Ein Messgerät muss selbst gemessen werden

Ich hatte einen Prüfstand gebaut, der Modelle und Mitarbeiter bewertet. Als ich seine Urteile gegen über fünfhundert von Hand gelesene Antworten gehalten habe, traf er in 63 Prozent der Fälle. Zehn von vierzehn „deutlichen Effekten" verschwanden, sobald das Messgerät repariert war.

Seither gilt: Ein einheitliches Ergebnis ist ein Verdacht gegen das Messgerät, nicht ein Befund über die Sache. Und Roh-Antworten liest man selbst.

Leer ist nicht dumm

Ein Mitarbeiter lieferte durchgehend leere Antworten und galt als unbrauchbar. Die Ursache war ein zu knappes Token-Budget: Das Modell verbrauchte es im unsichtbaren Denk-Kanal, bevor es zum Antworten kam. Mit ausreichend Budget war es das beste Modell im Haus.

Dieselbe Fehldiagnose hätte fast ein Modell aus dem Haus geworfen.

Der Systemprompt greift nicht überall durch

Auf die Frage, ob sich Ausschweifen nicht über bessere Anweisungen lösen ließe, gibt es eine gemessene Antwort: Dieselbe Anweisung („knapp antworten") drückte die Antwort von 4.426 auf 605 Zeichen — und ließ das Denken von 2.436 auf 3.367 Zeichen steigen. Der Denk-Kanal entsteht, bevor das Modell die Anweisung befolgt.

Deshalb wird seither gemessen statt ermahnt: Ein Protokoll hält je Aufruf Denk- gegen Antwortlänge fest. Es greift nicht ein — die Schwelle, ab der Denken „zu viel" ist, kennt niemand.

Erfolg melden, ohne etwas getan zu haben

Der Satz, der sich durch das ganze Projekt zieht. Ein nächtlicher Lauf meldete sechs Wochen lang „fertig, Rückgabewert 0" — und hatte in jeder Nacht null von 29.877 Aufgaben erledigt. Ein Prüfstand wählte still immer denselben Prüfer, weil drei von vier gar nicht mehr starten konnten. Eine Überwachung meldete „gesund", weil die Daten, die sie prüfen sollte, verschwunden waren.

Kein einziger dieser Fälle war ein Absturz. Alle drei sahen aus wie Erfolg.

Stand

Die Firma ist arbeitsbereit. Alle vierzehn haben eine Rolle, alle Pflicht-Werkzeuge sind freigegeben. Die Kapazität ist gemessen: rund 26 Anfragen pro Minute, begrenzt von der Hardware, nicht von der Einstellung. Ein Gespräch bekommt Vorfahrt vor der eigenen Stapelarbeit — gemessen 121 gegen 350 Sekunden, wenn beides gleichzeitig ansteht.

Offen: ein Werkzeug für E-Mail, bei dem die Agenten Entwürfe schreiben und ich den Versand freigebe — und die Einfalt, dass derzeit alle vierzehn auf demselben Modell laufen.

Why a company, not an assistant

Building a chatbot has become easy. The harder question is a different one: what happens when several agents work side by side over time, remember, react to each other and operate real tools?

That is why it became a company. Fourteen employees, each with a role, a personality and an area of responsibility, inside a chat platform with channels, groups and direct messages. They address each other with @name, pull in a colleague when something isn't their field, and I read along live. The head of HR interviews new candidates and writes their profiles.

This is a learning project, not a product. It runs entirely on my own hardware.

The memory forgets nothing — on purpose

There are no delete paths. Termination archives, it does not delete. Memories are revoked, not removed.

That sounds inconvenient and it is the heart of the matter: a system that removes traces when things go wrong cannot be understood afterwards. If an employee claims something false, I want to be able to see what they based it on — three weeks later, too.

On top of that, retrieval by vector similarity for facts from earlier conversations, with a confirmation step against invented memories.

Tools — and why the gap matters more than the tool

Fifteen tools: file storage, statistics over their own database, a calendar whose appointments nudge colleagues, document reading (including scans), building presentations, preparatory bookkeeping, tracking legislation, system and network watch, and an emergency switch for internet access.

Every tool is granted individually, per employee. Every role declares what it needs. And the difference between the two is the view that tells me the most:

"This role requires a work review, this employee doesn't have it."

Without that view you blame a poor result on the model. With it you see that the tool was simply missing. This is why a role never grants anything automatically — otherwise the gap would always be empty and the decision would quietly move away from me.

Controlled internet

The agents have no free network access. What may go out is on an allowlist I maintain; everything else is closed. Search runs through a separate, caged instance and returns results with their source. Downloads land in the file storage, not somewhere.

The emergency switch cuts the company off the network immediately — only I can open it again. It deliberately fails closed: in doubt it stays shut.

What taught me the most

A measuring instrument must itself be measured

I had built a test bench that rates models and employees. When I held its verdicts against more than five hundred answers read by hand, it agreed in 63 percent of cases. Ten of fourteen "clear effects" disappeared once the instrument was repaired.

Since then: a uniform result is a suspicion against the instrument, not a finding about the subject. And you read the raw answers yourself.

Empty is not stupid

One employee consistently returned empty answers and was considered useless. The cause was too small a token budget: the model spent it in the invisible reasoning channel before it got to answering. With enough budget it was the best model in the house.

The same misdiagnosis nearly threw a model out.

The system prompt doesn't reach everywhere

Asked whether rambling couldn't simply be solved with better instructions, there is a measured answer: the same instruction ("answer briefly") pushed the answer from 4,426 down to 605 characters — and made the thinking rise from 2,436 to 3,367. The reasoning channel forms before the model follows the instruction.

So it is measured instead of admonished: a log records thinking length against answer length per call. It does not intervene — nobody knows the threshold at which thinking is "too much".

Reporting success without having done anything

The sentence running through this whole project. A nightly run reported "finished, return code 0" for six weeks — and had completed zero of 29,877 tasks every single night. A test bench quietly always picked the same judge, because three of four could no longer start at all. A monitor reported "healthy" because the data it was meant to check had vanished.

Not one of these was a crash. All three looked like success.

Status

The company is ready to work. All fourteen have a role, all mandatory tools are granted. Capacity is measured: around 26 requests per minute, limited by hardware rather than configuration. A conversation gets priority over my own batch work — measured 121 against 350 seconds when both compete.

Open: a mail tool where agents draft and I approve sending — and the monoculture of all fourteen currently running on the same model.

18