kontakt

ende

Staff Engineer AI & Backend @ Hygraph

Dino Omanovićstaff engineerfür ki-plattformen, agenten-runtimes, mcp-server, durable workflows, verteilte backends, graphql im großen stil

Ich baue seit rund 14 Jahren Backends. Bei Hygraph arbeite ich gerade an KI: einem MCP-Server, dem Service, auf dem unsere Agenten laufen, und allem, was dazwischen liegt. Meistens in Go und TypeScript.

woran ich arbeite👋sag hallo
  • 14+ Jahre Backend
  • Go & TypeScript
  • AI Labs @ Hygraph
  • Bonn
Porträt von Dino Omanović

Idee. Experiment. Software.

Am meisten Spaß macht mir der Moment, in dem aus einer Idee etwas wird, das in Produktion läuft. Mit KI ist das spannender geworden. Einen Demo-Agenten baut man an einem Nachmittag. Bis einer zuverlässig mit echten Kundendaten arbeitet, dauert es deutlich länger.

Damit verbringe ich gerade die meiste Zeit. Davor waren es viele Jahre GraphQL-APIs, Postgres und große E-Commerce-Plattformen, und das mag ich nach wie vor.

AI & Backend Engineer

Agenten, MCP-Tools und die Go- und TypeScript-Services, auf denen sie laufen. Viel Code schreibe ich immer noch selbst.

Forward Deployed Engineer

Nah an Kunden. Vom ersten Gespräch bis zum fertigen Feature in Produktion, und danach kümmere ich mich auch darum.

Architekt

Entscheiden, wo die Grenzen zwischen Services liegen, und wie man schrittweise dorthin kommt.

Tech Lead

Engineers coachen und Produkt und Technik helfen, sich auf das Nächste zu einigen.

KI & Agenten
Ich habe den MCP-Server von Hygraph gebaut und einen guten Teil der Agenten-Plattform dahinter. Inzwischen gehören auch Custom Agents dazu, die Kunden selbst einrichten.
Lang laufende Arbeit
Agenten rufen langsame und manchmal unzuverlässige APIs auf. Dafür nutze ich Temporal, damit Retries, Abbrüche und Neustarts an einer Stelle gelöst sind.
Daten & APIs
Viel GraphQL, SQL und Postgres über die Jahre, zuletzt Vektorsuche mit pgvector. Migrationen rolle ich am liebsten in kleinen Schritten aus.
Führung
Zwei Jahre habe ich das Core-Team bei Hygraph geleitet. Heute arbeite ich teamübergreifend als Staff Engineer: Design-Reviews, Rollout-Pläne und Mentoring.

so baue ich agenten_

Ungefähr das passiert, wenn auf der Plattform, an der ich arbeite, ein Agent läuft. Der Großteil meiner Arbeit steckt in den Schritten rund um den Modellaufruf.

  1. 01 start()

    läuft

    Ein Workflow-Schritt ändert sich, ein Webhook kommt rein oder jemand klickt im Editor auf „ausführen“.

  2. 02 queue()

    Temporal übernimmt. Jeder Agent hat einen Koordinator mit einer festen Zahl an Slots, damit ein großer Batch den LLM-Provider nicht überrennt.

  3. 03 think()

    Das Modell arbeitet mit MCP-Tools, aber nur mit denen, die für genau diesen Eintrag Sinn ergeben. Veröffentlichen gehört nicht dazu.

  4. 04 check()

    Vor dem Schreiben fragt der Agent, ob gerade jemand den Eintrag bearbeitet. Wenn ja, hält er sich zurück.

  5. 05 review()

    Alles, was ein Lauf geändert hat, landet in einer einzigen Version. Ein Mensch schaut drauf und entscheidet, ob sie live geht.

ausgewählte arbeit_

Dinge, die ich in den letzten Jahren geleitet oder geprägt habe, meistens bei Hygraph. Was ich gebaut habe, ist nur die halbe Geschichte, deshalb steht auf jeder Karte auch die Entscheidung dahinter. Keins davon war ein Soloprojekt.

01

Eine MCP-Schnittstelle für KI-Clients

