Une alternative à HumanLayer pour les approbations d’agents

La version courte

HumanLayer a commencé comme un SDK qui permettait aux agents de demander l’avis d’une personne avant d’agir : require_approval pour verrouiller une fonction, human_as_tool pour poser une question. Aujourd’hui, HumanLayer développe un IDE pour agents de code, et le SDK d’approbations n’a pas eu de version depuis juin 2025. Si vous en dépendez encore, Run it by couvre les deux mêmes schémas, et la personne qui répond n’a besoin de rien d’autre qu’un lien.

Vérifié sur les pages de HumanLayer en novembre 2026. Nous n’avons trouvé aucun avis officiel d’abandon ; vérifiez auprès de HumanLayer avant de vous appuyer sur notre lecture.

Ce qui a changé chez HumanLayer

• humanlayer.dev décrit désormais un IDE et un cloud multijoueur pour exécuter Claude Code, Codex et d’autres agents de code.
• La dernière version du paquet humanlayer sur PyPI est la 0.7.9, de juin 2025.
• La documentation des approbations n’est plus sur le site, et le dépôt contient maintenant le nouveau produit.

C’est un choix sensé pour HumanLayer, et si vous supervisez des agents de code en équipe, leur nouveau produit est fait pour ça. Mais il laisse sans SDK les agents qui ont besoin de l’accord d’une personne.

Les mêmes schémas dans Run it by

• Verrouiller une action (require_approval) : créez une demande avec mode: "approval", le motif et les personnes qui décident. N’agissez que si le verdict est approved.
• Poser une question (human_as_tool) : créez une demande avec mode: "form" et un JSON Schema pour la réponse. Elle revient validée selon ce schéma.
• Recevoir la réponse : un webhook signé, getStatus avec une attente allant jusqu’à 25 secondes, ou, via MCP avec Builder et Pro, une notification dès que quelqu’un répond.

Exemple

Un petit require_approval en Python via l’API REST. Il attend dans l’appel ; en production, préférez le 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 et expired renvoient tous deux False : le silence ne devient donc jamais un remboursement.

Ce qui est différent

• Les approbateurs n’ont besoin ni de Slack ni d’un compte. Chaque personne nommée reçoit son propre lien par e-mail, ou vous transmettez vous-même le lien, y compris dans Slack.
• Plusieurs approbateurs avec une règle (any, all, majority ou un nombre), un code par e-mail facultatif pour chaque personne, et une expiration qui se termine en expired.
• Il n’y a pas de décorateur pour envelopper vos fonctions ; vous appelez l’API ou les outils MCP. Si vous comptiez sur des approbations sous forme de messages Slack avec boutons, Run it by ne fait pas cela.

Pour un panorama plus large des options, voir Run it by vs outils d’approbation.