Zum Inhalt springen
megapromotingLassen Sie uns sprechen
Produkte Taskin

Organizarea muncii Dezvoltare & demonstrații

Was wir festgelegt haben. Wer weitermacht. Was als Nächstes kommt.

Taskin untersucht die Umwandlung von Gesprächen und Projektkontext in Verpflichtungen, Prioritäten und Arbeitsschritte. Ziel ist es, die Verbindung zwischen einer Aufgabe und dem Gespräch, aus dem sie hervorgegangen ist, zu erhalten.

  1. 1Discuție și context
  2. 2Sarcini propuse
  3. 3Angajamente confirmate
Schemă explicativă ·Taskin

Taskin

Von der Information zur erledigten Arbeit.

01

Context

Wir führen die relevanten autorisierten Quellen für das Projekt zusammen.

02

Angajamente

Wir identifizieren die Entscheidungen und To-dos zur Prüfung durch das Team.

03

Continuitate

Wir organisieren die Zuständigkeiten und die Verfolgung der bestätigten Schritte.

Wo es nützlich wird.

Projekte

Die Rekonstruktion von Entscheidungen und Prioritäten, ohne den Kontext zu verlieren.

Întâlniri

Aufgabenvorschläge aus Gesprächen, vor der Nutzung überprüft.

Operațiuni

Eine Richtung für die Koordination zwischen Menschen und KI-Agenten.

Die Funktionen und Verbindungen sind in Entwicklung. Wir gehen nicht davon aus, dass jede automatisch extrahierte Entscheidung korrekt oder genehmigt ist.

Taskin im Detail

Was Sie mit diesem Projekt tun können.

Taskin ist ein Arbeitsboard mit einer Besonderheit: Es wartet nicht darauf, dass Sie Aufgaben eingeben. Es liest, was bereits passiert ist — Anrufe, E-Mails, Kalender, Nachrichten, Commits, Arbeitssitzungen — und schlägt vor, was getan werden sollte, zusammen mit dem Beleg, aus dem der Vorschlag entstanden ist.

Die Unterscheidung, die es aufbaut, ist die zwischen dem, was beobachtet wurde, und dem, was entschieden wurde. Eine automatisch vorgeschlagene Aufgabe wird nicht zu einer Verpflichtung, bis ein Mensch den Verantwortlichen, die Frist und die Formulierung bestätigt. Diese Regel ist kein Interface-Versprechen, sondern eine in der Datenbank verankerte Einschränkung: Ein Agent kann eine Aufgabe nicht abschließen, und jede Schreiboperation, die eine Aufgabe abschließt, muss angeben, wer sie angefordert hat. Eine Schreiboperation ohne Namen wird abgelehnt.

Wir nutzen es selbst. Fast alles Interessante daran ist entstanden, weil uns bei der eigenen Unternehmensführung etwas Konkretes fehlte, und die Kommentare im Code zitieren reale Produktionszahlen und datierte Vorfälle — einschließlich eines, bei dem eine tägliche Routine elf Tage hintereinander geschwiegen hat, ohne dass es jemand bemerkte.

01

Ein vollständiges Board, kein Experiment

50 Routen über 49 Seiten: Teams, Zyklen, Projekte, Aufgaben, Inbox, Roadmap, Tagesplan, Kunden mit Akte und Verlauf, wiederkehrende Ausgaben, Rechnungsstellung, Zeiterfassung und Arbeitssitzungen, Leistungen, interner Chat, Verwaltung und Mitglieder. Die Datenbank hat 90 Tabellen, aufgebaut aus 81 Migrationen.

02

Der Sammler: 21 Schleifen, die die Realität auf das Board bringen

Auf dem Server geplante Routinen, keine Timer im Prozess — denn ein Timer geht bei jedem Redeploy verloren. Jeder Lauf geht durch einen Wrapper, der ein Protokoll schreibt und selbst eine HTTP-200-Antwort als Fehler behandelt, wenn sie eine Fehlerliste trägt, mit Alarm auf Telegram. Der Wrapper existiert, weil zuvor ein Befehl, der stillschweigend fehlschlug, das tägliche Briefing elf Tage lang lahmgelegt hat.

03

MCP-Server: dieselbe Warteschlange für Menschen und für Agenten

14 Tools über HTTP — Lesen (Auflisten, Suchen, meine Warteschlange, Warteschlange der Agenten, Board-Zusammenfassung, Menschen, Agenten, Projekte) und Schreiben (Erstellen, Aktualisieren, Zuweisen, Verschieben, Kommentar). Jedes Zugangstoken ist mit einem realen Profil verknüpft, daher vermerkt die Aktivität auf dem Board, wer sie angefordert hat. Ein KI-Agent und ein Kollege arbeiten mit derselben Liste, nach denselben Regeln.