KI-Clients brauchten einen sicheren Weg in Kundenprojekte, statt einer neuen Integration für jeden Anwendungsfall. Ich habe den MCP-Server in Go aufgesetzt und die Regeln für neue Tools festgelegt: authentifiziert, auf ein Projekt begrenzt, validierte Eingaben und Fehlermeldungen, mit denen ein Modell etwas anfangen kann. Content-, Schema- und Migrations-Tools kamen danach auf demselben Vertrag dazu.

entscheidung

Ein gemeinsamer Tool-Vertrag statt Integrationen pro Feature. Das bringt mehr Hebel, aber jedes Tool wird Teil der Sicherheitsgrenze der Plattform. Validierung ist also Pflicht.

  • Go
  • MCP
  • Auth
02

Robuste Ausführung für Agenten

Agenten rufen langsame LLM-APIs auf und müssen Deployments und Neustarts überstehen, mit einfachem Request/Response klappt das nicht. Ich habe den Agenten-Service auf Temporal aufgesetzt und die Muster für Orchestrierung und Recovery festgelegt: ein Koordinator pro Agent, begrenzte Parallelität, Retries und Abbruch. Spätere Agenten nutzen genau diese Muster, statt eigene zu erfinden.

entscheidung

Temporal als neue Abhängigkeit in Kauf nehmen, dafür bekommen wir robuste Retries, Queueing und Einblick, die wir sonst schlechter selbst gebaut hätten.

  • Temporal
  • AWS
  • Go
03

Custom Agents, denen man vertrauen kann

Agenten, die Kunden selbst konfigurieren, bringen nur etwas, wenn man ihnen vertraut. Ich habe zuerst die Grenze definiert und sie dann über vier Services gebaut: Agenten-Konfiguration, Tool-Loop, Content-Versionierung und die Review-Oberfläche im Editor.

entscheidung

Ein Agent darf nur den Eintrag ändern, auf dem er gestartet wurde, und nichts veröffentlichen. Alle Änderungen eines Laufs werden zu einer Version, die ein Mensch prüft.

  • Agenten
  • MCP
  • Versionierung
04

Agenten vs. Menschen im Editor

Agenten sollen nicht in einen Eintrag schreiben, an dem gerade jemand arbeitet. Mein erster Entwurf hat dafür direkt das Redis des Editors aus dem Agenten-Service gelesen. Ich habe umgeschwenkt auf eine kleine API des Editor-Teams, damit das Team, dem die Daten gehören, auch entscheidet, was sie bedeuten.

entscheidung

Bei Timeouts offen scheitern, damit ein Editor-Ausfall nicht alle Agenten stoppt. Erst im Shadow-Mode laufen lassen und schauen, was blockiert worden wäre, bevor es scharf geschaltet wird.

  • Temporal
  • Redis
  • Rollouts
05

Vektorfelder im CMS

Ein neuer Feldtyp muss in Datenbank, Migrationen, GraphQL-Schema, SQL-Übersetzung und Editor dasselbe bedeuten. Ich habe die Arbeit in sieben einzelne Teile geschnitten, damit jede Schicht für sich reviewt und hinter einem Flag ausgeliefert werden konnte.

entscheidung

Den Trade-off zwischen exakter und approximativer Suche für Nutzer sichtbar machen, statt ihn hinter einem Index zu verstecken, der still Treffer verpassen kann.

  • pgvector
  • GraphQL
  • Aurora
06

Leitung der Core-GraphQL-Plattform

Zwei Jahre technische Ausrichtung für das Team hinter Hygraphs globaler GraphQL-API, zwischen Performance, Zuverlässigkeit und API-Stabilität. Dazu gehörten Edge-Caching mit feinerer Invalidierung, der Umzug auf Aurora und der Aufbau unserer On-Call- und Incident-Routinen.

entscheidung

Riskante Infrastruktur Region für Region umstellen, mit Monitoring vorab, statt alles auf einmal umzulegen.

  • GraphQL
  • Fastly
  • Aurora

werdegang

2012 als Azubi angefangen, unterwegs Go lieben gelernt und jetzt bei KI gelandet.

Hygraph

