API-Design für KI-Agenten: Leitfaden zur Agent Experience (AX)

Solange wir APIs bauen, haben wir sie für Entwickler geschrieben, die in einem Tab die Dokumentation offen haben und im anderen ein Terminal. Schlug eine Anfrage fehl, las ein Mensch die Fehlermeldung, schlug in der Dokumentation nach, fand das Problem und korrigierte den Aufruf.

Dieser Mensch sitzt immer seltener davor. Ein KI-Agent ruft Ihre API auf, liest die Antwort und entscheidet selbst über den nächsten Schritt, in einer Schleife. Ihre Fehlermeldung liest niemand mehr beim Debuggen. Sie geht direkt als nächste Eingabe zurück an ein Modell. Ist die Antwort vage, rät der Agent. Rät er falsch, versucht er es erneut. Ist die Wiederholung nicht sicher, zahlt Ihr Kunde doppelt.

Dieser Beitrag behandelt das Engineering für genau diesen Leser: was sich in diesem Monat geändert hat, warum jede Antwort, die Sie senden, jetzt Teil eines Prompts ist, und sechs konkrete Muster mit Code, damit ein System gut funktioniert, wenn der Client ein Agent ist.

Was hat sich am 7. Oktober geändert?

Am 7. Oktober 2026 hat OpenAI eine Funktion namens Intelligent UI eingeführt, zusammen mit einem neuen GPT-6-Modell in ChatGPT. Wie TechCrunch berichtete, können Antworten jetzt antippbare Schaltflächen enthalten, einen Rechner für eine bestimmte Aufgabe, interaktive Diagramme und bearbeitbare Grafiken. Zu OpenAIs Beispielen gehörten ein Rechner für persönliche Ersparnisse und eine Karte für eine mehrtägige Wanderung. Zuerst erhielten es die bezahlten Tarife, Free- und Go-Nutzer am nächsten Tag. OpenAI-Produktmanager Aarush Selvan sagte dazu: “ChatGPT has predominantly been a text-based interface”, also: ChatGPT war bisher vor allem eine textbasierte Oberfläche.

Das ist Generative UI. Google Research beschreibt sie als Fähigkeit, bei der ein KI-Modell “not only content but an entire user experience” erzeugt, also nicht nur Inhalte, sondern ein ganzes Nutzungserlebnis. Google hat sie im November 2025 in der Gemini-App und im KI-Modus der Google-Suche eingeführt.

Schon zuvor, auf der DevDay 2026, hatte OpenAI angekündigt, dass seine Agents API jetzt Computer Use unterstützt, also Anwendungen Software über deren grafische Oberfläche bedienen lässt. Außerdem schlug OpenAI eine Spezifikation namens MCP Events vor, mit der Automatisierungen starten, sobald in einer verbundenen Anwendung etwas passiert.

Für Entwickler ist die Schlussfolgerung einfach. Der Assistent wird zur Oberfläche, und die Arbeit dahinter erledigen Agenten, die Systeme wie Ihres aufrufen. Den Bildschirm, den Sie gestaltet haben, sieht womöglich niemand. Ihre API, Ihre Fehlermeldungen und Ihre Daten dagegen schon.

Von DX zu AX

Netlifys CEO und Mitgründer Mathias Biilmann hat den Begriff Agent Experience am 28. Januar 2025 in einem Beitrag eingeführt und als “the holistic experience AI agents will have as the user of a product or platform” definiert, also das gesamte Erlebnis, das KI-Agenten als Nutzer eines Produkts oder einer Plattform haben. Netlify zieht die Grenze einfach: Bei DX geht es um die Menschen, die auf einer Plattform aufbauen, bei AX um die KI-Agenten, die diese Menschen losschicken, um für sie zu handeln.

	Developer Experience (DX)	Agent Experience (AX)