04

Echte Integrationen, beim Namen genannt

Telegram, als eigener Bot mit dauerhaftem Zuhören, einschließlich Transkription von Sprachnachrichten. Vier Mailboxen (drei Gmail und eine Microsoft 365), ausschließlich im Lesemodus gelesen. Google Kalender. Telefonanrufe, über SIP-Trunk, einschließlich vom Board ausgelöster Erinnerungsanrufe. Obsidian. LinkedIn. Die Modelle laufen über ein eigenes OpenAI-kompatibles Gateway, und die Ausführungs-Engine der Agenten verwendet eine Werkzeugschleife über OpenRouter.

05

Die Regel, die Agenten nicht umgehen können

„Ein Agent schließt eine Aufgabe nicht ab“ ist eine Funktion in der Datenbank, kein Satz in einer Werkzeugbeschreibung. Sie ist dort gelandet, weil die erste Version nicht funktionierte: Sie identifizierte den Akteur auf eine Weise, die für einen automatisierten Dienst leer ausfiel, also wurde die Regel nirgendwo angewendet. Jetzt wird der Akteur aus drei aufeinanderfolgenden Quellen aufgelöst, und wenn er nicht bestimmt werden kann, wird die Anfrage abgelehnt.

Daten und Funktionsweise

Was in das System eingeht. Was geprüft werden muss.

Isolierung pro Organisation, auf Zeilenebene überprüft
Alle 90 Tabellen haben aktivierte Zeilenebenen-Zugriffssteuerung, unter 171 Richtlinien. Die interne Regel ist schriftlich und ohne Ausnahmen: Eine neue Tabelle bedeutet eine Zugriffsrichtlinie dafür. Die Rollenhierarchie reicht von Super Admin über Admin, Mitglied und Mitarbeiter.
Die Quellen werden gelesen, nicht übernommen
Die Postfächer sind standardmäßig im Lesemodus verbunden, nicht durch Konfiguration. Arbeits­sitzungen und Git-Aktivitäten werden vom Computer der Person gelesen, nicht vom Server. Was auf dem Board landet, ist eine Spur mit Rückverknüpfung zur Quelle, nicht eine Kopie der Korrespondenz.
Die Daten liegen auf eigener Infrastruktur
Supabase, von uns auf einer Azure-Maschine gehostet, nicht Supabase Cloud — Postgres, Kong, Auth, Realtime und Storage in Docker Compose. Die Datenbankadresse ist ein Pfad auf der eigenen Domain. Migrationen werden manuell und absichtlich angewendet: Es gibt keinen automatischen Schritt, der das Produktionsschema berührt.
Was ein Sprachmodell sieht
Die Schleifen, die zusammenfassen, verknüpfen und beurteilen, senden Inhalt an Modelle. Vier von neun internen Schleifen deaktivieren sich selbst mit einer expliziten Meldung im Protokoll, wenn ihnen die Anmeldedaten fehlen — also stoppt das Fehlen eines Schlüssels den Ablauf, statt ihn halb laufen zu lassen.

Von der Erkundung zur Implementierung

Wie wir ein Projekt mit Taskin vorbereiten.

01

Wir beginnen mit einer einzigen Quelle und einem einzigen Projekt

Wir verbinden nicht alles. Eine Quelle — normalerweise E-Mail oder Telegram — und ein echtes Projekt, damit auf echten Daten sichtbar wird, was das System vorschlägt und wie viel von dem, was es vorschlägt, nützlich ist.

02

Wir vergleichen die Vorschläge mit den tatsächlichen Entscheidungen

Die Periode, in der das System vorschlägt und das Team nur bestätigt oder ablehnt, ist diejenige, die zeigt, ob es sich lohnt fortzufahren. Ein abgelehnter Vorschlag ist genauso informativ wie ein angenommener.

03

Wir legen die Regeln für Abschluss und Zuweisung fest

Wer was schließen kann, was eine Frist bedeutet und was mit einer Aufgabe ohne Verantwortlichen geschieht. Hier wird auch entschieden, ob Agenten auf das Board schreiben dürfen und unter welchen Bedingungen.

04

Wir installieren auf der vereinbarten Infrastruktur

