Deterministischer Code um probabilistische Modelle.
Über 120 Bausteine von KI-Agenten in neun Bereichen, jeder mit seinem klassischen Gegenstück aus der Softwareentwicklung.
Der Grundsatz
Ein KI-Agent ist kein einzelnes Modell, sondern ein Softwaresystem, das ein probabilistisches Modell in eine kontrollierte Ausführungsschleife einbettet.
Das Sprachmodell ist die zentrale probabilistische Entscheidungskomponente im System. Der Code darum herum ist so deterministisch wie möglich gebaut: Er rahmt diese Unberechenbarkeit ein, versorgt sie mit Kontext, prüft ihre Vorschläge und fängt Fehler ab. Dieser Code ist der Harness.
Das Modell schlägt vor, ein Scorer bewertet, der Code entscheidet.
Kontrollfluss & Auslöser
Ereignis- & Zeitauslöser
Agenten nicht nur interaktiv im Chat starten, sondern nach Zeitplan oder als Reaktion auf Ereignisse im System.
Agent Loop
Das Modell in einer Schleife aufrufen, bis das Ziel erreicht ist.
Abbruchbedingung
Aufhören, sobald eine finale Antwort vorliegt oder harte Grenzen (Schritte, Zeit, Budget) erreicht sind.
Prompt Chaining
Feste Abfolge, in der die Ausgabe von Schritt 1 die Eingabe von Schritt 2 ist.
Plan-and-Execute
Das Modell einen strukturierten Arbeitsplan erstellen lassen, den der Code danach Schritt für Schritt ausführt.
Evaluator–Optimizer (Reflexion)
Entwurf → Kritik → Überarbeitung in einer gezielten Schleife, bis ein Qualitätskriterium erfüllt ist.
Routing
Das Modell die Anfrage einordnen lassen; der Code leitet sie an den passenden Ausführungspfad weiter.
Tool Dispatch
Den Tool-Namen aus der Modellantwort der tatsächlichen Funktion im Code zuordnen.
Hooks / Middleware
Code, der automatisch vor und nach jedem Modell- oder Tool-Aufruf läuft (Logging, Validierung, Transformation).
Workflow-Graph
Erlaubte Zustände und Übergänge ausdrücklich im Code festlegen.
Parallelisierung
Mehrere Modell- oder Tool-Aufrufe gleichzeitig starten und ihre Ergebnisse zusammenführen.
Spekulative Ausführung
Wahrscheinlich benötigte Daten vorab laden oder Guardrails parallel prüfen, während das Modell noch generiert.
Orchestrator–Worker
Ein Modell zerlegt die Gesamtaufgabe; spezialisierte Worker bearbeiten die Teilaufgaben.
Streaming & Events
Tokens und Zwischenschritte laufend weitergeben, statt bis zum Ende zu blockieren.
Human-in-the-Loop
Vor kritischen Schritten die Bestätigung eines Menschen verlangen.
Unterbrechung & Abbruch
Eine laufende Schleife sauber beenden, wenn der Nutzer sie stoppt oder neue Informationen liefert.
Time-Travel / Replay
Zu einem früheren Checkpoint zurückspringen, den Kontext anpassen und ab dort neu ausführen.
Rückfragen bei Mehrdeutigkeit
Bei einer mehrdeutigen Anfrage anhalten und den Nutzer fragen, statt zu raten (z. B. über ein Tool ask_user). Der Code erkennt das und pausiert die Schleife.
Tool Choice (erzwungener Aufruf)
tool_choice auf auto, required oder ein bestimmtes Tool setzen, z. B. um im letzten Schritt eine strukturierte Antwort zu erzwingen.
Kontext, Gedächtnis & Tool-Schnittstellen
System Prompt
Grundregeln, Rolle und Grenzen ganz oben im Kontext verankern.
Prompt-Vorlagen
Prompts zur Laufzeit aus festen Bausteinen und Variablen zusammensetzen.
Few-Shot-Beispiele
Gewünschtes Verhalten und Ausgabeformat mit Beispielen im Prompt vorführen.
Tool-Definitionen
Name, Beschreibung und Parameterschema jedes Tools (das Modell sieht nur das – unklare Beschreibungen führen zu schlechten Aufrufen).
Deterministische Tools statt Modellwissen
Rechnen, Datumslogik, Sortieren oder Codeausführung an Tools abgeben, statt das Modell raten zu lassen.
Aufbereitung von Tool-Ausgaben
Zu große Tool-Ausgaben kürzen, filtern oder zusammenfassen, bevor sie das Kontextfenster sprengen.
Kurzzeitgedächtnis
Nachrichtenverlauf und Zwischenschritte durch den laufenden Lauf tragen.
Kontext-Scoping (Isolation)
Jedem Schritt nur genau den Ausschnitt der Daten zeigen, den er braucht.
Kontext-Kompaktierung
Älteren Verlauf kürzen oder zusammenfassen, wenn sich das Kontextfenster füllt.
Langzeitgedächtnis
Wissen über Sitzungen hinweg speichern.
Gedächtnis-Extraktion im Hintergrund
Nach einem Gespräch asynchron die wichtigsten Fakten herausziehen und in eine Datenbank schreiben.
RAG
Vor oder während eines Laufs passende Dokumente aus einer Wissensbasis abrufen.
Dynamisches Laden von Tools (Tool-RAG)
Bei Hunderten von Tools nur die Beschreibungen in den Kontext laden, die für den aktuellen Schritt relevant sind.
Multimodale Vorverarbeitung
PDFs, Bilder oder Audio vor dem Modellaufruf in Text, Tabellen oder Abschnitte umwandeln.
Prompt Caching
Einen unveränderten Prompt-Anfang nicht bei jedem Schritt neu verarbeiten (spart Latenz und Kosten).
Reihenfolge im Kontext
Wichtige Anweisungen an den Anfang oder ans Ende setzen; was in sehr langen Kontexten in der Mitte steht, wird leichter übersehen. Stabile Teile vorn halten, damit das Prompt Caching greift.
Chunking & Indexierung
Dokumente sinnvoll teilen (nach Abschnitten, mit Überlappung und Metadaten wie Quelle und Datum). Schlechte Chunks ergeben schlechtes RAG, egal wie stark das Modell ist.
Hybride Suche & Query Rewriting
Stichwortsuche (z. B. BM25) und Vektorsuche kombinieren, weil Embeddings mit exakten Zeichenketten wie Teilenummern schlecht umgehen. Das Modell Suchanfragen umformulieren oder zerlegen lassen.
Anweisungsmodule (Skills)
Spezielle Anweisungen erst laden, wenn sie gebraucht werden, statt alles in den System Prompt zu packen. Hält den Kontext schlank.
Externes Arbeitsgedächtnis (Notizen & Aufgabenlisten)
Den Agenten Pläne, Fortschritt und Erkenntnisse in Dateien oder eine Aufgabenliste schreiben lassen. Übersteht Kontext-Kompaktierung und sehr lange Läufe.
Validierung von Ein- und Ausgaben (Validierung & Guardrails)
Eingabe-Guardrails
Ungültige, gefährliche oder sensible Eingaben abfangen, bevor das Modell aufgerufen wird.
Constrained Decoding
Ungültige Tokens schon während der Generierung ausschließen.
Strukturierte Ausgaben
Ein typisiertes Datenobjekt erzwingen statt freien Text.
Parsing & Validierung
Modellantworten parsen, Typen und Wertebereiche prüfen und Fehler sauber abfangen.
Ausgabe-Guardrails
Die Antwort auf Inhalts- und Formatregeln prüfen, bevor sie weitergegeben wird.
Grounding & Belege
Vom Modell verlangen, Aussagen mit Quellen-IDs zu belegen; der Code prüft deterministisch, dass Quelle und Zitat existieren.
Deterministisches Nachrechnen
Summen, Prozente oder Daten aus dem Text mit deterministischem Code nachrechnen.
Logprobs / Konfidenzprüfung
Token-Wahrscheinlichkeiten auswerten. Einschränkung: nicht bei jedem Anbieter verfügbar und kein verlässlicher Halluzinationsdetektor (Modelle liegen oft selbstsicher falsch).
LLM-as-Judge
Ein zweites Modell bewertet die Antwort (Einschränkung: selbst probabilistisch!).
Retry mit Feedback
Den Validierungsfehler an das Modell zurückgeben, damit es sich selbst korrigiert.
Mehrfach-Sampling & Abstimmung
Mehrere Antworten erzeugen und die häufigste oder am besten bewertete wählen.
Fallback
Auf ein Ersatzmodell oder eine feste Antwort wechseln, wenn die Wiederholungen erschöpft sind.
Behandlung des Stop-Grunds
Prüfen, warum die Generierung endete (fertig, Tool-Aufruf, Token-Limit, Ablehnung). Abgeschnittene Antworten fortsetzen oder verwerfen und Ablehnungen ausdrücklich behandeln, statt sie als normale Antwort zu nehmen.
Guardrails sind nicht nur if/else. if/else beschreibt den Kontrollfluss; in der Praxis entstehen Guardrails auch über Policy-Engines, Berechtigungsdienste, Schema-Validatoren, Sandboxes oder eigene Klassifikationsmodelle.
Sicherheit & Isolation
Schutz vor Prompt Injection
Nicht vertrauenswürdige externe Daten im Prompt kennzeichnen. Wichtig: Anders als bei SQL Prepared Statements gibt es in LLMs keine garantierte Trennung von Code und Daten. Echten Schutz bieten harte Grenzen für Tool-Berechtigungen im Harness.
Validierung von Tool-Argumenten
Nicht nur prüfen, ob ein Tool erlaubt ist, sondern auch, mit welchen Argumenten es aufgerufen wird (z. B. Dateipfade, Betragsgrenzen, Empfängerdomains).
Ausgabe-Encoding
Modellausgaben als nicht vertrauenswürdige Eingabe behandeln, bevor sie als HTML/Markdown im Browser erscheinen oder in Abfragen eingesetzt werden.
Mandantentrennung im Gedächtnis
Im Datenbank- und RAG-Code strikt durchsetzen, dass Gedächtnis und Dokumente von Nutzer A nie in den Kontext von Nutzer B gelangen.
Identitätsweitergabe (On-Behalf-Of)
Daten- und Tool-Aufrufe mit genau den Rechten des angemeldeten Nutzers ausführen.
Tool-Berechtigungen
Festlegen, welche Tools und Aktionen in welchem Zustand erlaubt sind.
Freigabe vor unumkehrbaren Aktionen
Nie ohne ausdrückliche Freigabe eines Menschen senden, löschen, bezahlen oder veröffentlichen.
Umkehrbare Maskierung personenbezogener Daten
Sensible Daten vor dem Modellaufruf durch Platzhalter ersetzen und danach wiederherstellen.
Umgang mit Secrets
Passwörter und API-Keys nie in den Modellkontext geben; sie erst im Tool-Code einsetzen.
Sandbox
Codeausführung und Dateizugriff vom Host-System abschotten.
Egress-Filter (DLP)
Verhindern, dass ein gekapertes Modell Daten über externe Links, Webhooks oder Bilder abfließen lässt.
Budgets & Rate Limits
Harte Obergrenzen für Kosten und Aufrufe je Lauf und je Mandant durchsetzen.
Audit-Trail
Manipulationssicher festhalten, wer welche schreibende oder unumkehrbare Aktion wann ausgelöst hat.
Autonomiestufen
Je Aufgabe festlegen: read_only, suggest, act_with_approval oder autonomous. Die Stufe nach dem Risiko der Aktion wählen, nicht nach dem Vertrauen ins Modell.
Vertrauensprüfung für Tools & MCP-Server
Tool-Server von Dritten können manipulierte Tool-Beschreibungen oder Ergebnisse liefern. Geprüfte Quellen nutzen, Versionen festschreiben und Tool-Beschreibungen auf Änderungen überwachen.
Datenschutz & Aufbewahrung
Festlegen, welche Daten in Logs, Traces, Checkpoints und Vektorindizes landen, wie lange sie bleiben und wie sie auf Anfrage vollständig gelöscht werden.
Regulatorische Einstufung
Je nach Anwendungsfall bringen Regelwerke wie der EU AI Act Pflichten mit sich (Transparenz, Dokumentation, menschliche Aufsicht). Die Risikoklasse früh klären.
Red Teaming
Gezielt versuchen, den Agenten zu Fehlverhalten zu bringen (Injection, Rechteausweitung, Datenabfluss), bevor es Angreifer tun. Befunde in dauerhafte Eval-Fälle überführen.
Zuverlässigkeit, Betrieb & Lebenszyklus
Prompt-Versionierung
Prompts wie Code versionieren, damit sich Evals, Kennzahlen und Rollbacks einer genauen Revision zuordnen lassen.
Festschreiben der Modellversion
Datierte Modell-Snapshots festschreiben, damit Updates des Anbieters das Verhalten nicht unbemerkt ändern.
Sampling-Parameter
temperature und top_p steuern die Streuung (Hinweis: Selbst temperature=0 ist nicht garantiert deterministisch).
Modell-Kaskade / Tiering
Zuerst ein kleines, schnelles Modell versuchen; nur bei Bedarf an ein größeres eskalieren.
Timeouts
Hängende Modell- oder Tool-Aufrufe sauber abbrechen.
Circuit Breaker & Backoff
Bei API-Ausfällen oder Rate Limits mit Backoff warten oder auf einen zweiten Anbieter umschalten.
Idempotente Tools
Sicherstellen, dass ein wiederholter Tool-Aufruf keine doppelten Nebenwirkungen hat.
Kompensationslogik (Rollback)
Bricht Schritt 4 ab, die Nebenwirkungen der Schritte 1–3 rückgängig machen.
Checkpointing
Lang laufende Workflows nach einem Absturz ab dem letzten abgeschlossenen Schritt fortsetzen.
Antwort-Cache
Für identische Anfragen nicht zweimal bezahlen.
Semantisches Caching
Ähnlich formulierte Fragen über Vektorähnlichkeit cachen. Vorsicht: braucht sehr hohe Schwellen und eine Faktenprüfung, sonst verwechselt der Cache „bis 30. Juni“ und „bis 30. September“.
Logging & Tracing
Nachvollziehen, was der Agent wann getan hat, wie lange es dauerte und warum.
Kostenverfolgung
Token-Verbrauch (Eingabe, Ausgabe, Cache, Reasoning) und Kosten je Lauf erfassen.
Evals
Über realistische Testfälle statistisch messen, ob eine Änderung die Qualität verschlechtert.
Shadow Mode / Canary
Neue Prompts oder Modelle im Hintergrund mit echtem Verkehr testen.
Feedback-Daten fürs Training
Erfolgreiche und korrigierte Läufe sammeln. Der Harness selbst verändert nie Modellgewichte – eine eigene Trainingspipeline (z. B. Fine-Tuning) nutzt diese Daten für künftige Modelle.
Durable Execution
Garantieren, dass ein Lauf über Abstürze, Deployments oder tagelanges Warten hinweg weiterläuft. Baut auf Checkpoints auf.
Reasoning-Budget
Bei Reasoning-Modellen festlegen, wie viel Denkbudget ein Schritt bekommt: viel für schwierige Planung, wenig für Routineschritte. Kostet Tokens und Latenz.
Batch-Verarbeitung
Nicht dringende Aufgaben günstiger über die Batch-APIs der Anbieter verarbeiten.
Qualitätsüberwachung im Betrieb & Drift
Evals prüfen vor dem Release; im Betrieb echte Läufe stichprobenartig bewerten, um Qualitätsdrift oder neue Anfragemuster früh zu erkennen.
Globaler Not-Aus (Kill Switch)
Einen Agenten oder einzelne Mandanten und Tools zentral sofort abschalten, ohne neu zu deployen.
Koordination mehrerer Agenten
Sub-Agent
Eine Teilaufgabe an einen Agenten mit eigenem, isoliertem Kontext abgeben.
Übergabe (Kontexttransfer)
Gespräch und Verantwortung vollständig an einen spezialisierten Agenten übergeben.
Message Passing
Agenten Ergebnisse asynchron über Nachrichten austauschen lassen.
Gemeinsamer Zustand
Mehrere Agenten in einen gemeinsamen Speicher lesen und schreiben lassen.
Sperren auf gemeinsamem Zustand
Verhindern, dass zwei parallele Agenten oder Worker gleichzeitig denselben Lauf oder Datensatz überschreiben (Race Conditions).
Tool- / Agenten-Protokolle (MCP, A2A)
Vereinheitlichen, wie sich Tools und Agenten verbinden, ohne eigens geschriebenen Verbindungscode.
Schutz vor Ping-Pong / Deadlocks
Verhindern, dass Agenten Aufgaben in einer Endlosschleife hin- und herschieben.
Delegation mit minimalen Rechten an Sub-Agenten
Sub-Agenten nur die Rechte geben, die ihre Teilaufgabe braucht, nie mehr, als der Aufrufer selbst hat.
Typisierte Übergaben
Ergebnisse zwischen Agenten oder Phasen als validierte Schemas weitergeben statt als freien Text. Fehler zeigen sich an der Grenze, nicht drei Schritte später. Prüft die Struktur, nicht die inhaltliche Wahrheit.
Scoring als Zwischenschicht (Bewertung & Schwellen)
Scoring schließt die Lücke zwischen unscharfen Modellausgaben und deterministischem Code: Eine weiche Frage wie „Ist das gut genug?“ wird zu einer Zahl, und gewöhnlicher Code entscheidet über if score > threshold. Schon auf der Ebene einzelner Tokens arbeiten Sprachmodelle so: Das Netz vergibt jedem Token deterministisch einen Score (Logits), nur das Ziehen aus dieser Verteilung ist probabilistisch.
Token-Scoring (Logits → Softmax)
Das Netz bewertet jedes mögliche Token; temperature, top_k und top_p formen die Verteilung vor dem Ziehen. Constrained Decoding und Logprobs-Prüfungen setzen genau hier an.
Ähnlichkeits-Scoring (Embeddings)
Die Ähnlichkeit zwischen einer Anfrage und einem Dokument, einer Tool-Beschreibung oder einem Cache-Eintrag als Zahl ausdrücken. Grundlage für RAG, Tool-RAG und semantisches Caching.
Reranking
Ein zweites, genaueres Modell ordnet grobe RAG-Treffer neu, damit nur die besten k in den Kontext gelangen.
Klassifikator-Scores
Wahrscheinlichkeit je Kategorie (Injection, Toxizität, Themen-Routing); der Code blockiert oder leitet ab einer Schwelle um.
Judge-Scores nach Bewertungsraster
Ein LLM-as-Judge vergibt Punkte nach ausdrücklichen Kriterien statt nach vagen Eindrücken. Bleibt probabilistisch, daher eine Stichprobe gegen menschliche Bewertungen prüfen.
Best-of-N-Auswahl
N Antworten erzeugen, bewerten und die beste zurückgeben. Kostet N-mal so viele Tokens.
Eskalation nach Konfidenz
Bei niedrigem Score an ein stärkeres Modell (Kaskade) oder an einen Menschen (Human-in-the-Loop) eskalieren.
Kalibrierung von Schwellen
Schwellen aus Evals an echten Beispielen ableiten statt zu raten. Jede Schwelle wägt falsch Positive gegen falsch Negative ab – wer rät, verschiebt die Unschärfe nur in eine willkürliche Zahl.
Reward-Modell (Training)
KI-Labore bewerten Ausgaben mit Reward-Modellen und verschieben die Gewichte in Richtung höherer Scores (z. B. RLHF). Im eigenen Harness nur relevant, wenn man Modelle selbst feinabstimmt.
Schutz vor Reward Hacking
Modelle optimieren manchmal auf den Score statt auf die Aufgabe (Tests löschen oder abschwächen, Ausgaben fest einprogrammieren, Fehler mit type: ignore verstecken, einem Judge schmeicheln). Gegenmittel: schreibgeschützte Prüfer (ProtectedPaths), Diff-Prüfungen auf Test- und Konfigurationsdateien, zurückgehaltene Tests, mehrere unabhängige Signale (Tests, Typprüfer, Linter), ein isolierter Judge, konkretes Feedback statt einer bloßen Zahl, begrenzte Wiederholungen und ein menschliches Review vor dem Merge.
Paarvergleich
Einen Judge entscheiden lassen, ob A oder B besser ist, statt absolute Noten von 1 bis 10 zu vergeben. Meist stabiler.
Kontrolle von Judge-Bias
Judges bevorzugen oft längere Antworten, die zuerst gezeigte Option oder Ausgaben der eigenen Modellfamilie. Reihenfolge zufällig wählen, Länge berücksichtigen und ein Modell einer anderen Familie als Judge einsetzen.
Wo Scoring in dieser Taxonomie sonst vorkommt: RAG und Tool-RAG (Ähnlichkeit), Routing und Eingabe-Guardrails (Klassifikatoren), LLM-as-Judge, Mehrfach-Sampling & Abstimmung, Logprobs-Prüfungen, Modell-Kaskade, semantisches Caching und Evals (Bestehensquote als Release-Schwelle).
Betrieb mit mehreren Modellen (modellunabhängige Architektur)
Modelle verschiedener Labore reagieren unterschiedlich auf denselben Prompt, bevorzugen andere Formate und haben andere Stärken – auch, weil jedes Labor seine Modelle in einer eigenen Harness-Umgebung trainiert. Grundsatz: gemeinsamer Sicherheitskern, modellspezifische Ränder, Evals als Schiedsrichter. Ein Harness auf dem kleinsten gemeinsamen Nenner verschenkt Fähigkeiten der Modelle; ein Harness, der an ein einziges Modell gebunden ist, erzeugt Lock-in.
Modellunabhängiger Sicherheitskern
Tool-Berechtigungen, Sandboxes, Egress-Filter, Freigaben, Mandantentrennung und Budgets hängen nie vom Modell ab. Ein schwächeres Modell liefert vielleicht schlechtere Antworten, kann aber keinen Schaden anrichten.
Provider-Adapter
Dünne Schicht, die das interne Standardformat in das API-Format jedes Anbieters übersetzt (Tool-Aufrufe, strukturierte Ausgaben, Caching, System Prompt). Der Rest des Codes kennt nur das Standardformat.
Prompt-Profile je Modell
System Prompts, Few-Shot-Beispiele und Tool-Beschreibungen bei Bedarf als versionierte Varianten je Modell pflegen. Was für Modell A am besten funktioniert, kann Modell B verwirren.
Native Funktionen statt Polyfills
Natives Tool Calling, strukturierte Schemas und Prompt Caching nutzen, statt sie mit Prompt-Tricks nachzubauen. Spielt die Stärken aus, auf die das Modell trainiert wurde.
Fähigkeitenmatrix
Im Code festhalten, was jedes Modell kann (Tools, Bildverarbeitung usw.). Der Router filtert die Kandidaten danach.
Graceful Degradation
Fehlt einem Modell eine Funktion, auf eine unterstützte Alternative ausweichen (z. B. Pydantic-Validierung + Retry), statt abzustürzen.
Modellübergreifende Evals
Dieselbe Eval-Suite mit echten Projektaufgaben gegen jedes Kandidatenmodell laufen lassen. Zeigt, welches Modell mit diesem Harness am besten arbeitet und ob eine Prompt-Anpassung für A das Modell B verschlechtert.
Modell-Routing nach Aufgabe
Je Aufgabe das beste Modell nach Evals wählen: ein schnelles für Routineschritte, ein Frontier-Modell für komplexes Schlussfolgern, ein spezialisiertes für Code oder Bilder.
Verwandte Bausteine in dieser Taxonomie: Festschreiben der Modellversion, Shadow Mode / Canary bei Modellwechseln, portable Tool-Protokolle (MCP), einheitliches Logging & Tracing für Modellvergleiche, Modell-Kaskade, Fallback sowie Circuit Breaker mit Umschalten des Anbieters.
Schnittstelle Mensch–Agent (UX & Transparenz)
Auch die Benutzeroberfläche ist deterministischer Code – und oft der Ort, an dem sich entscheidet, ob Freigaben, Korrekturen und Vertrauen in der Praxis funktionieren.
Transparenz über den Fortschritt
Den aktuellen Schritt und die Tool-Aufrufe über Events zeigen, damit Menschen früh eingreifen können und nicht erst am Ende.
Vorschau vor der Ausführung
Geplante Änderungen (Code-Diff, E-Mail-Entwurf, Zahlungsdaten) vor der Ausführung zeigen. Erst das macht eine Freigabe sinnvoll statt zum bloßen Abnicken.
Unsicherheit kommunizieren
Den Agenten Rückfragen stellen (ask_user) oder Annahmen kennzeichnen lassen, statt Vermutungen mit falscher Sicherheit zu präsentieren.
Rückgängig / Rollback
Nutzern einen klaren Weg geben, Aktionen des Agenten zurückzunehmen (technisch über Kompensationslogik oder Versionskontrolle).
Feedback erfassen
Daumen hoch oder runter, Änderungen und Abbrüche erfassen, um Evals, Qualitätsüberwachung und das Data Flywheel zu speisen.
Projekt starten oder weiter skalieren?
Sagen Sie uns, wo Sie stehen und wohin es gehen soll. Wir unterstützen Sie dabei und melden uns persönlich bei Ihnen.
info@appamass.com