Wer Ihre Antwort liest	Ein Entwickler, einmal, beim Debuggen	Ein Modell, jedes Mal, in einer Schleife
Was bei einem vagen Fehler passiert	Der Entwickler öffnet die Dokumentation	Der Agent rät, wiederholt oder gibt auf
Was bei einem Timeout passiert	Der Entwickler prüft vor dem Wiederholen	Der Agent wiederholt oft einfach
Wo die Dokumentation steht	Auf einer Doku-Website	In der Tool-Beschreibung und in der Antwort selbst

Jede Antwort ist der nächste Prompt des Agenten

Ein Agent arbeitet in einer Schleife: eine Aktion wählen, ein Tool aufrufen, das Ergebnis lesen, erneut entscheiden. Was Ihr System zurückgibt, wird Teil des Kontexts des Modells für die nächste Entscheidung. Damit wird Antwortdesign zu einer Form von Prompt-Design.

Die Entwickler dieser Systeme sagen das direkt. In seinem Leitfaden zum Schreiben von Tools für Agenten rät Anthropic: “you can prompt-engineer your error responses to clearly communicate specific and actionable improvements, rather than opaque error codes or tracebacks”, also Fehlerantworten so zu formulieren, dass sie konkrete, umsetzbare Verbesserungen vermitteln statt undurchsichtiger Fehlercodes oder Tracebacks. Die Spezifikation des Model Context Protocol (MCP) unterscheidet zwei Arten von Fehlern: Protokollfehler, die Modelle “less likely to be able to fix” sind, und Fehler bei der Tool-Ausführung, die “actionable feedback that language models can use to self-correct and retry with adjusted parameters” enthalten, also umsetzbares Feedback, mit dem sich Sprachmodelle selbst korrigieren und mit angepassten Parametern neu versuchen können. Validierungsfehler bei Eingaben, etwa ein Datum im falschen Format, zählt sie zur zweiten Art.

Hier ist ein Beispiel. Jeder Fehler darin ist einer, auf den wir Agenten regelmäßig stoßen sehen. Ein Agent soll diesen Freitag um 19 Uhr einen Tisch für vier reservieren und eine eventuelle Anzahlung zahlen.

1. Er sendet das Datum als 17.10.2026. Die API antwortet 400 Bad Request mit dem Inhalt Invalid request. Der Agent probiert zwei weitere Formate, bevor eines funktioniert.
2. Der Bezahlaufruf läuft in ein Timeout. Der Agent kann nicht erkennen, ob die Anzahlung durchging, also ruft er erneut auf. Zwei Anzahlungen werden abgebucht.
3. Er braucht die Öffnungszeiten. Die gibt es nur als Foto der Speisekarte. Der Agent rät.
4. Er wird ausgebremst. Die API antwortet 429 ohne Hinweis, wann er wiederkommen soll. Der Agent versucht es pausenlos, gibt dann auf und reserviert woanders.

Keiner dieser Fehler ist ein Problem des Modells. Jeder ist eine technische Entscheidung auf der Serverseite, und für jeden gibt es eine bekannte Lösung.

1. Fehlermeldungen, die dem Agenten den Weg zeigen

Die Grundlage ist RFC 9457, Problem Details for HTTP APIs, veröffentlicht im Juli 2023. Der Standard definiert ein JSON-Fehlerformat mit dem Medientyp application/problem+json, den Feldern type, title, status, detail und instance und erlaubt Erweiterungsfelder. Sein eigenes Beispiel ergänzt ein errors-Array mit einem pointer auf jedes ungültige Feld.

Vorher:

HTTP/1.1 400 Bad Request
Content-Type: text/plain

Invalid request

Nachher:

HTTP/1.1 422 Unprocessable Content
Content-Type: application/problem+json

{
  "type": "https://api.example.com/problems/validation-error",
  "title": "Your request is not valid.",
  "status": 422,
  "detail": "1 field failed validation. Fix it and send the request again.",
  "errors": [
    {
      "pointer": "#/date",
      "detail": "Must be an ISO 8601 date (YYYY-MM-DD), for example 2026-10-17. Received \"17/10/2026\"."
    }
  ]
}

Warum die zweite Version für einen Agenten funktioniert:

