Agentic AI Infrastructure with a Human in the Loop

draft

Survey of agent orchestration frameworks and HITL layers, with a practical breakdown of self-hosting and Slack/email/Linear/GitHub/GitLab/Terraform/Ansible integration.

July 24, 2026infra2727 words · 14 min read
#ai#agents#hitl#automation#devops

Table of Contents

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 apply or an ansible-playbook run?

Quick Comparison

Same 12 solutions in every table below, one attribute at a time: easier to scan than one wide table.

Self-hosted?

SolutionSelf-hosted
LangGraphYes (OSS + Enterprise self-host)
CrewAIYes (OSS) + AMP cloud/on-prem
AutoGen / AG2Yes (OSS only)
Semantic KernelYes (OSS) + Azure managed
HumanLayerSDK is OSS, approval backend hosted
Composio (connector layer)Cloud, limited self-host
n8nYes (OSS self-hosted or cloud)
TemporalYes (OSS self-hosted or Cloud)
Sierra / Decagon / Moveworks / Glean / Cognigy / Kore.ai / AiseraNo, SaaS only
AWS Bedrock AgentCoreNo, managed
Azure AI Foundry Agent ServiceNo, managed
Vertex AI Agent BuilderNo, managed

Native HITL mechanism

SolutionNative HITL
LangGraphYes, core (interrupt()/checkpointer)
CrewAIYes, human_input flag
AutoGen / AG2Yes, core (UserProxyAgent)
Semantic KernelYes, via planner/filters
HumanLayerYes, this is the product
Composio (connector layer)N/A (it's a tool bus, not an agent)
n8nYes, "Wait for approval" node
TemporalPattern via signals, not built-in
Sierra / Decagon / Moveworks / Glean / Cognigy / Kore.ai / AiseraYes, built-in approval queues
AWS Bedrock AgentCoreAction-group approval hooks
Azure AI Foundry Agent ServiceBuilt-in via Logic Apps
Vertex AI Agent BuilderVia Cloud Functions hook

Slack

SolutionSlack
LangGraphvia community bot
CrewAINative (Enterprise)
AutoGen / AG2DIY
Semantic Kernelvia Azure Logic Apps
HumanLayerNative
Composio (connector layer)Native
n8nNative node
TemporalDIY
Sierra / Decagon / Moveworks / Glean / Cognigy / Kore.ai / AiseraNative (most)
AWS Bedrock AgentCorevia Lambda
Azure AI Foundry Agent Servicevia Logic Apps
Vertex AI Agent Buildervia Cloud Functions

Email

SolutionEmail
LangGraphvia custom tool
CrewAIvia Gmail/Outlook tool
AutoGen / AG2DIY
Semantic Kernelvia Logic Apps
HumanLayerNative
Composio (connector layer)Native (Gmail/Outlook)
n8nNative node
TemporalDIY
Sierra / Decagon / Moveworks / Glean / Cognigy / Kore.ai / AiseraNative (most)
AWS Bedrock AgentCorevia SES
Azure AI Foundry Agent Servicevia Logic Apps
Vertex AI Agent Buildervia Cloud Functions

Linear

SolutionLinear
LangGraphvia Composio/MCP
CrewAIvia Composio
AutoGen / AG2DIY
Semantic Kernelno
HumanLayerno
Composio (connector layer)Native
n8ncommunity node
TemporalDIY
Sierra / Decagon / Moveworks / Glean / Cognigy / Kore.ai / Aiserarare
AWS Bedrock AgentCorevia Lambda
Azure AI Foundry Agent Servicevia connector
Vertex AI Agent Buildervia API

GitHub

SolutionGitHub
LangGraphvia community toolkit
CrewAIvia crewai-tools
AutoGen / AG2DIY
Semantic Kernelvia Azure DevOps/GH Actions
HumanLayerno
Composio (connector layer)Native
n8nNative node
TemporalDIY
Sierra / Decagon / Moveworks / Glean / Cognigy / Kore.ai / Aiserarare
AWS Bedrock AgentCorevia Lambda
Azure AI Foundry Agent Servicevia GH Actions/Azure DevOps connector
Vertex AI Agent Buildervia Cloud Build/GitHub App

GitLab

SolutionGitLab
LangGraphvia community toolkit
CrewAIvia Composio
AutoGen / AG2DIY
Semantic Kernelno
HumanLayerno
Composio (connector layer)Native
n8nNative node
TemporalDIY
Sierra / Decagon / Moveworks / Glean / Cognigy / Kore.ai / Aiserarare
AWS Bedrock AgentCorevia Lambda
Azure AI Foundry Agent Servicevia connector
Vertex AI Agent Buildervia API

Terraform / Ansible

SolutionTerraform / Ansible
LangGraphwrap CLI as a tool
CrewAIwrap CLI as a tool
AutoGen / AG2wrap CLI as a tool
Semantic Kernelwrap CLI, or Azure Automation
HumanLayeryou wrap the CLI as the gated function
Composio (connector layer)no native toolkit, custom action
n8nvia Execute Command/SSH node or Terraform Cloud/AWX API
Temporalcommon pattern for long-running infra workflows
Sierra / Decagon / Moveworks / Glean / Cognigy / Kore.ai / Aiseranot applicable, support/ops focused, not devops
AWS Bedrock AgentCoreprovisioned by Terraform (AWS provider), not the reverse
Azure AI Foundry Agent Serviceprovisioned by azurerm Terraform provider
Vertex AI Agent Builderprovisioned 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:

  1. Wrap terraform plan (or ansible-playbook --check --diff) as a read-only tool the agent can call freely.
  2. Save the plan/diff as an artifact.
  3. Put the HITL gate (interrupt() in LangGraph, human_input in CrewAI, human_input_mode=ALWAYS in AutoGen, the Wait node in n8n) between the plan and the apply.
  4. 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.