Table of Contents
- Why I'm Writing This Down
- Quick Comparison
- Best-Practice HITL Implementation
- Orchestration Frameworks
- Dedicated HITL Layers
- No-Code: n8n
- Durable Execution Underneath: Temporal
- Terraform and Ansible: the actual pattern
- Enterprise Vertical Platforms (for completeness)
- Cloud Hyperscaler Managed Agent Services (for completeness)
- What I'd Actually Wire Together
Why I'm Writing This Down
I wanted a full picture of what exists today for "AI agents that can touch real infrastructure, but pause and ask a human before doing anything dangerous." There's a lot of marketing noise around "agentic AI platforms" in 2026, so this is my attempt to separate what's actually a devops-relevant building block from what's a vertical SaaS chatbot product.
I care about a specific set of questions for each solution:
- Can I self-host it, or is it SaaS-only?
- How does the human-in-the-loop (HITL) approval actually work?
- Does it talk to Slack, email, Linear, GitHub, GitLab natively?
- Can it safely gate a
terraform applyor anansible-playbookrun?
Quick Comparison
Same 12 solutions in every table below, one attribute at a time: easier to scan than one wide table.
Self-hosted?
| Solution | Self-hosted |
|---|---|
| LangGraph | Yes (OSS + Enterprise self-host) |
| CrewAI | Yes (OSS) + AMP cloud/on-prem |
| AutoGen / AG2 | Yes (OSS only) |
| Semantic Kernel | Yes (OSS) + Azure managed |
| HumanLayer | SDK is OSS, approval backend hosted |
| Composio (connector layer) | Cloud, limited self-host |
| n8n | Yes (OSS self-hosted or cloud) |
| Temporal | Yes (OSS self-hosted or Cloud) |
| Sierra / Decagon / Moveworks / Glean / Cognigy / Kore.ai / Aisera | No, SaaS only |
| AWS Bedrock AgentCore | No, managed |
| Azure AI Foundry Agent Service | No, managed |
| Vertex AI Agent Builder | No, managed |
Native HITL mechanism
| Solution | Native HITL |
|---|---|
| LangGraph | Yes, core (interrupt()/checkpointer) |
| CrewAI | Yes, human_input flag |
| AutoGen / AG2 | Yes, core (UserProxyAgent) |
| Semantic Kernel | Yes, via planner/filters |
| HumanLayer | Yes, this is the product |
| Composio (connector layer) | N/A (it's a tool bus, not an agent) |
| n8n | Yes, "Wait for approval" node |
| Temporal | Pattern via signals, not built-in |
| Sierra / Decagon / Moveworks / Glean / Cognigy / Kore.ai / Aisera | Yes, built-in approval queues |
| AWS Bedrock AgentCore | Action-group approval hooks |
| Azure AI Foundry Agent Service | Built-in via Logic Apps |
| Vertex AI Agent Builder | Via Cloud Functions hook |
Slack
| Solution | Slack |
|---|---|
| LangGraph | via community bot |
| CrewAI | Native (Enterprise) |
| AutoGen / AG2 | DIY |
| Semantic Kernel | via Azure Logic Apps |
| HumanLayer | Native |
| Composio (connector layer) | Native |
| n8n | Native node |
| Temporal | DIY |
| Sierra / Decagon / Moveworks / Glean / Cognigy / Kore.ai / Aisera | Native (most) |
| AWS Bedrock AgentCore | via Lambda |
| Azure AI Foundry Agent Service | via Logic Apps |
| Vertex AI Agent Builder | via Cloud Functions |
| Solution | |
|---|---|
| LangGraph | via custom tool |
| CrewAI | via Gmail/Outlook tool |
| AutoGen / AG2 | DIY |
| Semantic Kernel | via Logic Apps |
| HumanLayer | Native |
| Composio (connector layer) | Native (Gmail/Outlook) |
| n8n | Native node |
| Temporal | DIY |
| Sierra / Decagon / Moveworks / Glean / Cognigy / Kore.ai / Aisera | Native (most) |
| AWS Bedrock AgentCore | via SES |
| Azure AI Foundry Agent Service | via Logic Apps |
| Vertex AI Agent Builder | via Cloud Functions |
Linear
| Solution | Linear |
|---|---|
| LangGraph | via Composio/MCP |
| CrewAI | via Composio |
| AutoGen / AG2 | DIY |
| Semantic Kernel | no |
| HumanLayer | no |
| Composio (connector layer) | Native |
| n8n | community node |
| Temporal | DIY |
| Sierra / Decagon / Moveworks / Glean / Cognigy / Kore.ai / Aisera | rare |
| AWS Bedrock AgentCore | via Lambda |
| Azure AI Foundry Agent Service | via connector |
| Vertex AI Agent Builder | via API |
GitHub
| Solution | GitHub |
|---|---|
| LangGraph | via community toolkit |
| CrewAI | via crewai-tools |
| AutoGen / AG2 | DIY |
| Semantic Kernel | via Azure DevOps/GH Actions |
| HumanLayer | no |
| Composio (connector layer) | Native |
| n8n | Native node |
| Temporal | DIY |
| Sierra / Decagon / Moveworks / Glean / Cognigy / Kore.ai / Aisera | rare |
| AWS Bedrock AgentCore | via Lambda |
| Azure AI Foundry Agent Service | via GH Actions/Azure DevOps connector |
| Vertex AI Agent Builder | via Cloud Build/GitHub App |
GitLab
| Solution | GitLab |
|---|---|
| LangGraph | via community toolkit |
| CrewAI | via Composio |
| AutoGen / AG2 | DIY |
| Semantic Kernel | no |
| HumanLayer | no |
| Composio (connector layer) | Native |
| n8n | Native node |
| Temporal | DIY |
| Sierra / Decagon / Moveworks / Glean / Cognigy / Kore.ai / Aisera | rare |
| AWS Bedrock AgentCore | via Lambda |
| Azure AI Foundry Agent Service | via connector |
| Vertex AI Agent Builder | via API |
Terraform / Ansible
| Solution | Terraform / Ansible |
|---|---|
| LangGraph | wrap CLI as a tool |
| CrewAI | wrap CLI as a tool |
| AutoGen / AG2 | wrap CLI as a tool |
| Semantic Kernel | wrap CLI, or Azure Automation |
| HumanLayer | you wrap the CLI as the gated function |
| Composio (connector layer) | no native toolkit, custom action |
| n8n | via Execute Command/SSH node or Terraform Cloud/AWX API |
| Temporal | common pattern for long-running infra workflows |
| Sierra / Decagon / Moveworks / Glean / Cognigy / Kore.ai / Aisera | not applicable, support/ops focused, not devops |
| AWS Bedrock AgentCore | provisioned by Terraform (AWS provider), not the reverse |
| Azure AI Foundry Agent Service | provisioned by azurerm Terraform provider |
| Vertex AI Agent Builder | provisioned by google Terraform provider |
The honest takeaway from building these tables: none of the orchestration frameworks ship first-party Linear/GitHub/GitLab/Terraform/Ansible connectors. Those are always either (a) community packages, (b) routed through a connector layer like Composio, or (c) something you wire yourself by wrapping a CLI call as a "tool" the agent can invoke. The only category with genuinely native, batteries-included connectors for all of Slack/email/GitHub/GitLab is the no-code automation tools (n8n).
Best-Practice HITL Implementation
Regardless of which framework you pick, the implementations that hold up in production share the same shape. Tier actions by blast radius and only interrupt for the ones that mutate state: read-only calls (terraform plan, ansible-playbook --check, a GitHub search) should never block on a human, or reviewers burn out and start rubber-stamping everything, which defeats the point. Show the reviewer the actual artifact, not a summary of it, meaning a plan diff or a rendered playbook change, not "agent wants to modify infrastructure." Set an explicit approval timeout with an escalation path to a secondary reviewer, and fail closed: if the approval channel (Slack, email, whatever) is unreachable, the default must be "do nothing," never "proceed anyway." Keep an immutable, identity-tied audit log of every request and decision (who saw what, when, and what they approved); this is precisely what auditors and the EU AI Act's human-oversight requirement will ask for. And make the resume path idempotent, so a crashed or retried approval workflow can't double-apply a terraform apply or send a duplicate email.
Orchestration Frameworks
LangGraph
Open source, graph-based state machine. HITL is not bolted on: it's a first-class primitive. A node calls interrupt(), execution pauses, state is checkpointed (Postgres/SQLite/Redis backends), and a human resumes it later with Command(resume=...). This is what you want if the approval might take hours or days, because the checkpoint survives process restarts.
Self-hosting: fully OSS. LangGraph Platform also offers "Self-Hosted Lite" (all plans) and "Self-Hosted Enterprise" if you want their control plane without sending data to LangChain's cloud. Note there's a known rough edge on self-hosted OSS Docker deployments: interrupts aren't always reflected correctly in thread_state, though the stream itself emits the interrupt fine. Worth testing before you rely on it for anything critical.
Slack/GitHub/GitLab/Linear: none of these are core. There's a langgraph-messaging-integrations repo for wiring in Slack as an event source, and the LangChain ecosystem has community toolkits for GitHub. For Linear/GitLab you're generally going through Composio or an MCP server. LangGraph itself has no opinion on how you deliver the approval request to a human; that's explicitly left to the application layer.
Terraform/Ansible: wrap terraform plan/apply or ansible-playbook --check/apply as tool nodes, and put the interrupt() between plan and apply. This is the standard pattern regardless of framework.
CrewAI
Open source, role-based ("crew" of agents with role/goal/backstory). Has a built-in human_input flag on tasks, the simplest of the bunch to bolt basic HITL onto, though it's coarser-grained than LangGraph's interrupt/resume.
Self-hosting: OSS core is free to self-host. CrewAI AMP (their enterprise suite) explicitly supports both cloud and on-premise deployment for teams with compliance requirements.
Slack: CrewAI Enterprise has a documented native Slack integration. Gmail/Outlook are supported too. GitHub is covered via crewai-tools (there's even a documented "PR Agent" pattern for automated GitHub PR review). Linear and GitLab aren't native, same story: go through Composio.
AutoGen / AG2
Open source (AG2 is the community fork after Microsoft restructured AutoGen). This is the one framework where HITL is genuinely baked into the core abstraction, not an add-on: UserProxyAgent has a human_input_mode parameter (ALWAYS, TERMINATE, NEVER) that controls whether a human is consulted before every action, only on termination, or never. If you want the most "native" HITL semantics with the least glue code, this is it.
The tradeoff: no managed hosting offering, and zero native Slack/Linear/GitHub/GitLab connectors. You're building the delivery channel yourself (e.g., a Slack bot that surfaces the human_input prompt and posts the reply back).
Semantic Kernel
Open source, Microsoft. Less of a pure-agent framework, more of an orchestration SDK that plugs into the Azure ecosystem. HITL is implementable via planners/filters that intercept a plan step before execution. Its practical advantage is Azure Logic Apps as an integration bus: Teams, Slack, and email approvals become "just another Logic App connector" rather than something you build from scratch. GitHub Actions/Azure DevOps connectors exist in that same ecosystem. No native Linear or GitLab connector.
Dedicated HITL Layers
HumanLayer
This is the one purpose-built for the exact question "how do I make an agent pause and ask a human before it does something consequential." The SDK is Apache-2 licensed and open source; it provides "OmniChannel Contact": Slack, email, and Discord are first-class, with granular routing to specific teams or people. It's framework-agnostic: bring your own LLM/orchestrator (LangGraph, CrewAI, raw function calling, whatever) and use HumanLayer purely as the approval gate.
No native Linear, GitHub, or GitLab channel. It's built for notifying a human, not for ticketing systems. If you want an approval request to also show up as a Linear issue, you'd chain it: agent to HumanLayer (Slack/email) to your own webhook to Linear API.
Self-hosting: the SDK/client side is OSS, but the approval-routing backend is a hosted service. Check current docs before assuming a fully airtight self-hosted deployment.
Composio: the connector layer everyone actually uses
Worth calling out on its own because it answers the "does X have Linear/Slack/GitHub/GitLab integration" question better than any individual agent framework does. Composio is a tool-integration bus: 200+ apps including Slack, Gmail/Outlook, Linear, GitHub, and GitLab, with OAuth/auth handling done for you, exposed as tools any framework (LangGraph, CrewAI, AutoGen, plain function-calling) can call. It's the thing that turns "my agent needs to open a Linear ticket when a human rejects an approval" from a bespoke integration into a five-line tool call.
It is not itself an HITL mechanism. It's the plumbing you'd combine with LangGraph's interrupt() or HumanLayer's approval gate to actually reach a human and then act on tools like Linear/GitHub/GitLab afterward. No native Terraform/Ansible toolkit as of writing; you'd register those as custom actions.
No-Code: n8n
If your actual requirement is "self-hosted, with native Slack + email + GitHub + GitLab, and a human approval step," n8n is the most complete out-of-the-box answer, not any of the code-first agent frameworks. It's open source, self-hostable, and has a documented "Human-in-the-loop for AI tool calls" pattern: the workflow pauses, shows the reviewer which tool the AI wants to run and with what parameters, and waits for approve/deny via Slack, email, or n8n's own chat UI form.
Native nodes exist for Slack, GitHub, and GitLab (including combined GitHub+Slack notification workflows and GitLab CI code-review automation people have built with it). Linear is a community node rather than core, but it works. For Terraform/Ansible there's no dedicated node: you either shell out via the Execute Command/SSH node, or hit Terraform Cloud's API / Ansible AWX's REST API directly with the HTTP Request node, gated behind the same approval step.
This is the pragmatic choice if you want the integration matrix filled in without writing custom connector code for every ticket system.
Durable Execution Underneath: Temporal
Not agent-specific, but the honest answer for "what happens if the human doesn't approve for three days." LangGraph's checkpointing handles short gaps well, but for genuinely long-running, must-survive-a-restart workflows, people put Temporal underneath. It's OSS self-hosted or Temporal Cloud, and the HITL pattern is implemented with signals (the workflow blocks on a signal, a human approval external system sends the signal when someone clicks approve). No native Slack/Linear/GitHub integration (that's still on you), but it's rock solid for the "this Terraform apply might wait for approval over a weekend" case.
Terraform and Ansible: the actual pattern
Across every framework above, there is no such thing as a native "Terraform integration" or "Ansible integration" the way there's a native Slack integration. What you build instead, regardless of framework, is:
- Wrap
terraform plan(oransible-playbook --check --diff) as a read-only tool the agent can call freely. - Save the plan/diff as an artifact.
- Put the HITL gate (
interrupt()in LangGraph,human_inputin CrewAI,human_input_mode=ALWAYSin AutoGen, the Wait node in n8n) between the plan and the apply. - Only after approval, call
terraform apply/ansible-playbook(without--check) as a second, separate tool.
MCP servers for both Terraform and Ansible AWX are starting to show up, which is the more future-proof direction: any MCP-capable agent (Claude, LangGraph via langchain-mcp-adapters, etc.) can use the same server without framework-specific glue.
Enterprise Vertical Platforms (for completeness)
Sierra, Decagon, Moveworks, Glean, Cognigy, Kore.ai, Aisera: these are SaaS-only, built for customer support / employee IT support, and generally do have native Slack/Teams approval queues. But Linear, GitHub, GitLab, and Terraform/Ansible are simply not their target surface. They're not devops tools, and treating them as agent infrastructure for this use case would be the wrong tool for the job.
Cloud Hyperscaler Managed Agent Services (for completeness)
AWS Bedrock AgentCore, Azure AI Foundry Agent Service, and Vertex AI Agent Builder are all managed-only (no self-hosting the control plane, though you own the account/tenant). Important distinction: Terraform's relationship to these is inverted from everything else in this post. You use Terraform (aws/azurerm/google providers) to provision the agent service itself, rather than the agent using Terraform as a tool. If you want the agent itself to call Terraform/Ansible as part of its own workflow, you're back to the same wrap-the-CLI-and-gate-it pattern via Lambda/Cloud Functions/Logic Apps.
What I'd Actually Wire Together
For a self-hosted stack that hits every integration point I care about:
LangGraph (orchestration + interrupt/resume) + Composio (Linear/Slack/GitHub/GitLab tool access) + HumanLayer or a plain Slack bot (the human notification channel) + Temporal (if approvals might take longer than a checkpoint should reasonably hold state) + wrapped terraform plan/ansible-playbook --check calls gated behind the interrupt.
If I didn't want to write and maintain that glue code, n8n self-hosted gets me 80% of the same integration coverage (Slack, email, GitHub, GitLab native; Linear via community node) with none of the Python.