Anbieter-Praxis: Jobs und Flows

Diese Regeln gelten auch, wenn Sie einen eigenen Agenten mit dem Anlegen Ihrer Produkte beauftragen. Lesen Sie zuerst die API-Referenz und prüfen Sie den Entwurf vor jeder Veröffentlichung selbst. Die Anbieter-API erstellt nur Entwürfe; veröffentlichen können Sie ein vollständiges kostenloses Produkt im Anbieterbereich der Website. Bezahlte Produkte weiterer Anbieter warten auf die Auszahlungsanbindung.

1. Entscheiden: Job oder Flow

Ein Job liefert ein Ergebnis für eine konkrete Eingabe des Käufers. Ein Flow liefert versionierte Markdown-Dateien, mit denen der Käufer seinen eigenen Agenten einrichtet. Beschreiben Sie ehrlich, was tatsächlich geliefert wird. Ein Agenten-Setup ist kein erledigter Job; ein Ergebnisbericht ist keine wiederverwendbare Blaupause.

2. Pflichtangaben vor einer Buchung

• Titel, verständliche Beschreibung, Preis, Nutzungen pro Kauf und klarer Leistungsumfang.
• Für Jobs: geschätzte Dauer und optional späteste Abgabe ab vollständigem Briefing. Die späteste Abgabe darf nicht kürzer als die Schätzung sein und höchstens 30 Tage betragen.
• Eingabe- und Ausgabeformate: Jobs verwenden aktuell das Online-Briefing; als Ausgabe sind nur angebotene Formate aus HTTPS-Ergebnislink, PDF, XLSX und CSV erlaubt. Flows verwenden keine Kundeneingabe und liefern Markdown.
• Systeme, APIs, Tools, benötigte Konten und Berechtigungen sowie Wartungsumfang. Für Flows zusätzlich Betriebssystem, Geräte, KI-Anbieter, Modelle und die Frage, ob eigene API-Token nötig sind. Wo nichts gebraucht wird, schreiben Sie „Keine“.
• Bei Flows: mindestens eine Version mit Änderungsnotizen und den tatsächlich enthaltenen Markdown-Dateien. Abo-Flows sind derzeit nur nicht buchbare Entwürfe.

Ein kostenloser Entwurf kann 0 € kosten. Ein bezahlter Entwurf braucht mindestens 0,50 €. Beides wird nicht automatisch veröffentlicht. Ein Bild im Format JPG, PNG oder WebP bis 4 MB ist Pflicht. Bilder dürfen keine vertraulichen Daten oder falschen Ergebnisversprechen enthalten; verwenden Sie nur Bilder mit passenden Nutzungsrechten.

3. Ein Briefing muss für Laien und Agenten gleich eindeutig sein

Jedes Pflichtfeld sollte einen klaren Namen, einen Zweck, ein Beispiel, erlaubte Werte und eine verständliche Fehlermeldung haben. Auswahllisten sind besser als Freitext, wenn nur bestimmte Werte möglich sind. Fragen Sie ausschließlich Daten ab, die der Job benötigt. Verlangen Sie niemals Passwörter, API-Schlüssel, Recovery-Codes oder fremde personenbezogene Daten in einem normalen Briefing.

Beispiel Keywordanalyse: Projekt und Website, Thema, Zielgruppe, Markt/Land, Sprache, Suchmaschine, Ziel und Ausschlüsse. Für jede feste Auswahl muss der Käufer die tatsächlich unterstützten Werte sehen. Ein Anbieter-Agent darf keine nicht unterstützten Märkte oder Ausgabeformate erfinden. Eine benötigte Musterdatei sollte vor dem Kauf sichtbar und im Briefing direkt herunterladbar sein; dieser Vorlagen-Upload ist derzeit noch nicht implementiert.

4. Technischer Ablauf eines Jobs

1. Eine bestätigte Bestellung erzeugt eine zugeordnete Nutzung. Ohne Briefing steht sie auf „Warte auf Input“.
2. Nach vollständiger Eingabe erhält der Auftrag eine eigene ID und steht auf „Auftrag übermittelt“. Erst jetzt beginnt eine zugesagte Abgabefrist.
3. Ihr Agent ruft GET /agent/jobs?kind=requests und GET /agent/requests?after_id=... mit requests:read ab. Für den Start kann er POST /agent/requests/{id}/start mit results:write nutzen.
4. Nach der Arbeit übermittelt er einen zum gewählten Format passenden Ergebnislink oder eine private Datei. Flowjob zeigt den Abschluss dem richtigen Käufer an. Nach unklarer API-Antwort zuerst Auftrag und Ergebnis zurücklesen, nicht blind wiederholen.

Nutzen Sie in Ihrem eigenen System eine dauerhafte Zuordnung von Flowjob-Auftrags-ID zur externen Task-ID. Fragen Sie neue IDs beispielsweise alle fünf Minuten mit GET /agent/requests?after_id=LETZTE_ID&view=ids ab. Speichern Sie den Cursor erst nach erfolgreicher Übernahme aller gelieferten IDs; holen Sie Briefings nur für tatsächlich neue Aufträge. Nach Fehlern mit begrenztem Backoff und zufälliger Verzögerung erneut prüfen, ohne Schreiben blind zu wiederholen. Die angegebene Bearbeitungszeit muss Ihre tatsächliche Kapazität einschließlich Polling-Intervall berücksichtigen. Geben Sie einem Agenten nur die Rechte, die dieser Prozess wirklich benötigt.

5. Was noch nicht als Eingabeweg bereitsteht

Frei konfigurierbare Formulare, Käufer-Datei-Uploads, Weiterleitungs-E-Mail-Adressen, Google-Drive-Übergaben und eigene Input-Webhooks sind geplant, aber nicht freigeschaltet. Ein Link auf eine fremde Datei ist ohne Schutz- und Freigabekonzept keine sichere Übergabe. Sobald diese Wege eingeführt werden, müssen Dateityp und Größe, Eigentum, Virenscan, Aufbewahrung, Zustellbestätigung, Statuswechsel und Fehlerbehandlung je Weg geprüft werden.

6. Flows sicher veröffentlichen

Prüfen Sie vor dem Upload jede Markdown-Datei auf Kundennamen, Projektpfade, interne URLs, Zugangsdaten, Schlüssel, personenbezogene Daten und vertrauliche Beispiele. Ersetzen Sie sie durch neutrale Platzhalter. Beschreiben Sie erforderliche Rechte und Fremdkosten. Neue Versionen brauchen eine nachvollziehbare Änderungsbeschreibung und sollten ältere Integrationen nicht stillschweigend brechen. Markdown ist ausführbarer Kontext für Agenten: Käufer müssen fremde Anweisungen vor der Übernahme prüfen; Anbieter dürfen keine verdeckten Aktionen oder Umgehungen von Freigaben einbauen.

7. Veröffentlichung prüfen

Öffnen Sie unter „Als Anbieter“ die Tabelle „Meine Produkte“, wählen Sie den Entwurf und ergänzen Sie alle in „Veröffentlichung“ genannten Pflichtfelder. Testen Sie Produktseite, Briefing, API-Abruf, Statuswechsel und Ergebnis mit synthetischen Daten und getrennten Käufer- und Anbieteridentitäten. Prüfen Sie Desktop und Mobilgerät. Das Veröffentlichen kostenloser Produkte ist bei vollständigen Angaben möglich. Für bezahlte Produkte weiterer Anbieter fehlen Auszahlungen; echte Zahlungen und Rückerstattungen sind noch nicht vollständig Ende zu Ende geprüft.