Eine Alternative zu HumanLayer für Agenten-Freigaben

Die Kurzfassung

HumanLayer begann als SDK, mit dem Agenten vor einer Aktion einen Menschen fragen konnten: require_approval, um eine Funktion abzusichern, human_as_tool, um eine Frage zu stellen. Heute baut HumanLayer eine IDE für Coding-Agenten, und das Freigabe-SDK hat seit Juni 2025 kein Release mehr bekommen. Wenn du noch davon abhängst, deckt Run it by dieselben zwei Muster ab, und die antwortende Person braucht nichts als einen Link.

Im November 2026 anhand der eigenen Seiten von HumanLayer geprüft. Wir haben keine offizielle Einstellungsankündigung gefunden; frag bei HumanLayer nach, bevor du dich auf unsere Lesart verlässt.

Was sich bei HumanLayer geändert hat

• humanlayer.dev beschreibt jetzt eine Multiplayer-IDE und Cloud, um Claude Code, Codex und andere Coding-Agenten auszuführen.
• Das letzte Release des humanlayer-Pakets auf PyPI ist 0.7.9 vom Juni 2025.
• Die Freigabe-Dokumentation ist nicht mehr auf der Website, und das Repository enthält jetzt das neue Produkt.

Für HumanLayer ist das ein sinnvoller Schritt, und wenn du Coding-Agenten im Team beaufsichtigst, ist das neue Produkt genau dafür gebaut. Es lässt nur Agenten ohne das SDK zurück, die die Zustimmung eines Menschen brauchen.

Dieselben Muster in Run it by

• Eine Aktion absichern (require_approval): Erstelle eine Anfrage mit mode: "approval", dem Grund und den Personen, die entscheiden. Handle nur, wenn die Entscheidung approved lautet.
• Eine Frage stellen (human_as_tool): Erstelle eine Anfrage mit mode: "form" und einem JSON Schema für die Antwort. Sie kommt gegen dieses Schema validiert zurück.
• Die Antwort erhalten: ein signierter Webhook, getStatus mit einer Wartezeit von bis zu 25 Sekunden oder, über MCP bei Builder und Pro, eine Benachrichtigung in dem Moment, in dem jemand antwortet.

Beispiel

Ein kleines require_approval in Python über die REST-API. Es wartet im Aufruf; in Produktion nimm lieber den Webhook.

import os, requests

API = "https://runitby.app/v1/requests"
AUTH = {"Authorization": f"Bearer {os.environ['RUNITBY_API_KEY']}"}

def require_approval(reason, approvers):
    request = requests.post(API, headers=AUTH, json={
        "mode": "approval",
        "title": reason,
        "requester": "The billing agent",
        "audience": {"kind": "named", "recipients": approvers},
        "approval": {"reason": reason, "policy": "any", "verify": "email"},
        "expiresIn": "24h",
        "sendEmail": True,
    }).json()
    while True:
        status = requests.get(
            f"{API}/{request['requestId']}?wait=25", headers=AUTH
        ).json()
        if status["verdict"]:
            return status["verdict"] == "approved"

if require_approval("Refund order #4821, $1,200",
                    [{"name": "Emily Lee", "email": "emily@acme.com"}]):
    issue_refund("4821")

declined und expired geben beide False zurück, Schweigen wird also nie zu einer Erstattung.

Was anders ist

• Freigebende brauchen weder Slack noch ein Konto. Jede namentlich genannte Person bekommt ihren eigenen Link per E-Mail, oder du gibst den Link selbst weiter, auch in Slack.
• Mehrere Freigebende mit einer Regel (any, all, majority oder eine Zahl), ein optionaler E-Mail-Code pro Person und ein Ablauf, der als expired endet.
• Es gibt keinen Decorator, der deine Funktionen umhüllt; du rufst die API oder die MCP-Tools auf. Wenn du dich darauf verlassen hast, dass Freigaben als Slack-Nachrichten mit Buttons ankommen, macht Run it by das nicht.

Einen breiteren Überblick über die Optionen findest du unter Run it by vs Freigabe-Tools.