• Sie zeigt auf das Feld. pointer sagt genau, welche Eingabe falsch ist.
• Sie nennt das erwartete Format mit Beispiel. Modelle übernehmen Beispiele gut.
• Sie gibt wieder, was ankam. Der Agent sieht seinen eigenen Fehler, ohne raten zu müssen.
• Sie sagt, was als Nächstes zu tun ist. “Fix it and send the request again” ist eine Anweisung, nicht nur ein Status.
• Sie verrät nichts Internes. Keine Stacktraces, die niemandem helfen und Ihre Interna offenlegen.

Ein praktischer Test: Lesen Sie jede Fehlermeldung und fragen Sie, ob ein neuer Entwickler den Aufruf allein anhand der Meldung reparieren könnte, ohne Dokumentation. Wenn nicht, kann es ein Agent wahrscheinlich auch nicht.

2. Sichere Wiederholungen mit Idempotenzschlüsseln

Agenten wiederholen Anfragen. Ein Timeout ist mehrdeutig: Die Anfrage kann fehlgeschlagen sein, oder sie war erfolgreich und nur die Antwort ging verloren. Ein sorgfältiger Entwickler prüft vor dem Wiederholen. Ein Agent versucht es oft einfach erneut. Bei Lesezugriffen ist das harmlos. Bei einer Zahlung oder Buchung ist es eine doppelte Abbuchung.

Die Lösung ist ein Idempotenzschlüssel: Der Client erzeugt pro Vorgang einen eindeutigen Schlüssel und sendet ihn bei jedem Versuch mit, und der Server stellt sicher, dass der Vorgang pro Schlüssel nur einmal läuft. Die API von Stripe ist ein bekanntes Beispiel. Ihre Dokumentation beschreibt Idempotenz als “safely retrying requests without accidentally performing the same operation twice”, also sichere Wiederholungen, ohne versehentlich denselben Vorgang zweimal auszuführen. Die IETF hat an einem Standard-HTTP-Header Idempotency-Key gearbeitet. Der letzte Entwurf, draft-07 vom Oktober 2025, ist inzwischen abgelaufen, ohne ein RFC zu werden, aber seine Regeln sind eine nützliche Referenz:

Situation	Statuscode im Entwurf
Der Schlüssel fehlt bei einem Endpunkt, der ihn verlangt	400
Der Schlüssel wird mit einem anderen Anfrageinhalt wiederverwendet	422
Eine Wiederholung kommt an, während die ursprüngliche Anfrage noch läuft	409

Der Entwurf empfiehlt eine UUID oder einen ähnlichen Zufallswert als Schlüssel und sagt, dass der Server festlegen soll, wie lange Schlüssel aufbewahrt werden, und dies dokumentieren soll. Er erlaubt außerdem einen Idempotenz-Fingerprint, also einen Hash der Anfrage, um einen mit anderem Inhalt wiederverwendeten Schlüssel zu erkennen.

Hier eine vereinfachte Version für eine Express-API mit PostgreSQL. Die Tabelle speichert eine Zeile pro Client und Schlüssel:

CREATE TABLE idempotency_keys (
  client_id    text        NOT NULL,
  key          text        NOT NULL,
  fingerprint  text        NOT NULL,   -- hash of the request body
  status_code  int,                    -- NULL while the request is in flight
  response     jsonb,
  created_at   timestamptz NOT NULL DEFAULT now(),
  PRIMARY KEY (client_id, key)
);

Und der Wrapper um jeden Endpunkt, der Zustand ändert:

import { createHash } from "node:crypto";
import type { Request, Response } from "express";
import { db } from "./db"; // a node-postgres Pool

type Result = { status: number; body: unknown };

function problem(res: Response, status: number, title: string, detail: string) {
  return res.status(status).type("application/problem+json").json({ title, status, detail });
}

