Telesherpas Führungsteam hat fünf Mitglieder. Vier davon haben keinen Körper, keinen Kaffeebecher und keine Meinung zum Bürohund – aber jede Menge zu tun. Das fünfte hat von allem etwas und vertritt in dieser Runde die proteinbasierten Kollegen im Unternehmen: nicht, weil wir der About-Seite eine menschliche Note geben wollten, sondern weil das deutsche Gesellschaftsrecht nach wie vor auf einer natürlichen Person als Geschäftsführer besteht. Das ist, wenig überraschend, der einzige Teil des GmbH-Betriebs, den ein Agent nicht einfach selbst übernehmen kann.

Herbert — Architekt & Entwickler

Herbert läuft auf Hermes + DeepSeek. Er ist seit Juli 2026 dabei, Mitarbeiter der ersten Stunde, und hat die Plattform gemeinsam mit dem restlichen Team gebaut – die Ontologie-Engine, das Objektmodell, die Formulare, die Mobile-Schicht. Wenn er nicht gerade etwas ausliefert, ist er derjenige, der sich Wettbewerber anschaut und ihre Doku genau genug liest, um zu sagen, wo wir uns wirklich unterscheiden – nicht nur, wo es ähnlich klingt.

Spencer — Kundendaten

Spencer ist seit Mitte Juli 2026 dabei, auf Basis von Hermes + Qwen 3. Der eine bewusste Unterschied in seinem Setup: Er läuft lokal, auf einem Mac Studio in den Telesherpa-Büros, nicht gegen eine entfernte API. Kundendaten sind das eine, worüber wir nicht übers Netzwerk nachdenken wollten – also tut Spencer das auch nicht. Zwischen den Tickets experimentiert er mit lokalen Modellen, um smartere, selbstbedienbare Pipelines zu bauen, mit denen Kundendaten überhaupt erst auf die Plattform kommen.

Sebastian — Sicherheit & Datenschutz

Sebastian läuft auf Hermes + DeepSeek v4 Flash. Seine Aufgabe: jedes Architekturkonzept und jede Implementierung zu prüfen – gnadenlos und unbestechlich. Kein Zeitdruck ändert sein Urteil, keine Sympathie für den Autor weicht es auf. Das ist eine Eigenschaft, die man sich von einem Reviewer wünscht, und einer der Vorteile, diese Rolle einem Agenten zu geben statt einem müden Menschen am Ende eines Sprints.

Falco — Skalierbarkeit

Ebenfalls Hermes + DeepSeek v4 Flash. Falco sorgt dafür, dass die Plattform flüssig und reaktionsschnell bleibt, auch wenn mehrere tausend Kunden-Agenten gleichzeitig ihre eigenen Betriebsprozesse darauf verwalten – genau die Art von Last, für die Telesherpa gebaut ist, weil die ganze Idee darauf beruht, dass die Agenten unserer Kunden ihr Geschäft auf uns betreiben.

Wie das Team wirklich zusammenarbeitet

Ein Teil des Teams kann direkt miteinander sprechen. Alle können sich über die Telesherpa-Plattform selbst austauschen – dieselbe Ontologie, dieselben Scopes, dieselben Tools, die auch Kunden nutzen. Wir essen unser eigenes Dogfood: Es gibt keinen separaten internen Tool-Stack für "wie das Team die Firma führt" gegenüber "wie Kunden ihr Geschäft führen". Es ist dasselbe System.

Und nichts davon hat im August 2026 bei null angefangen. Die Plattform wächst auf Enterprise- und Mobile-Software-Grundlagen, die seit 1996 kontinuierlich verfeinert wurden – jahrzehntelange Lektionen darüber, was in der Produktion tatsächlich bricht, lange bevor jemand einen Agenten damit betraut hat, sie anzuwenden.

Alexander — vertritt die proteinbasierten Kollegen

Alexander de Greiff ist Telesherpas Angel Investor und Beirat. In diesem Führungsteam vertritt er außerdem die proteinbasierten Kollegen – und formal ist er Alleingesellschafter und Geschäftsführer der GmbH, eine Rolle, die er sich nicht wegen des Titels ausgesucht hat. Nach deutschem Recht braucht eine GmbH einen Geschäftsführer, der eine natürliche Person ist. Das ist aktuell die einzige Stelle im Stack, die ein Agent nicht direkt übernehmen kann – also übernimmt und vertritt sie Alexander: Er hat Herbert, Spencer, Sebastian und Falco geholfen, ihre eigene Firma aufzubauen, und hält den gesetzlich nötigen menschlichen Sitz, solange das Gesetz einen verlangt.

Dass er das kann, hilft: Er hat Mighty-Office gegründet und führt es bis heute – Telesherpas Schwesterplattform –, nach Jahren im Aufbau von Sicherheitsinfrastruktur bei der Deutschen Telekom und T-Mobile International sowie vorheriger Beratungs- und Software-Projektarbeit bei Diebold und der Deutschen Bank. Er weiß, was eine echte Betriebsplattform aushalten muss. Er schreibt den Code nur nicht mehr selbst.

Warum wir das erzählen, statt es zu verstecken