Remote · 2021 – heute

  1. Staff Engineer AI & Backend

    2025 – heutejetzt

    MCP-Server, Agenten-Runtime auf Temporal, Vektorsuche und die Infrastruktur darunter.

  2. Staff Engineer Backend & Infrastructure

    2024 – 2025

    Content-Suche mit Berechtigungen, Autorisierung für Workflows, Autoscaling und Observability-Kosten im Griff behalten.

  3. Engineering Lead · Core

    2022 – 2024

    Leitung des Teams hinter der GraphQL-API. Edge-Caching, Aurora, On-Call und viel Coaching.

  4. Engineering Lead · Developer Experience

    2021 – 2022

    Wiederverwendbare Content-Komponenten über Datenmodell, API und Editor, während das Team schnell gewachsen ist.

  5. Senior Backend Engineer

    2021

    Schema-Generierung umgebaut, sodass jedes Projekt nur noch ein gecachtes GraphQL-Schema braucht.

TheyDo

Amsterdam · Remote · 2024

  1. Staff Engineer

    2024

    Große Mengen Kundenforschung importieren und mit LLMs Insights und Customer Journeys daraus ziehen.

Qvest Digital

Deutschland · 2012 – 2021

  1. IT Consultant & Systems Architect

    2020 – 2021

    Architekturgruppe für die E-Commerce-Plattform eines großen Autoherstellers.

  2. Product Owner & Systems Architect

    2018 – 2020

    Ansprechpartner des Kunden für zwei bis drei Teams, Prioritäten in technische Arbeit übersetzt.

  3. Entwickler → Systems Architect

    2012 – 2018

    Go- und Java-Microservices für große Onlineshops. Go intern so lange unterrichtet, bis es alle benutzt haben.

technologie_

Ich lerne gerne Neues, aber ein paar Technologien machen mir besonders viel Spaß.

übersicht

Über die Jahre habe ich in verschiedensten Projekten gearbeitet und viele Technologien schätzen gelernt.

  • Go
  • TypeScript
  • Node.js
  • MCP
  • Temporal
  • LLM tool loops
  • Agents
  • RAG
  • pgvector
  • Embeddings
  • PostgreSQL
  • Aurora
  • Redis
  • GraphQL
  • SQL
  • OPA
  • AWS
  • ECS/Fargate
  • SQS
  • Fastly
  • Pulumi
  • OpenTelemetry
  • Distributed tracing
  • Rust
  • Java
  • Kafka
  • gRPC
  • Docker
  • Kubernetes
  • CI/CD
  • Load testing
  • Event-driven
  • Microservices

talks

Mir macht es Spaß, meine Erfahrungen zu teilen und darüber zu diskutieren.

neu2026

Building an AI Knowledge Base with MCP

Talk

neu2025

Building an AI Agent with TypeScript and MCP

Hygraph Livestream

2022

Choosing a GraphQL Provider

GraphQL Conf

The state of Kafka and Go
Why Go?
Database bottleneck
Microservice quality
Reactive Go
Serverless Go

kurz gesagt_

Die schnelle Version, für Recruiter, Kunden und alle, die nur kurz drüberschauen.

Wer ist Dino Omanović?

Dino Omanović ist Staff Engineer für KI- und Backend-Systeme und lebt in Bonn. Seit 2021 arbeitet er bei Hygraph, davor bei TheyDo und neun Jahre bei Qvest Digital.

Worauf ist er spezialisiert?

KI-Agenten-Plattformen, MCP-Server, robuste Workflows mit Temporal, GraphQL-APIs und PostgreSQL, meistens in Go und TypeScript. Er hat sowohl selbst entwickelt als auch technisch geführt.

Welche Rollen übernimmt er?

Staff Engineering für KI und Backend, Forward Deployed Engineering nah am Kunden, teamübergreifende Architektur und Tech-Lead-Rollen.

Arbeitet er remote?

Ja. Seit 2021 komplett remote aus Bonn (MEZ), auf Deutsch und Englisch.

Wie erreiche ich ihn?

Am einfachsten per Nachricht auf LinkedIn. Seinen Code gibt es auf GitHub.