export async function withIdempotency(
  req: Request,
  res: Response,
  clientId: string,
  run: () => Promise<Result>,
) {
  const key = req.get("Idempotency-Key");
  if (!key) {
    return problem(res, 400, "Missing Idempotency-Key",
      "Send an Idempotency-Key header with a new UUID for each booking, and reuse it when you retry.");
  }

  const fingerprint = createHash("sha256").update(JSON.stringify(req.body)).digest("hex");

  // Claim the key atomically. Of two identical concurrent requests, only one can insert the row.
  const claim = await db.query(
    `INSERT INTO idempotency_keys (client_id, key, fingerprint)
     VALUES ($1, $2, $3) ON CONFLICT DO NOTHING`,
    [clientId, key, fingerprint],
  );

  if (claim.rowCount === 0) {
    const { rows: [saved] } = await db.query(
      `SELECT fingerprint, status_code, response FROM idempotency_keys
       WHERE client_id = $1 AND key = $2`,
      [clientId, key],
    );
    if (saved.fingerprint !== fingerprint) {
      return problem(res, 422, "Idempotency-Key reused",
        "This key was already used for a different request. Generate a new key for a new booking.");
    }
    if (saved.status_code === null) {
      res.set("Retry-After", "2");
      return problem(res, 409, "Request still in progress",
        "The first request with this key is still running. Retry with the same key in 2 seconds.");
    }
    return res.status(saved.status_code).json(saved.response); // replay the original result
  }

  let result: Result;
  try {
    result = await run(); // runs once per key
  } catch (err) {
    // The operation failed: release the claim so the client can retry with the same key.
    await db.query(`DELETE FROM idempotency_keys WHERE client_id = $1 AND key = $2`, [clientId, key]);
    throw err;
  }

  // The operation succeeded: store the result so every retry gets the same answer.
  await db.query(
    `UPDATE idempotency_keys SET status_code = $3, response = $4
     WHERE client_id = $1 AND key = $2`,
    [clientId, key, result.status, JSON.stringify(result.body)],
  );
  return res.status(result.status).json(result.body);
}

Der Code ist der einfache Teil. Die Entscheidungen drumherum sind die Stellen, an denen Systeme scheitern:

• Schlüssel pro Client trennen. Zwei Clients können zufällig denselben Schlüssel erzeugen. Der zusammengesetzte Primärschlüssel verhindert, dass ein Client die Antwort eines anderen erhält.
• Festlegen, was ein Fehler bedeutet. Das Beispiel oben gibt den Schlüssel frei, wenn der Vorgang eine Ausnahme wirft, sodass eine Wiederholung ihn erneut ausführt. Das ist nur sicher, wenn ein fehlgeschlagener Lauf nichts hinterlassen hat. Kann er halb abgeschlossen sein, behalten Sie den Schlüssel und geben den Fehler bei Wiederholungen erneut zurück.
• Den Schlüssel weiterreichen. Stürzt der Server ab, nachdem die Karte belastet wurde, aber bevor das Ergebnis gespeichert ist, läuft eine Wiederholung erneut. Wenn das nachgelagerte System es unterstützt, geben Sie auch ihm einen Idempotenzschlüssel mit. Stripe zum Beispiel akzeptiert einen bei seinen POST-Anfragen, sodass auch der Zahlungsanbieter eine doppelte Abbuchung ablehnt.
• Vor dem Hashen normalisieren. Dasselbe JSON mit anderer Reihenfolge der Felder ergibt einen anderen Hash. Hashen Sie eine normalisierte Form des Inhalts oder nur die Felder, die den Vorgang bestimmen.
• Schlüssel ablaufen lassen und das dokumentieren. Stripes API v1 zum Beispiel kann Schlüssel entfernen, sobald sie mindestens 24 Stunden alt sind. Welches Zeitfenster Sie auch wählen, dokumentieren Sie es und räumen Sie Ansprüche auf, die ein abgestürzter Prozess offen gelassen hat.

3. Rate Limits, die sagen, wann es weitergeht