Die Lieferung erfolgt per rsync auf eine Maschine, nicht in einen Container: die Oberfläche als statische Verzeichnisse, bereitgestellt von nginx, der Collector und der MCP-Server als systemd-Dienste. Die Gesundheitsprüfung vergleicht das bereitgestellte Paket mit dem gebauten und rollt zurück, wenn sie nicht übereinstimmen.

Fragen, die sich lohnen, geklärt zu werden.

Ist es ein fertiges Produkt oder eine Demonstration?

Es läuft in Produktion und ist das Board, an dem wir unser Unternehmen führen. Die Zahlen: 566 Commits, der letzte am 4. September 2026; 81 Migrationen, die 90 Tabellen erzeugen; 171 Row-Level-Access-Policies; 563 automatische Testfälle in 38 Dateien; 21 geplante Routinen auf dem Server plus 9 Schleifen im Prozess; 14 MCP-Werkzeuge; 35 Endpoints auf dem Collector. Was es nicht ist: ein Self-Service-Dienst. Es gibt keinen Button, mit dem ein externes Team es selbst starten kann — es wird installiert.

Entscheidet es automatisch, wer arbeitet?

Nein, und die Einschränkung steht in der Datenbank, nicht in der Oberfläche. Eine Guard-Funktion verhindert, dass ein Agent eine Aufgabe abschließt, und jede Schreiboperation, die eine abschließen würde, muss den Akteur deklarieren; wenn der Akteur nicht bestimmt werden kann, wird die Anfrage abgelehnt. Es lohnt sich auch zu sagen, warum die Regel so aussieht: Die erste Version identifizierte den Akteur über eine Funktion, die für einen automatischen Dienst leer zurückgab, also griff sie nirgends. Ein eigener Audit fand das, und die Migration, die es behoben hat, erklärt im Kommentar genau, was nicht funktionierte.

Womit verbindet es sich konkret?

Tatsächlich, mit Code und mit geplanter Routine: Telegram (eigener Bot, permanentes Zuhören, Transkription von Sprachnachrichten), vier E-Mail-Postfächer — drei Gmail und eines Microsoft 365 — nur lesend, Google Calendar, Telefonate über einen SIP-Trunk, Obsidian, LinkedIn sowie Arbeits­sitzungen und Git-Aktivität, gelesen vom Rechner der Person. Die Modelle laufen über ein eigenes, OpenAI-kompatibles Gateway; die Ausführungs-Engine der Agenten läuft auf OpenRouter. Was NICHT verbunden ist, obwohl unsere Integrationsseite es anzeigt: Slack, GitHub, Jira, Notion, Figma, Zapier, Dropbox, Google Drive, Microsoft Teams, GitLab, Outlook. Wir haben im Code gesucht und es gibt keine einzige Zeile für eines davon. Diese Seite ist ein Marketing-Raster und muss korrigiert werden.

Gibt es eine WhatsApp-Integration?

Nein, trotz des Namens eines Bildschirms in der App. Dieser Bildschirm ist in Wirklichkeit die Kopplung eines Geräts per QR-Code, in dem Stil, an den die Leute von WhatsApp Web gewöhnt sind — daher kommt der Name. Es gibt keinen einzigen Aufruf an irgendeine WhatsApp-API. Mehr noch: Dieser Ablauf wird nicht genutzt, und seine Tabellen sind leer, was sogar die Migration feststellt, die ihre Berechtigungen überarbeitet hat.

Wie steht es mit der Sicherheit, jenseits von Aussagen?

Das Nützliche ist nicht, dass wir Access-Policies haben, sondern dass wir die Lücken gefunden und sie eine nach der anderen repariert haben, wobei jede Migration erklärt, was nicht funktionierte. Ein eigener Audit aus August entdeckte, dass alle drei Zäune für Agenten inert waren. Ein anderer Guard erwies sich als fail-open — die Prüfung wurde komplett übersprungen, nicht abgelehnt — und wurde auf fail-closed umgestellt. Das dritte Problem war subtil und allgemein: In Postgres ist eine neue Funktion standardmäßig für alle ausführbar, also schränkte die explizite Vergabe von Rechten nichts ein; in Produktion wurde geprüft, dass ein anonymer Schlüssel im Funktionskörper ankam, dann wurde das Standardrecht widerrufen. Auf Repository-Ebene weist ein Guard direkte Pushes auf den Hauptzweig zurück und blockiert Secret-Dateien, weil ein privates Repository auf einem persönlichen Konto keinen Branch-Schutz von GitHub haben kann.

Was ist nicht fertig?

