Angewandte Systeme: unsere Architektur, erprobt im realen Betrieb.
Unsere Forschung beschreibt, wie ein Unternehmen mit koordinierten KI-Agenten arbeiten kann, wobei jede folgenreiche Aktion durch feste Regeln geprüft und von einem Menschen freigegeben wird. In angewandten Systemen bauen wir diese Architektur für den realen Betrieb. Jedes beginnt mit einem operativen Problem, nutzt ein gesteuertes Multi-Agenten-Design und wird an festgelegten Grenzen gemessen. Der Kunde erhält ein funktionierendes System. Wir erhalten Belege dafür, was sich im Produktivbetrieb bewährt und was nicht.
Wenn Sie bereits wissen, welches System Sie brauchen, können wir es direkt abgrenzen. Ein Audit ist nicht erforderlich.
Warum angewandte Arbeit Teil der Forschung ist.
| Framework | Was angewandte Systeme testen |
|---|---|
| AMEA (Architektur) | Ob Agenten echte Arbeit vorbereiten, weiterleiten und prüfen können, mit deterministischen Prüfungen, bevor etwas verbindlich wird |
| AMES (Sicherheit) | Ob Agenten in Geschäftssystemen handeln können, ohne Zugangsdaten zu besitzen, auch bei feindlichen Eingaben |
| AMEG (Governance) | Ob für jede Aktion die Regelkonformität nachgewiesen und sie in einem Prüfpfad festgehalten werden kann |
| AMEE (Ökonomie) | Ob sich Betriebskosten tatsächlich vom Personal hin zur Rechenleistung verlagern, sobald die Koordination automatisiert ist |
Ergebnisse aus der angewandten Arbeit fließen in die Frameworks zurück, einschließlich ihrer genannten Grenzen.
Was wir bauen und was jedes System belegt.
| Kompetenzbereich | Operatives Problem | System und Architektur | Technisch bedeutsam, weil | Belegt | Nachweis |
|---|---|---|---|---|---|
| Gesteuerte Multi-Agenten-Koordination | Arbeit wandert zwischen Menschen, Tools und Prüfungen, und die meisten Kosten stecken in dieser Koordination | Multi-Agenten-Orchestrierung mit typisierten Verträgen, Validierungsschleifen und Freigabe-Routing für folgenreiche Schritte | Der Ausgabe eines Agenten wird nie direkt vertraut: Sie wird validiert, wiederholt und an einen Menschen eskaliert, wenn sie weiterhin fehlschlägt | Das AMEA-Muster: KI bereitet vor, feste Prüfungen verifizieren, ein Mensch gibt frei | MCP-Plattform für agentenbasierten Betrieb; selbstkorrigierende Pipelines; Multi-Agenten-Planung |
| Sicherer Tool-Zugriff für Agenten (MCP) | Agenten brauchen Datenbanken, APIs und Dokumente, dürfen aber nicht die Schlüssel dazu besitzen | Eigene MCP-Server mit typisierten Eingaben und eng begrenzten Berechtigungen. Berechnungen laufen deterministisch in der Datenbank, nicht im Modell | Das Modell sieht nie Zugangsdaten, und Zahlen stammen aus deterministischem Code, nicht aus generiertem Text | Das AMES-Prinzip der Isolation von Zugangsdaten, in funktionierenden Systemen | Datenassistent für das Gesundheitswesen; mehrsprachige Finanz-Workflows |
| Fundierte Wissenssysteme | Antworten aus internen Dokumenten müssen nachvollziehbar und messbar korrekt sein | Hybride Suche aus dichten Vektoren und Schlüsselwörtern, mit angezeigten Quellen und Evaluierung vor dem Start | Die Antwortqualität wird gemessen, nicht angenommen | Dass die Suche einem Evaluierungsstandard genügen kann, bevor sich Menschen darauf verlassen | Suche in Finanzdokumenten; SOP-Assistent; Finanz-Copilot |
| Pipelines für Dokumente, Sprache und Bilder | Unstrukturierte Eingaben (Rechnungen, Anrufe, Bilder) gelangen ungeprüft in den Betrieb | Layoutbewusste Extraktion, Sprecher-Diarisierung und visuelle Inspektion, jeweils gefolgt von einer Validierung | Fälle mit geringer Konfidenz gehen in eine Prüfwarteschlange, und Genauigkeitsgrenzen werden genannt | Wo Automatisierung aufhören und ein Mensch übernehmen sollte | Dokumenten-KI für Rechnungen; Sprecher-Diarisierung; visuelle Fehlererkennung; Sprach-Empfangsassistent |
| Evaluierung und Beobachtbarkeit | KI im Produktivbetrieb läuft oft ohne Messung oder Nachverfolgung | Reproduzierbare containerisierte Evaluierung, Tracing und Anomalieerkennung mit vom Modell entworfenen Ursachenzusammenfassungen | Verhalten lässt sich reproduzieren, vergleichen und prüfen | Die AMEG-Anforderung, dass Aktionen aufgezeichnet und überprüfbar sind | Benchmark-Framework für Agenten; vorausschauende Fehlererkennung |
| Selbst gehostete KI-Infrastruktur | Daten und Kontrolle müssen in der Umgebung des Kunden bleiben | Open-Weight-Modelle auf dedizierten GPU-Servern, modellunabhängige Orchestrierung | Das System läuft ohne Abhängigkeit von einem einzelnen Anbieter | Operative Unabhängigkeit als Designeigenschaft. Siehe Open-Source-KI | ERP/CRM-Assistent auf selbst gehosteten Modellen |
| AdTech: autonomes Clearing in einem Live-Umfeld | Werbeentscheidungen in Echtzeit fallen in Maschinengeschwindigkeit, und es geht um Geld | Die Architektur hinter der angewandten Clearing-Studie und fünf KI-Plugins im AdTech-Produktivbetrieb | Es ist ein Produktivumfeld, in dem die Prüfung mit Maschinengeschwindigkeit mithalten muss | AMEA in einem Umfeld, in dem es bereits läuft. Der Benchmark der Studie ist eine synthetische Arbeitslast | Angewandte Clearing-Studie; reviveadservermod.com |
Angewendet auf Branchen-Workflows wie Schadenbearbeitung, Forderungsmanagement, Underwriting und Fallbearbeitung auf unseren Branchenseiten. Gebaut von unserem Engineering-Team und unserem Umsetzungsnetzwerk; Kundennamen und Zahlen bleiben vertraulich.
Design-Invarianten: bei jedem System gleich.
- KI bereitet vor, feste Prüfungen verifizieren, ein Mensch gibt frei, sobald etwas folgenreich ist. Siehe AMEA.
- Agenten besitzen nie Zugangsdaten für Zahlungen oder Kernsysteme. Siehe AMES.
- Jede Aktion wird protokolliert und in einem Prüfpfad festgehalten. Siehe AMEG.
- Modellunabhängig und selbst hostbar, damit Sie nicht an einen Anbieter gebunden sind.
Drei Wege, mit unserer Technologie zu arbeiten.
| Wenn Sie … | Beginnen Sie mit |
|---|---|
| wissen, welches System gebaut werden soll | Einem angewandten System (diese Seite) |
| wissen wollen, wo sich KI auszahlt, bevor gebaut wird | Der kostenlosen Diagnose, dann dem Audit |
| zuerst einen Workflow im Produktivbetrieb erproben wollen | Einem Pilot |
Abgegrenzt, in Etappen gebaut, übergeben.
| Schritt | Was passiert |
|---|---|
| 01 Umfang | Ein kurzes Gespräch, dann ein schriftlicher Umfang: was das System tut, was es niemals tun darf, wie Erfolg gemessen wird und der Preis. |
| 02 Bau in Etappen | Funktionierende Demos in jeder Etappe, damit Sie Fortschritte früh sehen und die Richtung ändern können. |
| 03 Prüfen | Tests, Qualitätsprüfungen der KI-Antworten und Freigabeschranken für alles Folgenreiche, vor dem Start. |
| 04 Übergabe | Code, Dokumentation und eine gemeinsame Durchsicht. Die workflowspezifischen Ergebnisse, die wir für Sie bauen, gehören Ihnen. |
| 05 Betreuung | Optionale Betreuung oder eine fortlaufende Engineering-Partnerschaft nach dem Start. |
Drei Wege, mit uns zu arbeiten.
| Modell | Ideal für | Preise |
|---|---|---|
| Projekt mit festem Umfang | Ein klar definiertes KI-System | Festpreis, im schriftlichen Umfang vereinbart |
| Fortlaufende Engineering-Partnerschaft | Eine Reihe von Systemen auf derselben Architektur | Monatliche Gebühr für eine vereinbarte Kapazität |
| Pilot | Einen Workflow erproben, bevor er breiter ausgerollt wird | Ab 5.200 € / 6.000 $. Siehe Leistungen. |
Projekte werden nach einem Scoping-Gespräch angeboten. Wir veröffentlichen keine Tagessätze.
Zeigt ein Projekt eine größere operative Chance, ist das Operational Leverage Audit der naheliegende nächste Schritt, aber es ist nie Pflicht.
Häufig gestellte Fragen
Warum übernimmt ein Forschungslabor Kundenprojekte?
Weil sich die Frameworks im realen Betrieb bewähren müssen. Angewandte Systeme testen die Architektur unter realen Bedingungen, und was wir dabei lernen, fließt in die Forschung zurück. Kunden erhalten ein gesteuertes, funktionierendes System.
Müssen wir zuerst die Diagnose oder das Audit machen?
Nein. Wenn Sie wissen, was gebaut werden soll, können wir es direkt als Projekt abgrenzen.
Wem gehört der Code?
Die workflowspezifischen Ergebnisse, die wir für Sie bauen, gehören Ihnen. Unsere bereits bestehenden Frameworks und Werkzeuge behalten wir. Die genauen Bedingungen stehen im schriftlichen Umfang.
Welche KI-Modelle nutzen Sie?
Wir sind modellunabhängig: Frontier-Modelle, kleinere Modelle oder selbst gehostete Open-Weight-Modelle, je nach Aufgabe gewählt.
Kann es auf unseren eigenen Servern laufen?
Ja. Der gesamte Stack ist durchgängig selbst hostbar.
Bauen Sie auch allgemeine Websites oder mobile Apps?
Nein. Secular Labs baut ausschließlich KI-native Systeme. Allgemeine Softwareentwicklung übernimmt unser Schwesterunternehmen DJAX unter djaxtech.com.
Wie gestalten Sie Ihre Preise?
Nach einem kurzen Scoping-Gespräch senden wir Ihnen einen schriftlichen Umfang mit Festpreis oder eine monatliche Gebühr für fortlaufende Arbeit.