RFC 6585 definiert 429 Too Many Requests für Rate Limiting. Der Standard sagt: “SHOULD include details explaining the condition, and MAY include a Retry-After header”. Die Antwort soll also den Grund erklären und kann einen Retry-After-Header enthalten. RFC 9110 definiert Retry-After entweder als HTTP-Datum oder als Anzahl Sekunden, zum Beispiel Retry-After: 120.

Ein Mensch sieht eine 429 und wartet. Ein Agent ohne Hinweis versucht es vielleicht sofort erneut, verbraucht sein eigenes Budget und Ihres und gibt dann auf. Sagen Sie ihm genau, wann er wiederkommen soll:

HTTP/1.1 429 Too Many Requests
Retry-After: 30
Content-Type: application/problem+json

{
  "type": "https://api.example.com/problems/rate-limited",
  "title": "Too many requests",
  "status": 429,
  "detail": "The limit is 60 booking requests per minute per API key. Wait 30 seconds, then retry. Earlier retries will also be rejected."
}

4. Fakten maschinenlesbar veröffentlichen

Öffnungszeiten auf einem Foto, Preise in einem PDF und Richtlinien in einem Bild sind für Menschen in Ordnung und für Maschinen schwer. Legen Sie die Fakten, von denen Entscheidungen abhängen, als Text und strukturierte Daten ab.

Für Unternehmen mit Standort bietet schema.org das passende Vokabular, und Google führt openingHoursSpecification in seiner Dokumentation zu strukturierten Daten für lokale Unternehmen als empfohlene Eigenschaft:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Restaurant",
  "name": "Example Bistro",
  "servesCuisine": "French",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "Marktstraße 12",
    "addressLocality": "Berlin",
    "postalCode": "10115",
    "addressCountry": "DE"
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Tuesday", "Wednesday", "Thursday"],
      "opens": "17:00",
      "closes": "22:00"
    },
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Friday", "Saturday"],
      "opens": "17:00",
      "closes": "23:30"
    }
  ]
}
</script>

Der technische Punkt ist die Quelle. Erzeugen Sie dieses Markup aus derselben Datenbank, die Ihr Buchungssystem liest, nicht von Hand. Öffnungszeiten, die an drei Stellen kopiert sind, laufen auseinander, und ein Agent, der die veraltete Kopie liest, sagt Ihrem Kunden mit voller Überzeugung das Falsche.

Eine Anmerkung zu llms.txt, einer Datei, die Jeremy Howard im September 2024 vorgeschlagen hat, um Sprachmodellen eine einfache Zusammenfassung einer Website zu geben. Laut Google können Sie sie für die Google-Suche ignorieren, und es ist in Ordnung, eine für andere Dienste zu pflegen, die sie nutzen. Sie ist schnell angelegt, ersetzt aber weder strukturierte Daten noch eine gute API.

5. Ein Eingang für Agenten: Tools statt Seiten

Ein Agent kann eine Website über ihre Bildschirme bedienen, aber ein eigens gebautes Tool ist schneller und deutlich zuverlässiger. MCP ist der offene Standard dafür. Das Projekt beschreibt es als “an open-source standard for connecting AI applications to external systems”, also einen Open-Source-Standard, um KI-Anwendungen mit externen Systemen zu verbinden, und vergleicht es mit einem USB-C-Anschluss für KI-Anwendungen. Eine Tool-Definition hat einen name, eine description, ein inputSchema in JSON Schema und optionale annotations:

{
  "name": "create_booking",
  "title": "Book a table",
  "description": "Book a table at Example Bistro. Call check_availability first. Times are local to Berlin. Party size is 1 to 8; for larger groups call request_callback. Parties of 6 or more pay a deposit of 10 EUR per person. Reuse the same idempotency_key when you retry, or the guest may be charged twice.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "date": { "type": "string", "format": "date", "description": "ISO 8601 date, for example 2026-10-17" },
      "time": { "type": "string", "pattern": "^([01][0-9]|2[0-3]):[0-5][0-9]$", "description": "24-hour local time, for example 19:00" },
      "party_size": { "type": "integer", "minimum": 1, "maximum": 8 },
      "idempotency_key": { "type": "string", "description": "A UUID you create once per booking and reuse on every retry" }
    },
    "required": ["date", "time", "party_size", "idempotency_key"],
    "additionalProperties": false
  },
  "annotations": {
    "readOnlyHint": false,
    "destructiveHint": false,
    "idempotentHint": true,
    "openWorldHint": false
  }
}