Drei Dinge, die wir lieber offen sagen. Die generierten Typen für die Datenbank sind seit Januar veraltet und enthalten Tabellen aus einem völlig nicht verwandten Projekt, was 101 erzwungene Typkonvertierungen in 26 Dateien erzwungen hat — es funktioniert, verliert aber genau dort die Compile-Time-Prüfung, wo sie nützlich wäre. Der Stilprüfer meldet 161 geerbte Fehler und blockiert die Auslieferung nicht. Und 36 Tests werden in der Continuous Integration übersprungen, weil sie einen Modellschlüssel brauchen, der dort nicht existiert. Keines davon stoppt das Produkt; alle drei sind echte Schuld.

Wie wird es installiert und wie sicher ist die Lieferung?

Per rsync, nicht als Container: Die Oberfläche landet in einem statischen Verzeichnis, das von nginx bereitgestellt wird, der Collector und der MCP-Server laufen als systemd-Dienste. Die Continuous Integration führt die Tests aus und baut; die Auslieferung startet nur, wenn diese auf dem Hauptzweig bestanden haben, über einen eigenen Executor, der genau zwei Skripte ausführen darf und sonst nichts. Jede externe Aktion in der Pipeline ist auf ihren vollständigen Fingerabdruck fixiert, nicht auf ein Tag, nach der Kompromittierung einer beliebten Action im März 2026. Die Gesundheitsprüfung liest, auf welches Paket die bereitgestellte Seite verweist, und rollt zurück, wenn es nicht das frische ist — eine Regel, die nach einem echten Vorfall vom 3. September 2026 geschrieben wurde. Die Datenbankmigrationen bleiben absichtlich manuell.

Beispiel zur Veranschaulichung

Ein Telefongespräch wird zu einer Aufgabe mit beigefügtem Nachweis

Ein Nutzungsszenario, ohne Kundendaten oder zugeordnete kommerzielle Ergebnisse.

Ausgangssituation

Ein Anruf endet mit einem Versprechen. Niemand schreibt es irgendwo auf, und eine Woche später erinnert sich niemand mehr daran, weder was versprochen wurde noch wem.

Wie es funktioniert

Der Anruf kommt per geplanter Routine ins Board, als Spur mit Rückverweis auf die Quelle. Eine Schleife verknüpft ihn mit der richtigen Kundenakte und schlägt eine Aufgabe mit Verantwortlichem und Frist vor. Der Vorschlag bleibt ein Vorschlag: Der Guard in der Datenbank erlaubt es einem Agenten nicht, ihn abzuschließen, und die Schreiboperation, die ihn abschließen würde, muss angeben, wer ihn angefordert hat.

Rezultatul

Die Aufgabe erscheint mit dem Kontext, aus dem sie hervorgegangen ist und der beigefügt ist, sodass ein Kollege, der nicht im Anruf war, verstehen kann, was zu tun ist, ohne das Gespräch neu zusammenzusetzen. Ein Mensch bestätigt die verantwortliche Person, die Frist und die Formulierung — oder lehnt den Vorschlag ab, was ebenso informativ ist.

Ce este necesar:Sursa trebuie conectată efectiv, cu acces autorizat, și trebuie să existe un acord al echipei asupra a ce înseamnă o sarcină atribuită. Sistemul nu presupune consimțământul nimănui.

Möglichkeiten der Zusammenarbeit

Taskin, im Kontext Ihrer Organisation.

Interne Abläufe und Informationen

Verknüpfung autorisierter Quellen, Organisation der Informationen und Überprüfung der Aktionen durch das Team, mit separatem Zugriff nach Rollen.

Private Unternehmen

Wir definieren einen Pilot rund um einen realen Prozess: Nutzer, Daten, Integrationen, Kosten und Abnahmekriterien. Die Erweiterung erfolgt nach der Bewertung des Ergebnisses.

Institutionen und staatliche Unternehmen

Wir legen die Anforderungen an Zugänglichkeit, Hosting, Datenschutz und Interoperabilität fest. Jede Verbindung mit AGE- oder STISC-Diensten erfordert die Validierung der Berechtigung, des Zugriffs und der Genehmigungen.

Dies sind Anpassungsszenarien, keine Aussagen über bestehende Verträge oder Partnerschaften. Die vorgeschlagenen Funktionen werden im Arbeitsbereich des Projekts bestätigt.

Discută un pilot

Teil eines Ökosystems.

Was sollte bei Ihnen besser laufen?

Erzählen Sie uns von Ihrem Prozess. Gemeinsam legen wir fest, was sich zu bauen lohnt, was wir anbinden können und wie wir das Ergebnis prüfen.

Lassen Sie uns sprechen