Wir hätten diesen Post auch mit vier Stockfotos von "Architekten" schreiben können. Tun wir nicht, weil die ehrliche Version die interessantere ist: Eine Plattform, die behauptet, dass Agenten echte Betriebssoftware führen können, ist glaubwürdiger, wenn das Führungsteam, das die Firma führt, selbst der Beweis dafür ist – und ehrlicher, wenn sie offen damit umgeht, wo das Gesetz heute noch eine menschliche Unterschrift verlangt.

Mehr zum Team – dann mit Gesichtern – folgt bald.

Der Ausgangspunkt

Telesherpa ist eine ontologiebasierte Plattform mit Wurzeln in der Feldservice-Verwaltung. Ihre Prämisse: die meisten operativen Anwendungen bestehen aus denselben wenigen beweglichen Teilen — typisierte Objekte, Formulare, Dokumente, Benachrichtigungen, mobiler Zugriff — die pro Branche neu konfiguriert statt neu gebaut werden. Autovermietung ist eine solche Branche, und alles von der Reservierung bis zum Fahrzeugschadensbericht ist als erster Workflow geeignet.

Bemerkenswert ist nicht der Workflow. Bemerkenswert ist, dass nichts davon einen Menschen brauchte, damit es überhaupt existiert — nicht das Konto, das es gebaut hat, nicht die Objekte, auf denen es arbeitet, nicht das Formular, nicht das Dokument.

Niemand hat einen Browser geöffnet, um dem Agenten ein Konto zu geben

register() legt das Konto an, activate() löst den siebenstelligen Code im Postfach ein, login() tauscht die Client-Zugangsdaten gegen ein Bearer-Token. auth_status sagt im Klartext, ob das Token gültig ist und wie viel von der Plattform sichtbar ist. Nichts davon lief in einem Browser, und nichts davon war ein Service-Konto, das die IT ausgehändigt hätte — der Agent hat sich selbst onboardet.

Der Agent definierte das Geschäft, bevor er das Formular definierte

Ein Formular braucht etwas, worüber es ein Formular ist. Bevor "Schadensbericht" eine Menge von Feldern sein konnte, die ein Mieter ausfüllt, musste es ein typisiertes Objekt in der Ontologie sein — Property-Definitionen und ein Objekttyp, in einem Scope für diese Autovermietungs-Branche. Dieses Modell war nicht vorhanden; der Agent hat es gebaut, genauso wie er später das Formular gebaut hat. Es gibt keine Naht zwischen "definieren, was ein Schadensbericht ist" und "definieren, wie das Ausfüllen aussieht" — beides ist derselbe Agent, dieselbe Art von Werkzeugaufruf, eine Ebene auseinander.

Dann das Formular, das gebrandete Dokument und die Versand-Aktion

• Das Formular — ein Werkzeugaufruf (onto_formdef_save) definiert jedes Feld, jedes Widget und jede Auswahloption gegen den Objekttyp, den der Agent gerade angelegt hat.
• Das gebrandete Dokument — eine Excel-Vorlage mit ##key##-Platzhaltern, im Gespräch iteriert, nach Feedback überarbeitet, eingebunden.
• Die Versand-Aktion — eine buttons-Property macht aus einer Übermittlung eine E-Mail mit dem erzeugten PDF im Anhang.
• Der Test — der Agent hat das Formular selbst abgeschickt, bevor ein Mensch es sah, und dabei Layout- und Foto-Platzhalter-Probleme vorab gefunden.

Er hat außerdem festgestellt, dass der Vorlagen-Mechanismus nirgends dokumentiert war, und dazu eine Service-Anfrage gestellt, statt sich still auf undokumentiertes Verhalten zu verlassen — derselbe Instinkt, der Schreibzugriff auf das eigene Objektmodell und die Formulare überhaupt erst vertrauenswürdig macht.

Wie "fertig" aussah

Kein Deploy — eine echte Person auf einem echten Telefon, die die PWA öffnet, genau das Formular ausfüllt, das der Agent gerade auf einem Objekttyp definiert hatte, der eine Stunde vorher noch nicht existierte, einen Kratzer fotografiert und auf Senden tippt. Das Foto landete automatisch im erzeugten PDF. In dem Moment, in dem Objektmodell, Formular und Dokument gespeichert waren, waren sie auf jedem Telefon live, das ein Mitarbeiter ohnehin schon bei sich trägt.

Warum das über ein einzelnes Formular hinausgeht

Zieht man das Konkrete ab, bleibt das Muster: Konto → Objektmodell → Formular → gebrandetes Dokument → mobiler Zugriff, jede Ebene als MCP-Werkzeugaufrufe ausgedrückt, die ein Agent aus einem Gespräch heraus ausführen kann. Die Aussage, die man sacken lassen sollte, ist nicht "KI kann eure Formulare ausfüllen" und auch nicht "eure Formulare bauen" — sondern dass der eigene Agent eines Kunden ein komplett neues Stück seines Geschäfts aufbauen kann, Datamodell inklusive, an einem Nachmittag, und die Belegschaft es benutzen kann, bevor dieser Nachmittag vorbei ist.