Einiges in dieser Definition ist bewusst so gewählt:

• Die Beschreibung ist Dokumentation. Anthropic rät: “think of how you would describe your tool to a new hire on your team”, also das Tool so zu beschreiben, wie man es einer neuen Kollegin oder einem neuen Kollegen im Team erklären würde. Reihenfolge der Aufrufe, Grenzen, Geld und die Wiederholungsregel gehören hierher, denn das liest das Modell, bevor es handelt.
• Das Schema dokumentiert, der Server validiert. JSON Schema sagt dem Agenten, welche Form er senden soll. Ihr Server muss trotzdem jede Eingabe prüfen, und die MCP-Spezifikation verlangt, dass Server alle Tool-Eingaben validieren.
• Annotations müssen stimmen. Im MCP-Schema bedeutet idempotentHint, dass wiederholte Aufrufe mit denselben Argumenten keine zusätzliche Wirkung haben. Das ist nur ehrlich, weil idempotency_key Teil der Argumente ist und der Server ihn durchsetzt. Die Spezifikation sagt außerdem, dass Clients Annotations als nicht vertrauenswürdig behandeln müssen, sofern sie nicht von einem vertrauenswürdigen Server stammen. Sie beschreiben Ihr Tool, sie schützen es nicht.

Schlägt ein Aufruf aus einem Grund fehl, den der Agent beheben kann, geben Sie einen Fehler bei der Tool-Ausführung mit isError: true zurück und eine Nachricht, die auf den nächsten Schritt zeigt:

{
  "content": [
    {
      "type": "text",
      "text": "No table for 4 on 2026-10-17 at 19:00. Free times that evening: 18:00 and 20:30. Call create_booking again with one of these times, or call request_callback to reach the restaurant."
    }
  ],
  "isError": true
}

Diese eine Nachricht macht aus einer Sackgasse den nächsten Schritt.

6. An einen Menschen übergeben, wenn der Agent nicht weiterkommt

Kein Agent wird jede Aufgabe abschließen. Manche Anfragen brauchen Urteilsvermögen, eine Ausnahme oder einen Anruf. Gestalten Sie diesen Weg bewusst, statt den Agenten stillschweigend scheitern zu lassen. Eine Anfrage, die einen Menschen braucht, muss nicht abgelehnt werden. Sie kann zur Prüfung angenommen werden, mit dem weiteren Weg in der Antwort:

HTTP/1.1 202 Accepted
Content-Type: application/json

{
  "status": "pending_review",
  "detail": "Groups larger than 8 are confirmed by the restaurant team. Your request has been passed on. Share the link with the guest.",
  "handoff": {
    "case_id": "c_48213",
    "url": "https://example.com/requests/c_48213",
    "expected_response": "within 2 hours, between 10:00 and 22:00 local time"
  }
}

RFC 9110 definiert 202 Accepted für eine Anfrage, die zur Verarbeitung angenommen, aber noch nicht abgeschlossen wurde. Genau das ist hier der Fall.

Eine saubere Übergabe macht aus einem verlorenen Kunden einen verspäteten und gibt dem Agenten etwas Wahres, das er der Person sagen kann, für die er arbeitet.

Checkliste: Agent Experience für Ihre API prüfen

1. Jeder Fehler nutzt ein strukturiertes Format wie application/problem+json und nennt das Feld, das erwartete Format, ein Beispiel und den nächsten Schritt.
2. Kein Fehler verrät Interna. Keine Stacktraces, keine rohen Datenbankmeldungen.
3. Jeder zustandsändernde Endpunkt akzeptiert einen Idempotenzschlüssel, pro Client getrennt, mit geprüftem Fingerprint und dokumentierter Lebensdauer.
4. Schlüssel werden weitergereicht an Zahlungsanbieter und andere Systeme, die sie unterstützen.
5. Jede 429 enthält Retry-After und einen Satz, der das Limit erklärt.
6. Entscheidungsrelevante Fakten sind maschinenlesbar, erzeugt aus Ihrer zentralen Datenquelle, nicht von Hand kopiert.
7. Tool-Beschreibungen lesen sich wie eine Einarbeitung, mit Reihenfolge der Aufrufe, Grenzen, Geld und Wiederholungsregel.
8. Annotations entsprechen dem Verhalten, und der Server validiert jede Eingabe, egal was das Schema sagt.
9. Es gibt einen Übergabeweg, der eine Vorgangsnummer oder einen Link liefert statt einer Sackgasse.
10. Lassen Sie Ihre wichtigsten Abläufe von einem KI-Agenten durchlaufen, bevor es die Agenten Ihrer Kunden tun.

Die Regel zum Übernehmen

Schreiben Sie jede Antwort so, als würde ein Modell darauf handeln, ohne nachzufragen, denn genau das passiert immer öfter. Reicht die Antwort allein nicht aus, um den richtigen nächsten Schritt sicher zu gehen, verbessern Sie die Antwort.

Wie Incresco hilft

Incresco ist Claude-Partner. Wir entwickeln Web- und Mobile-Anwendungen, Cloud-Systeme, Salesforce-Lösungen, WhatsApp-Erlebnisse und KI-Agenten. Für die Bereitschaft für KI-Agenten prüfen wir Ihre APIs und Kundenabläufe so, wie ein Agent ihnen begegnet: Fehler, Wiederholungen, Grenzen, Daten und Tools. Dann beheben wir, was im Weg steht, und bauen MCP-Server, wo sie sich lohnen. Siehe unsere Leistungen individuelle Plattformentwicklung, Systemintegrationen und KI-Transformation.

Sie fragen sich, wie gut Ihre API funktioniert, wenn der Client ein KI-Agent ist? Sprechen Sie Incresco an und bitten Sie um eine Prüfung Ihrer Agent Experience. Wir gehen Ihre wichtigsten Endpunkte und Abläufe durch und sagen Ihnen, was Sie zuerst beheben sollten.

Häufig gestellte Fragen

Was ist Agent Experience (AX)?

Agent Experience beschreibt, wie gut ein KI-Agent Ihr Produkt im Auftrag eines Menschen entdecken, nutzen und sich von Fehlern erholen kann. Netlifys Mathias Biilmann hat den Begriff im Januar 2025 eingeführt. Technisch läuft es auf klare Fehlermeldungen, sichere Wiederholungen, explizite Grenzen, maschinenlesbare Fakten und gut beschriebene Tools hinaus.

Was ist Generative UI?

Generative UI bedeutet, dass ein KI-Modell die Oberfläche für jede Frage selbst baut, etwa einen Rechner, ein Diagramm oder eine Karte, statt einen vorab gestalteten Bildschirm zu zeigen. Google hat sie im November 2025 in der Gemini-App und der Google-Suche eingeführt, ChatGPTs Intelligent UI folgte am 7. Oktober 2026.

Was ist ein Idempotenzschlüssel?

Ein eindeutiger Wert, den der Client mit einer Anfrage sendet und bei jeder Wiederholung erneut verwendet, damit der Server sicherstellen kann, dass der Vorgang nur einmal läuft. Er verhindert, dass aus einem Timeout und einer Wiederholung eine doppelte Abbuchung oder Buchung wird.

Brauche ich einen MCP-Server?

Nicht immer. Beginnen Sie mit klaren Fehlermeldungen, idempotenten Schreibvorgängen und dokumentierten APIs. Ein MCP-Server lohnt sich, wenn Sie erwarten, dass KI-Assistenten Ihren Dienst regelmäßig nutzen, denn er gibt ihnen Tools mit Beschreibungen und Schemas statt Seiten zum Durchklicken.