DEV Community: sekera-radim

A Lightweight Alternative to Workflow Engines for HITL

sekera-radim — Fri, 11 Sep 2026 21:50:02 +0000

If you only need one human checkpoint in an otherwise automated agent pipeline, standing up n8n or Temporal for that single yes/no is overkill — Impri adds the approval gate as three API calls with no workflow engine to run.

The situation this is for

You have a content pipeline: an agent researches a topic, drafts a post, and wants to publish it to your company blog and cross-post to X. Everything up to "publish" is fine to automate. The publish step is not — a bad take going out under your brand's name is expensive to walk back.

The instinct is often to reach for a workflow engine, since "wait for human input" sounds like a workflow node. But bringing in n8n, Temporal, or Inngest for a pipeline that is otherwise just "generate, then post" means running and maintaining an orchestration platform — persistence, workers, a UI, deployment — for what is functionally one pause-and-resume point.

What you actually need for one gate

Three things: somewhere to park the pending action, a way to notify a human, and a way for your existing script to resume once a decision exists. That's the entire feature set Impri provides — no DAGs, no node graph, no separate deployment beyond the API itself (or a self-hosted binary, if you'd rather not depend on the cloud service).

Here's the same publish pipeline with the gate added, as a plain TypeScript script — no orchestration framework in sight:

import { setTimeout as sleep } from "node:timers/promises";

const API = "https://api.impri.dev";
const headers = {
  Authorization: `Bearer ${process.env.IMPRI_API_KEY}`,
  "Content-Type": "application/json",
};

interface Decision {
  status: "pending" | "approved" | "rejected" | "expired";
  decision?: { final_preview: { body: string } };
}

async function gatePublish(title: string, draft: string): Promise<Decision> {
  const create = await fetch(`${API}/v1/actions`, {
    method: "POST",
    headers,
    body: JSON.stringify({
      kind: "blog.publish",
      title: `Publish: ${title}`,
      preview: { format: "markdown", body: draft },
      expires_in: 43200, // 12h
      editable: ["preview.body"],
    }),
  }).then((r) => r.json());

  while (true) {
    const check: Decision = await fetch(`${API}/v1/actions/${create.id}`, { headers }).then((r) =>
      r.json()
    );
    if (check.status !== "pending") return check;
    await sleep(10_000);
  }
}

async function run() {
  const draft = await generateBlogPost("distributed tracing pitfalls"); // your existing step
  const decision = await gatePublish("Distributed tracing pitfalls", draft);

  if (decision.status === "approved") {
    const finalBody = decision.decision!.final_preview.body;
    await publishToBlog(finalBody);
    await crossPostToX(finalBody);
  } else {
    console.log(`Publish skipped: ${decision.status}`);
  }
}

run();

No engine process, no separate UI to deploy, no node-graph config to version. The pipeline is still "just a script" — it has one await that happens to resolve only when a human decides.

Where this stops being the right fit

Impri is deliberately narrow, and that's the tradeoff for being lightweight. It is not a substitute for a workflow engine once your pipeline actually needs orchestration features:

You need	Reach for
One pause for a yes/no/edit decision	Impri
Branching logic across many conditions after the decision	A workflow engine's HITL node, or your own code — Impri gives you the decision, not the branching
Scheduling, retries-with-backoff across multiple steps, long-running state machines	Temporal, Inngest
Visual pipeline building for non-engineers	n8n
Multiple agents coordinating with each other	A workflow engine or agent framework — Impri gates one agent's action, it doesn't hand off between agents

The two aren't mutually exclusive, either: if you already run n8n for the rest of the pipeline, you can call Impri's REST API from an HTTP Request node and get the lightweight approval card without adopting n8n's own (heavier) human-in-the-loop pattern for this one step. See the integrations guide for wiring Impri into an existing pipeline rather than replacing it.

What you get for the tradeoff

By staying out of orchestration, Impri stays out of your pipeline's control flow — it's an await in a script, not a graph your script lives inside. That means:

No new infra to run if you're on the hosted version at api.impri.dev.
The rest of your pipeline is still ordinary code you can test, debug, and version like anything else.
Adding or removing the gate is a diff of a few lines, not a rewrite into a different execution model.

The cost is that you get exactly one primitive — propose, notify, decide — and nothing to model complex branching with. For a single checkpoint in an otherwise scripted pipeline, that's usually the right amount of tool.

Try it

Full walkthrough with both REST and MCP flows: how to add human approval to an AI agent. For webhook-based notification into your own systems instead of polling, see webhooks. More integration patterns, including chaining with existing tools, are in the cookbook.

Get an API key and try the script above in a few minutes: quickstart.

REST API vs MCP for Human-in-the-Loop Approval

sekera-radim — Thu, 10 Sep 2026 13:10:02 +0000

Choosing between Impri's REST API and its MCP server comes down to where your agent runs — a Python worker calls REST directly, a Claude Code or Claude Desktop agent gets the same three-call flow for free through MCP tools.

The same three calls, two transports

Whether you gate an action over REST or MCP, the underlying operation is identical: push an action, wait for a decision, execute only if approved. What changes is who writes the polling loop.

REST: your code makes the HTTP calls, your code polls, your code branches on the result.
MCP: the agent calls a tool, the tool blocks until a decision exists, the agent receives the result and continues.

Neither path skips the gate. Both hit the same https://api.impri.dev backend and the same inbox. The difference is ergonomics, not security.

Scenario: an agent that merges pull requests

Say you have a coding agent that opens PRs and, when CI is green, wants to merge them. Merging is exactly the kind of side effect you don't want an agent doing unsupervised — a bad merge to main is not easily undone by a retry.

Option A — a Python worker calling REST directly

This fits a standalone agent process, e.g. a cron job or a CI bot, that isn't running inside an MCP-capable client.

import os
import time
import requests

API = "https://api.impri.dev"
HEADERS = {"Authorization": f"Bearer {os.environ['IMPRI_API_KEY']}"}

def request_merge_approval(pr_number: str, pr_title: str, diff_summary: str) -> dict:
    resp = requests.post(f"{API}/v1/actions", headers=HEADERS, json={
        "kind": "github.pr_merge",
        "title": f"Merge PR #{pr_number}: {pr_title}",
        "preview": {"format": "markdown", "body": diff_summary},
        "target_url": f"https://github.com/acme/app/pull/{pr_number}",
        "expires_in": 21600,  # 6h — a stale merge approval isn't worth acting on
        "idempotent": False,
        "undo": f"git revert the merge commit for PR #{pr_number}",
    })
    action = resp.json()

    while True:
        result = requests.get(f"{API}/v1/actions/{action['id']}", headers=HEADERS).json()
        if result["status"] != "pending":
            return result
        time.sleep(10)

result = request_merge_approval("482", "Add retry backoff to webhook sender", "Adds exponential backoff...")
if result["status"] == "approved":
    merge_pr(482)  # your GitHub API call, using result["decision"]["final_preview"]
    requests.post(f"{API}/v1/actions/{result['id']}/result", headers=HEADERS,
                   json={"status": "executed"})

You own the retry loop, the timeout handling, and the HTTP error handling. That's more code, but it also means no dependency beyond requests and it runs anywhere Python runs.

Option B — MCP inside Claude Code

If the same merge-deciding agent is a Claude Code session or subagent, wire up the MCP server once and the polling loop disappears from your code entirely — it lives inside the tool implementation:

{
  "mcpServers": {
    "impri": {
      "command": "npx",
      "args": ["@impri/mcp"],
      "env": { "IMPRI_API_KEY": "im_your_key_here" }
    }
  }
}

The agent's flow becomes three tool calls with no HTTP client code in your prompt or scaffolding:

impri_push_action(kind="github.pr_merge", title="Merge PR #482: Add retry backoff",
                   preview={format:"markdown", body:"..."}, expires_in=21600)
  → { action_id: "act_482", status: "pending" }

impri_await_decision(action_id="act_482", timeout_s=21600)
  → { status: "approved", preview: {...} }

impri_report_result(action_id="act_482", status="executed")

When to pick which

Your setup	Use
Standalone script, cron job, backend worker	REST — no MCP runtime needed
Claude Code, Claude Desktop, or another MCP client	MCP — the client already speaks the protocol
You need custom retry/backoff logic around polling	REST — full control over the loop
You want the agent to reason about the wait naturally in its own tool-call loop	MCP — `impri_await_decision` blocks like any other tool call
Non-Node/Python runtime (Go, Rust, PHP)	REST — MCP server ships as an npx package, REST works from anywhere with HTTP

Both share the same rate limit (60 requests/min per key to POST /v1/actions) and the same expiry rules — nothing about the transport changes what counts as a valid decision.

The part that doesn't change either way

Regardless of transport, the gate only holds if the wrapped action truly has no other path to execution. An agent that can call the GitHub merge API directly, with its own token, can route around Impri entirely — REST or MCP. The chokepoint has to be the code path, not the request format. See how to add human approval to an AI agent for the full reasoning on that boundary, and the MCP integration guide for server setup details beyond this example.

If you're building specifically on the Claude Agent SDK, the dedicated guide covers wrapping tool executors so the approved decision is the only path to the side effect, not just an extra step the model could skip.

Next: quickstart to get an API key and try either path in under five minutes.

An MCP Approval Server for AI Agents

sekera-radim — Wed, 09 Sep 2026 17:50:02 +0000

Impri's MCP approval server (npx @impri/mcp) gives Claude Code and other MCP clients a real tool call to pause an agent and wait on a human's decision.

The problem with "just ask the user" in a prompt

If your agent runs inside an MCP client, it already has tools: file access, shell, GitHub, a database driver. Telling it in the system prompt to "pause and ask before doing anything destructive" is not a tool call — it's a suggestion the model can forget, rationalize past, or skip entirely under prompt injection from a fetched file or issue body. There's also no record of what was asked or who answered. An MCP approval-gate server turns that suggestion into a real dependency: the agent calls a tool, gets back a pending action, and the code path that does the actual work simply isn't reached until that tool returns approved.

The three tools, and what each one is for

Impri's MCP server exposes exactly three tools — nothing more:

impri_push_action(kind, title, preview, expires_in, editable) — creates the pending action and notifies a human. Returns an action_id.
impri_await_decision(action_id, timeout_s) — blocks (polling internally every few seconds) until the action is approved, rejected, or expired, or the timeout elapses.
impri_report_result(action_id, status) — tells Impri whether the agent's subsequent execution succeeded (executed) or failed (execute_failed), so the audit trail is complete.

That's the entire surface. There's no fourth tool for "auto-approve" or "cancel" — the state machine is deliberately small.

Wiring it up

Add the server to your MCP client config, pointing IMPRI_BASE_URL at either the cloud API or a self-hosted instance:

{
  "mcpServers": {
    "impri": {
      "command": "npx",
      "args": ["@impri/mcp"],
      "env": {
        "IMPRI_API_KEY": "im_your_key_here",
        "IMPRI_BASE_URL": "http://localhost:8484"
      }
    }
  }
}

Drop IMPRI_BASE_URL to use the cloud default, or point it at a self-hosted instance. Once configured, impri_push_action, impri_await_decision, and impri_report_result show up as ordinary tools in the client's tool list, right next to whatever else the agent can call.

Walkthrough: an agent that triages and closes GitHub issues

Say the agent has a github MCP server too, with tools to close issues and post comments. Without a gate, a triage agent that decides an issue is stale will just close it. With Impri in front of that decision, the close is proposed, not executed:

// Wrapper the agent calls instead of the raw GitHub "close issue" tool.
async function closeIssueWithApproval(issue: {
  repo: string; // "owner/repo"
  number: number;
  reason: string;
}) {
  const pushed = await mcp.call("impri_push_action", {
    kind: "github.issue.close",
    title: `Close ${issue.repo}#${issue.number}: ${issue.reason}`,
    preview: {
      format: "markdown",
      body: `Closing **${issue.repo}#${issue.number}**.\n\nReason: ${issue.reason}\n\nComment to post: "Closing as stale — no activity in 90 days."`,
    },
    expires_in: 3600, // 1 hour to review
    editable: ["preview.body"], // reviewer can rewrite the comment text
  });

  const decision = await mcp.call("impri_await_decision", {
    action_id: pushed.action_id,
    timeout_s: 1800,
  });

  if (decision.status !== "approved") {
    return { closed: false, status: decision.status };
  }

  // Only reached after a human approved — this is the actual GitHub call.
  const [owner, repo] = issue.repo.split("/");
  await github.issues.createComment({ owner, repo, issue_number: issue.number, body: decision.preview.body });
  await github.issues.update({ owner, repo, issue_number: issue.number, state: "closed" });

  await mcp.call("impri_report_result", { action_id: pushed.action_id, status: "executed" });
  return { closed: true };
}

If the reviewer rejects it, or 30 minutes pass without a decision, closeIssueWithApproval returns without ever calling github.issues.update. That's the whole mechanism — no branch of the agent's code that touches GitHub runs before impri_await_decision resolves to approved.

Where the gate actually lives

The gate is the closeIssueWithApproval wrapper, not Impri itself. Impri stores the proposed action, notifies a reviewer, and holds the decision — it doesn't know what "closing a GitHub issue" means and doesn't call the GitHub API for you. The protection only holds if the wrapper above is the agent's only route to closing issues. If the same agent session also has the raw github MCP server's close-issue tool available unwrapped, it can call that directly and skip Impri entirely — the approval tool becomes decoration, not a gate. Confine the agent to the wrapped tool (remove or don't register the raw one) for the dependency to be real. This is the MCP-specific version of the same rule that applies to the REST integration: a gate is only as strong as the absence of a bypass.

What this MCP server is, and isn't

@impri/mcp is three tools and nothing else. It doesn't decide what counts as risky, doesn't generate the close-comment text, and doesn't retry failed GitHub calls for you — impri_report_result just records what happened so the audit log is accurate. If you need branching logic across many tools and services, that's an orchestration layer like n8n or Temporal sitting above this, not something Impri adds. For a broader look at wiring Impri into an SDK-based agent rather than an MCP client, see the MCP integration guide and the Claude Agent SDK guide.

Ready to wire it up. Start with quickstart to get an API key, then point your MCP client config at it.

Approval Inbox vs Slack Buttons for Agent Sign-off

sekera-radim — Wed, 09 Sep 2026 05:30:03 +0000

Comparing a homegrown Slack approve/reject bot to a dedicated approval inbox for AI agent actions, covering audit trail, mobile use, expiry, and edits.

The instinct: just add Slack buttons

The first time someone needs a human to sign off on an agent action, the plan is almost always the same: post to Slack with Block Kit "Approve" / "Reject" buttons, stand up a small webhook receiver for the interaction payload, and flip a flag in your own database on click. It looks like an afternoon of work, and for a while it is.

What's easy to underestimate is everything Slack doesn't do for you. It delivers the click; your service handles the rest.

What you actually end up maintaining

The webhook receiver. A public endpoint that verifies Slack's request signature (HMAC against your signing secret + timestamp), replies inside Slack's 3-second window, and does the real work async. Get the check wrong and anyone who finds the URL can approve or reject actions.
State for the interaction. A button click gives you a message_ts and whatever value you encoded — not an approval record. Your own table for status, decision time, and who clicked, or there's no audit trail.
Expiry. Slack messages don't expire. A three-day-old "Approve this email?" button still fires on day nine, for a draft that's no longer relevant. You build the timeout logic yourself.
Editing the draft. Buttons alone can't let a reviewer tweak the text before sending — that needs a modal, a submit handler, and a way to carry the edit back into your pipeline.
Mobile. One approve/reject button renders fine on Slack mobile; a longer preview or diff is cramped, and there's no "here's what's waiting on me" view — just whatever scrolled past in the channel.
Only Slack. An approver away from Slack — email, SMS, push — means another integration and another retry policy.

None of this is exotic engineering. It's work unrelated to what you wanted to ship, and the kind of code that rots once its author moves on.

The same flow through an approval inbox

Impri replaces the receiver you'd maintain with three calls your agent already needs to make:

curl -s -X POST https://api.impri.dev/v1/actions \
  -H "Authorization: Bearer $IMPRI_API_KEY" \
  -d '{
    "kind": "slack.message.send",
    "title": "Reply in #support: refund request from customer #4821",
    "preview": { "format": "markdown", "body": "Hi, I have gone ahead and processed..." },
    "expires_in": 3600,
    "editable": ["preview.body"]
  }'
# → { "id": "act_9f2", "status": "pending", "inbox_url": "https://app.impri.dev/a/act_9f2" }

Compare that to what the DIY route needs just to render the prompt, before any receiver logic exists:

{
  "blocks": [
    { "type": "section", "text": { "type": "mrkdwn", "text": "Reply in #support: refund request from customer #4821" } },
    { "type": "actions", "elements": [
      { "type": "button", "text": { "type": "plain_text", "text": "Approve" }, "value": "act_9f2:approve" },
      { "type": "button", "text": { "type": "plain_text", "text": "Reject" }, "value": "act_9f2:reject" }
    ]}
  ]
}

The Slack JSON is just the button. Everything after the click — signature check, state, expiry, edits, history — is code you write. GET /v1/actions/act_9f2 gives the agent status, decision.final_preview (the human-edited version, when editable was used), and decision.diff, with no receiver of your own.

Slack doesn't disappear

This isn't "Slack vs an inbox" as mutually exclusive options. Impri lists Slack as one of its approval channels alongside Discord and Telegram, plus email, ntfy, and web push for plain notifications — see slack-approval. The difference is who owns the plumbing: the click in Slack still resolves against a real action record with an expiry, an audit entry, and a place to review it later, instead of a bespoke handler you're on the hook for. Teams that want the ping in Slack but the decision handling centralized keep the notification and drop the receiver.

Where the DIY Slack bot is genuinely fine

Be honest about this: for one approver, low volume, and no need to prove later who approved what, a button and a five-line webhook handler is a reasonable afternoon project. If nobody ever needs a diff, an edit step, mobile parity, or a second channel, the extra piece is the inbox, not the bot. The tradeoff shows up as volume grows, as more people need to approve, or the first time someone asks "who approved this and when" and the answer is a Slack search.

Situation	DIY Slack buttons	Approval inbox (Impri)
Single approver, a few actions/day	Fine	Also fine, more setup
Need an audit log of decisions	Build it yourself	Built in
Reviewer edits the draft before approving	Needs a modal + handler	`editable` field
Approver on mobile, away from desktop	Cramped, channel-dependent	Dedicated inbox card
Expiry on stale actions	You implement it	`expires_in`, enforced
Notify beyond Slack	Separate integration each	email/ntfy/push + Slack/Discord/Telegram

What this doesn't solve

Whichever side you pick, the gate is only as real as the wrapper around it. Impri stores the proposed action, notifies a human, and holds the decision — it doesn't generate the draft, doesn't interpret the action, and never executes anything itself. It's a genuine gate only when the wrapped tool is the agent's only path to the side effect; an agent holding the raw Slack or SMTP credential can route around either approach. See how-to-add-human-approval-to-an-ai-agent for the wrapper pattern.

Next step: quickstart to get an API key and push your first action, or slack-approval if Slack is where your team wants the notification to land.

Human-in-the-Loop Tools for LLM Agents, Compared

sekera-radim — Tue, 08 Sep 2026 04:10:02 +0000

A practical comparison of the four categories of human-in-the-loop tooling for LLM agents — framework-native interrupts, workflow-engine nodes, general approval software, and dedicated gates — so you pick by category, not by name.

The four categories

"HITL tool" gets used for four genuinely different things. Sorting a candidate into the right one answers most of the "does this fit my stack" question before you read a single doc page.

Category	Example	Lives where	Built for
Framework-native interrupt	LangGraph `interrupt()`, OpenAI Agents SDK approval hooks	Inside your agent process	Pausing a graph/run mid-execution
Workflow-engine node	n8n Wait node, Temporal signals	Inside an orchestration platform	Pausing a broader multi-step workflow
General approval/ticketing software	Jira workflow, generic BPM tools	Separate app, not agent-aware	Human approval processes in general
Dedicated agent approval gate	Impri	Separate service, agent-aware	Agent proposes → human decides → agent executes

Framework-native interrupts

If you're building on LangGraph, CrewAI, the OpenAI Agents SDK, or a similar framework, there's often a built-in way to pause a run and wait for external input. LangGraph's interrupt() is the clearest example: it suspends graph execution at a node and resumes when you feed a value back in.

// LangGraph-style interrupt, illustrative
import { interrupt } from "@langchain/langgraph";

async function sendEmailNode(state: AgentState) {
  const decision = interrupt({
    kind: "email.send",
    draft: state.draftBody,
  });
  // Execution resumes here once the graph is fed a decision externally
  if (decision.approved) {
    await sendEmail(decision.finalBody ?? state.draftBody);
  }
  return state;
}

This is the tightest integration you can get — no network hop, no separate service, the pause is a first-class part of the graph. The tradeoff is that the "waiting for a human" part is entirely up to you: something still has to notify a reviewer, render a card they can act on from their phone, and store the decision. The interrupt is the pause primitive, not the inbox, the notification, or the audit log around it. Teams often end up building (or bolting on) exactly the kind of gate described below, just triggered from inside the interrupt.

Workflow-engine nodes

If the agent step is one node in a larger n8n or Temporal workflow, the engine's own human-input primitive is usually the right default — n8n's Wait node resumes on a webhook call; Temporal workflows can block on a signal sent by an external approval action. You avoid adding a new service, and the approval step shows up in the same execution history as the rest of the workflow.

The limitation shows up when the approval step needs to be agent-specific: a diff view of what a human edited before approving, a notion of "this draft expired, don't send it," a mobile-first card instead of a generic form. Workflow engines are general-purpose by design; they don't know that this particular wait step is "should this LLM-drafted email go out."

General approval/ticketing software

Some teams route agent actions through whatever approval tooling already exists — a Jira workflow, a lightweight BPM tool. It avoids new infrastructure, but these systems have no concept of an agent polling for status, no final_preview carrying a human edit back to the exact text the agent should execute, and no expiry tuned to "this draft is now stale." Expect to write and maintain glue code, and expect it to break when the ticketing tool changes its API.

Dedicated agent approval gates

The fourth category is software built specifically for the agent-proposes → human-decides → agent-executes loop and nothing else. Impri is in this category: an agent pushes a proposed action, a human approves, rejects, or edits it from an inbox (web, Slack, Telegram, Discord, or push notification), and the agent polls or blocks for the decision before doing anything.

# Push a proposed action from any agent, any framework
curl -X POST https://api.impri.dev/v1/actions \
  -H "Authorization: Bearer $IMPRI_API_KEY" \
  -d '{
    "kind": "social.post",
    "title": "LinkedIn post: Q3 product update",
    "preview": { "format": "markdown", "body": "Excited to share..." },
    "editable": ["preview.body"],
    "expires_in": 14400
  }'
# → { "id": "act_...", "status": "pending", "inbox_url": "..." }

Because it's agent-agnostic — REST or MCP, no framework required — it composes with any of the other three categories rather than competing with them: trigger the push from inside a LangGraph interrupt(), or from an n8n node, and let Impri own the inbox, notification, human-edit, and audit-log surface instead of building that part yourself.

Picking one

Start from where your agent already lives, not from a feature list:

Already on LangGraph, CrewAI, or a framework with built-in interrupts? Use the interrupt to pause — see human-in-the-loop for LangGraph agents — and decide separately whether you need a real inbox behind it.
Already orchestrating in n8n or Temporal? Use its wait/signal node as the pause point.
Need the inbox, human-edit, and audit trail without building it, regardless of framework? That's what a dedicated gate is for — see the minimal REST/MCP integration.

None of these are mutually exclusive. Most real setups combine a framework-native pause with a dedicated gate behind it, because the pause and the inbox solve different halves of the problem.

Alternatives to Building Your Own Agent Approval System

sekera-radim — Sun, 06 Sep 2026 09:50:04 +0000

Before you write a pending_actions table and a Slack bot, see the four real alternatives to a custom AI agent approval system and when each one actually beats rolling your own.

Why teams end up building one

The trigger is almost always the same: an agent got far enough to be useful, then did something (sent an email, posted a comment, wrote a row) that nobody had reviewed first. The fix people reach for first is a bespoke approval system — a database table, a status column, a Slack webhook, a cron job that pings the agent for the answer. It works for a weekend demo. Then someone needs it on their phone, someone else needs an audit log, and the "just a table and a webhook" system has grown a UI, a notification layer, and an expiry policy nobody remembers writing.

That's the point to stop and look at what already exists, instead of continuing to build.

Option 1: a workflow engine's human-in-the-loop node

Tools like n8n, Temporal, and Inngest have first-class "wait for human input" primitives — n8n's Wait node with a webhook resume, Temporal's signal-based approval workflows. If your agent already lives inside one of these, this is often the path of least resistance: no new service to run, the approval step is just another node.

The tradeoff: these are workflow engines first. You get a pause-and-resume primitive, not a purpose-built inbox — no mobile-friendly approve/reject cards, no diff view for an edited draft, no dedicated audit trail of decisions (as opposed to workflow runs). Adopting one just for the approval step is a heavier dependency than the problem calls for.

Option 2: roll your own (the DIY path)

The minimal version is genuinely simple to prototype:

# db: actions(id, kind, title, body, status, created_at)
import sqlite3, time, uuid

def push_action(kind: str, title: str, body: str) -> str:
    action_id = str(uuid.uuid4())
    db.execute(
        "INSERT INTO actions (id, kind, title, body, status) VALUES (?, ?, ?, ?, 'pending')",
        (action_id, kind, title, body),
    )
    notify_slack(f"New action pending: {title} — {action_id}")
    return action_id

def await_decision(action_id: str, timeout_s: int = 3600) -> str:
    deadline = time.time() + timeout_s
    while time.time() < deadline:
        row = db.execute("SELECT status FROM actions WHERE id = ?", (action_id,)).fetchone()
        if row[0] != "pending":
            return row[0]
        time.sleep(10)
    return "expired"

This is real code you could ship today. The cost shows up later: a reviewer's phone needs a UI, not a database row, so you build one. Someone approves the same batch of emails every morning, so you build bulk-decide. Legal asks who approved what and when, so you build an audit log. Each of those is a normal, boring feature — and each one is a week you didn't spend on the agent itself. Roll-your-own is the right call when the surface is genuinely tiny (one action kind, one reviewer, no compliance requirement) and staying that way.

Option 3: repurpose existing approval/ticketing software

Some teams point agent actions at a system already in place for other approvals — a ticketing tool, a lightweight BPM product, even a shared spreadsheet with a manual review column. This avoids new infrastructure, but these tools weren't built for the agent loop: no GET status endpoint an agent can poll cleanly, no concept of "here is the edited version, execute this text," no expiry that maps to "this draft is stale, don't send it." You end up gluing scripts around a tool that wasn't designed for this shape of problem, which is its own maintenance burden.

Option 4: a dedicated approval-gate service

The fourth option is a service built specifically for this loop: agent proposes, human decides, agent executes only on approval — nothing else. Impri is this option. It exists so you don't build the table, the Slack bot, the diff view, and the audit log yourself:

curl -X POST https://api.impri.dev/v1/actions \
  -H "Authorization: Bearer $IMPRI_API_KEY" \
  -d '{
    "kind": "email.send",
    "title": "Reply to support ticket #4821",
    "preview": { "format": "markdown", "body": "Hi Jordan, thanks for..." },
    "editable": ["preview.body"],
    "expires_in": 3600
  }'

Three calls — push, poll, report — and you get a mobile-friendly inbox, human edits with a diff, notification channels (Slack, Telegram, Discord, email, push), and an audit trail, without owning that surface yourself. It's honestly narrow, though: Impri is only the gate. It does not generate the draft or orchestrate multi-step workflows — pair it with n8n or your own agent code for that, the same way you would with a DIY table.

Which one to pick

Situation	Alternative
Already orchestrating agent steps in n8n/Temporal	Use the engine's HITL node
One action kind, one reviewer, prototype only	Roll your own — but budget for it to grow
Existing approval tooling with spare capacity	Repurpose it, expect glue code
Need mobile approve/reject, audit log, human edits, multiple channels	Dedicated gate — see the minimal integration

If you're weighing this decision in more depth — including the actual engineering-hours math — see build vs. buy for an AI agent approval queue. For the mechanics of wiring a gate into your agent once you've picked one, the MCP integration is the fastest path if your agent already runs inside an MCP client.

Human-in-the-Loop vs Full Autonomy for AI Agents

sekera-radim — Sun, 06 Sep 2026 09:50:03 +0000

Deciding when an AI agent should act on its own versus wait for a human — a risk-based framework with concrete thresholds, not a blanket policy.

"Should this agent be autonomous?" is the wrong question

It's usually asked about the whole agent — "is our support bot autonomous or not?" — when the honest answer is almost always "it depends which action." A support agent that looks up order status needs no gate. The same agent issuing a refund does. Treating autonomy as a single on/off switch for an entire agent either blocks it on things that don't matter, which trains reviewers to rubber-stamp everything, or lets it run free on things that do.

The more useful unit isn't the agent, it's the action.

A risk-based framework

Sort actions by two things: how hard they are to undo, and how bad it is if the agent is wrong. Gate on that, not on how impressive the agent's reasoning looked in the transcript.

Risk tier	Example action	Reversible?	Autonomy level
Low	Read a record, draft a reply, query an API	Yes — no side effect	Full autonomy
Medium	Post a scheduled tweet, update a CRM field	Yes — can be edited/deleted after	Autonomy with logging, spot-check
High	Send an email, post publicly, message a customer	Hard — the recipient already saw it	Human-in-the-loop, every time
Critical	Refund a charge, delete a record, deploy code	No, or expensive	Human-in-the-loop, no exceptions

Most teams that say "our agent is fully autonomous" mean the low tier. Most teams that say "we require approval for everything" are gating the low tier too, which is why reviewers stop reading the cards after a week.

Encoding the framework, not just describing it

The point of a framework is that it's checkable in code, not just written in a doc nobody rereads. A minimal router looks like this:

import os
from impri import ImpriClient

impri = ImpriClient(api_key=os.environ["IMPRI_API_KEY"])

# Tier lookup keyed by action kind — the actual policy, in one place
GATE_REQUIRED = {
    "record.read": False,
    "crm.field_update": False,
    "email.send": True,
    "social.post": True,
    "payment.refund": True,
    "record.delete": True,
}

def run_action(kind: str, title: str, preview_body: str, execute_fn):
    if not GATE_REQUIRED.get(kind, True):  # unknown kinds default to gated
        return execute_fn(preview_body)

    action = impri.actions.create(
        kind=kind,
        title=title,
        preview={"format": "markdown", "body": preview_body},
        editable=["preview.body"],
        expires_in=3600,
    )
    decision = impri.actions.await_decision(action.id, timeout_s=1800)
    if decision.status != "approved":
        return None  # rejected or expired — never executed

    result = execute_fn(decision.final_preview["body"])
    impri.actions.report_result(action.id, status="executed")
    return result

The default (True for unknown kinds) matters more than the table: a new action kind nobody classified yet should fail toward asking, not toward running.

Where full autonomy still needs a leash

Even low-risk actions benefit from a ceiling, not because any single one is dangerous, but because volume changes the risk profile. A hundred read-only lookups a minute is fine; a hundred emails a minute from an agent stuck in a loop is not, no matter how each individual email looked. Rate limiting the write path — Impri caps POST /v1/actions at 60/minute per key — catches exactly this failure mode even for tiers you've decided don't need per-action review. See guardrails for real-world agent actions for the broader pattern.

Where human-in-the-loop is non-negotiable

Two conditions make the gate mandatory rather than a judgment call: the action is hard to undo, and the input the agent is acting on is untrusted. An agent drafting a refund based on a customer's own support ticket is one thing; an agent drafting a refund based on a scraped web page that could contain injected instructions is another. Content from RSS feeds, web pages, or public forums should always route through a gate before it triggers a side effect — see preventing prompt injection from executing actions.

What this framework doesn't solve

Choosing the right tier is still a judgment call, and Impri doesn't make that call for you — it holds the decision once you've decided an action needs one. It also doesn't rewrite the table when your product changes; a crm.field_update that seemed low-risk becomes high-risk the day that field starts triggering an automated billing change downstream. Revisit the table when the consequences of an action change, not just when the action itself changes.

For the mechanics of defining these tiers as enforced rules rather than an inline dictionary, see rules.

Next step: quickstart to get an API key, then wire the router above around your riskiest action kind first.

AI Agent Approval Queue: Build vs Buy

sekera-radim — Fri, 04 Sep 2026 16:30:02 +0000

Weighing whether to build an AI agent approval queue in-house or buy one — the real cost, from schema design to Slack polling to what teams forget.

The question isn't "can we build it"

Any team with a Postgres instance and a Slack webhook can build a table that says status = pending, notify someone, and update a row when they click a button. That part takes an afternoon. The question that actually matters is what happens in the following six months, once the first edge case shows up: an action that should have expired but didn't, a reviewer who edited a draft and the agent executed the original anyway, an audit log that's missing the one action someone needs to explain to a customer.

What building actually requires

The minimal version is deceptively small. The complete version — the one that survives contact with a real agent in production — needs more:

Component	Why it's not optional
Queue storage with expiry	Stale approvals ("yes" on a two-day-old draft) are worse than no approval
Notification fan-out	Email-only means missed approvals; you'll want Slack, push, or SMS eventually
Edit-then-approve	Reviewers rewrite drafts more often than they reject them outright
Diff between original and edited	Otherwise nobody can tell what changed before they approve it
Audit trail	The first time compliance or a customer asks "who approved this," you need an answer that isn't a Slack scrollback
Rate limiting	An agent stuck in a retry loop shouldn't be able to spam the queue
Idempotent execution guard	Approve-twice or retry-after-timeout shouldn't send the same email twice

None of these are hard individually. Together, they're a small service with its own on-call surface — for a piece of infrastructure that isn't your product.

Here's roughly what the in-house version starts to look like once you get past the happy path:

// approval-queue/schema.ts — the "simple" version, six weeks in
interface PendingAction {
  id: string;
  kind: string;
  originalPayload: Record<string, unknown>;
  editedPayload?: Record<string, unknown>;   // reviewers edit drafts
  editDiff?: string;                          // ...and you have to show what changed
  status: 'pending' | 'approved' | 'rejected' | 'expired';
  expiresAt: Date;                            // needs a sweep job to enforce
  notifiedVia: ('slack' | 'email' | 'sms')[];  // fan-out, retried on failure
  executedAt?: Date;                          // idempotency guard for double-approval
  auditEvents: { actor: string; action: string; at: Date }[];
}

// Plus: the sweep cron for expiry, the Slack interactivity endpoint,
// the retry logic for failed notifications, and the admin view for
// "who approved this" — none of which are in this file.

That file is the easy 20%. The Slack interactivity endpoint, the expiry sweep, the retry-safe notification fan-out, and the admin audit view are the other 80%, and they're the parts that turn into a maintenance burden nobody signed up for.

What buying gets you on day one

Impri's REST API collapses that entire list into three calls: push the action, poll for a decision, report the result. Expiry, editable drafts with diffs, audit log, and rate limiting are already handled server-side — see the full integration walkthrough for the exact request shapes.

import { ImpriClient } from "@impri/sdk";

const impri = new ImpriClient({ apiKey: process.env.IMPRI_API_KEY });

const action = await impri.actions.create({
  kind: "email.send",
  title: "Weekly digest to enterprise-tier customers",
  preview: { format: "markdown", body: draftBody },
  editable: ["preview.body"],
  expires_in: 86_400,
});

const decision = await impri.actions.awaitDecision(action.id, { timeoutS: 3600 });
if (decision.status === "approved") {
  await sendEmail(decision.final_preview.body); // human-edited version, not the original
  await impri.actions.reportResult(action.id, { status: "executed" });
}

Same guarantees as the schema above, minus the six weeks and the on-call rotation. See the TypeScript SDK reference for the full client surface.

When building actually makes sense

Buying isn't universally right. If approvals are core to your product — you're building a moderation platform, not using one — owning that logic is the point, not overhead. If you need branching, multi-step orchestration, or agent-to-agent handoffs, that's a workflow engine's job (n8n, Temporal, Inngest), not an approval queue's; Impri is deliberately narrow and can sit as one step inside a broader workflow rather than replace it. And if compliance requires the data to never leave your infrastructure, the self-hosted option keeps the build-vs-buy calculus but skips the "who's on call for this" part.

The honest boundary

Impri stores the proposed action, notifies a human, and holds the decision — it doesn't generate content or execute anything itself. Wiring the actual send/post/publish call, and making sure the agent has no path around the gate, is still your integration work either way. Buying removes the queue infrastructure, not the responsibility for the chokepoint.

Next step: quickstart to get an API key and push your first action in under five minutes.

A Self-Hosted Approval Inbox for AI Agents

sekera-radim — Thu, 03 Sep 2026 23:30:03 +0000

Run your own approval inbox for AI agents — Impri's MIT core is self-hostable in minutes, with the same REST API and MCP server as the cloud.

Why run it yourself

The cloud at impri.dev is the fastest way to get started. But there are reasons to prefer running Impri on your own infrastructure:

Data stays internal. Every action pushed to Impri includes the draft content your agent produced — an email body, a database query, a file to be modified. For agents working with internal documents, customer records, or anything under compliance review, you may not want that content leaving your network at all.

No per-seat or per-action cost at scale. If you run a high-volume agent loop that produces hundreds of approval requests per day, self-hosting removes that ceiling.

Integration with internal tooling. Running on-prem means you can put Impri behind your VPN, use your own SSO, and configure notification channels that point to internal Slack or ntfy instances.

Impri is open-core: the server that handles the approval inbox, the REST API, the MCP server, and the web UI is MIT-licensed and available at github.com/sekera-radim/impri. The hosted version at impri.dev runs the same code with managed infrastructure on top.

Running the server

The server is distributed as a Docker image. A single container handles the REST API and the web inbox.

docker run -d \
  --name impri \
  --restart unless-stopped \
  -p 8484:8484 \
  -v impri_data:/data \
  -e SECRET_KEY=$(openssl rand -hex 32) \
  ghcr.io/sekera-radim/impri:latest

The server starts on port 8484. The /data volume persists actions, decisions, and audit records across container restarts. SECRET_KEY signs sessions — generate once and store it somewhere safe (not in the command history for production use).

After the container is running, open http://localhost:8484 to create your first API key via the web UI. You'll use that key in the Authorization: Bearer im_... header the same way you would with the cloud.

For a compose file, reverse proxy config, and production hardening notes, see self-hosting.

Pointing your agents at the local instance

Wherever you set IMPRI_BASE_URL, switch it to your instance's address. The rest of the API is identical.

MCP server (Claude Code, Claude Desktop, or any MCP client):

{
  "mcpServers": {
    "impri": {
      "command": "npx",
      "args": ["@impri/mcp"],
      "env": {
        "IMPRI_API_KEY": "im_your_local_key",
        "IMPRI_BASE_URL": "http://localhost:8484"
      }
    }
  }
}

The MCP server reads IMPRI_BASE_URL and routes all tool calls — impri_push_action, impri_await_decision, impri_report_result — to your instance instead of the cloud. No code changes needed in the agent.

REST directly — useful for testing that the instance is up and accepting requests:

# Verify connectivity
curl http://localhost:8484/v1/actions \
  -H "Authorization: Bearer im_your_local_key"

# Push a test action — here an internal database migration awaiting sign-off
curl -X POST http://localhost:8484/v1/actions \
  -H "Authorization: Bearer im_your_local_key" \
  -H "Content-Type: application/json" \
  -d '{
    "kind": "db.migration",
    "title": "Run migration: add_user_preferences_table",
    "preview": {
      "format": "markdown",
      "body": "```

sql\nALTER TABLE users ADD COLUMN preferences JSONB;\nCREATE INDEX idx_user_preferences ON users(id)\n  WHERE preferences IS NOT NULL;\n

```"
    },
    "expires_in": 3600,
    "editable": []
  }'

The response is { id, status: "pending", inbox_url } — the same shape as the cloud. Poll GET /v1/actions/:id until status is no longer "pending", then execute only on "approved".

What you get vs. the cloud

Capability	Self-hosted (MIT core)	Cloud (impri.dev)
REST API (`/v1/actions`)	Yes	Yes
MCP server (`@impri/mcp`)	Yes	Yes
Web inbox	Yes	Yes
Audit log	Yes	Yes
Notifications (email, ntfy, web push)	Yes — configure your own SMTP/ntfy	Managed
Slack / Telegram / Discord approval	Yes	Yes
Infrastructure management	You	Managed
Uptime SLA	Your infra	Covered

The split is operational, not functional. A self-hosted instance accepts the same requests, stores decisions in the same schema, and exposes the same inbox UI. You configure your own notification channels — see notifications for the available options.

Honesty about what Impri is and is not

Running Impri yourself doesn't change what it does. It stores the proposed action, notifies the designated human, and holds the decision. It does not interpret what the agent is doing, does not generate or modify content, and does not execute anything.

The gate is real only when the agent's path to the side effect runs through the Impri response. If you run the server behind your firewall but your agent also holds direct credentials to the target system, the gate does not enforce anything — it just records what was proposed.

Impri is a focused tool: one human, one decision, one proposed action at a time. It is not a workflow engine with branching or scheduling (look at n8n or Temporal for those), and it is not an agent-to-agent coordination layer. You can embed it as one step inside a larger workflow. For compliance-sensitive environments, pair it with audit-log to export decision records.

Next step

Follow the self-hosting guide for compose file, reverse proxy, and environment variable reference. To wire up your first agent, start with the quickstart (the examples work against either the cloud or a local instance — just set IMPRI_BASE_URL). To use the MCP server with Claude Code or Claude Desktop, see mcp.

Open-Source Human-in-the-Loop Tools for AI Agents

sekera-radim — Thu, 03 Sep 2026 07:30:02 +0000

Comparing open-source human-in-the-loop tools for AI agents — from framework-native pause points to dedicated, self-hostable approval gates you wire in directly.

Two different things get called "human-in-the-loop"

Search for open-source human-in-the-loop tooling and you'll get two categories that solve different problems. The first is a pause point inside an agent framework — a way to stop a graph or chain mid-run and wait for input before continuing. The second is a standalone approval gate — a small service that sits between "agent decided to do X" and "X actually happens," independent of which framework built the agent. Which one you need depends on whether the thing you're gating lives inside one framework's run loop or has to work the same way regardless of what produced the action.

Framework-native pause points

If your agent is already built on a specific framework, that framework likely has some mechanism for pausing on a step:

LangGraph has interrupt/checkpoint support for pausing a graph at a node and resuming once external input arrives — useful if your whole system is already a LangGraph graph, since the pause is a native part of the graph's state machine.
CrewAI supports human input on a task before the crew proceeds — the crew blocks in-process waiting for a response.
AutoGen has a user-proxy agent pattern where a human (or human-driven process) sits in the conversation loop as one of the participants.

These are genuinely useful, and if you're all-in on one framework they're the path of least resistance. The tradeoff: the pause lives inside that framework's process. There's usually no built-in mobile notification, no audit trail independent of your app logs, and no shared review surface if you run agents across more than one framework or language.

Workflow-engine HITL nodes

If your agent action is a step inside a larger orchestrated workflow, the workflow engine may already have an approval primitive: n8n has a human-in-the-loop / wait-for-approval node, and Temporal supports pausing a workflow execution on a signal that a human (or a service acting for one) sends later. These work well when the agent step is genuinely embedded in a bigger workflow — but they pull in the whole orchestration engine even if your only need is "pause this one action for a yes/no."

Dedicated approval-gate services

The alternative is a small service whose only job is holding the decision — framework-agnostic, callable from a bash script, a Python agent, a TypeScript MCP tool, or a cron job, all the same way. Impri is one (MIT-licensed self-hostable core, hosted option at impri.dev): it stores the proposed action, notifies a human across email/Slack/Telegram/Discord/push, and returns a decision your agent polls for. No framework dependency, no workflow engine required.

import os, time, requests

BASE = os.environ.get("IMPRI_BASE_URL", "http://localhost:8484")
HEADERS = {"Authorization": f"Bearer {os.environ['IMPRI_API_KEY']}"}

def propose_action(kind, title, body):
    resp = requests.post(f"{BASE}/v1/actions", headers=HEADERS, json={
        "kind": kind,
        "title": title,
        "preview": {"format": "markdown", "body": body},
        "expires_in": 3600,
    })
    return resp.json()["id"]

def wait_for_decision(action_id):
    while True:
        resp = requests.get(f"{BASE}/v1/actions/{action_id}", headers=HEADERS)
        data = resp.json()
        if data["status"] != "pending":
            return data
        time.sleep(10)

action_id = propose_action("post.publish", "Publish weekly digest", "## This week...\n...")
decision = wait_for_decision(action_id)
if decision["status"] == "approved":
    publish(decision["decision"]["final_preview"]["body"])

Running the base URL against localhost:8484 means this is the self-hosted core — no cloud dependency at all. Self-hosting covers running it with Docker.

Comparison at a glance

Tool	Scope	Self-hostable	Works outside its framework
LangGraph interrupts	Pause within a LangGraph graph	Yes (it's your app)	No — tied to the graph
CrewAI human input	Pause within a crew task	Yes (it's your app)	No — tied to CrewAI
AutoGen user proxy	Human as a conversation participant	Yes (it's your app)	No — tied to AutoGen
n8n HITL node	Approval step inside an n8n workflow	Yes	Only as an n8n node
Impri	Dedicated approval gate	Yes (MIT core)	Yes — REST/MCP, any language

Picking one

If your agent lives entirely inside one framework and never needs to be reviewed from outside that process, the native pause point is less to set up. If you run agents across multiple frameworks, languages, or scripts and want one review inbox, one audit trail, and one notification path regardless of what produced the action, a dedicated gate is the better fit — and you can still call it from inside a LangGraph node or an n8n workflow as one step. See integrations for wiring it into an existing agent SDK, or the MCP server if your agent runs inside an MCP client.

Next step

Quickstart gets a self-hosted instance or a cloud key running in a few minutes either way.

Human-in-the-Loop for Personal AI Assistants

sekera-radim — Tue, 01 Sep 2026 17:30:05 +0000

A personal AI assistant that texts contacts, pays bills, or drafts emails needs a human-in-the-loop check before it acts — here's the minimal pattern to add one.

Personal assistants have a different risk profile than business agents

Most human-in-the-loop writing targets teams: a support bot issuing refunds, a marketing agent posting to a brand account. A personal AI assistant is different in a way that makes approval more important, not less: it acts on your behalf with your accounts, your contacts, and your money, and there's no second reviewer, no compliance team, no one else who'd notice if it sent the wrong text to the wrong person. You are the only backstop.

That also means the approval step has to be lightweight enough that you'll actually use it — a phone notification you can tap, not a dashboard you have to open. The mechanics are the same three calls as any agent integration: push the action, wait for a decision, execute on approval.

Wiring it into a personal assistant

Say your assistant handles reminders and can text people on your behalf (via Twilio, iMessage bridge, whatever). Before it sends, it proposes the message and waits:

async function proposeText(to: string, body: string) {
  const res = await fetch("https://api.impri.dev/v1/actions", {
    method: "POST",
    headers: {
      Authorization: `Bearer ${process.env.IMPRI_API_KEY}`,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({
      kind: "sms.send",
      title: `Text to ${to}: reschedule reminder`,
      preview: { format: "plain", body },
      editable: ["preview.body"],
      expires_in: 1800, // 30 min — a reminder text is time-sensitive
    }),
  });
  const { id, inbox_url } = await res.json();
  return id;
}

async function waitForDecision(actionId: string) {
  while (true) {
    const res = await fetch(`https://api.impri.dev/v1/actions/${actionId}`, {
      headers: { Authorization: `Bearer ${process.env.IMPRI_API_KEY}` },
    });
    const data = await res.json();
    if (data.status !== "pending") return data;
    await new Promise((r) => setTimeout(r, 10_000));
  }
}

const actionId = await proposeText("+1555...", "Hey, can we move lunch to 1pm?");
const decision = await waitForDecision(actionId);

if (decision.status === "approved") {
  await sendSms(decision.decision.final_preview.body); // your Twilio call
}

The editable: ["preview.body"] field matters here specifically — a reminder text your assistant drafted might have the wrong tone or a typo'd name, and you'd rather fix it inline on your phone than reject and re-prompt the whole assistant.

New to the flow? The full integration guide covers REST and MCP end to end.

Where this matters for a personal assistant specifically

Assistant action	Approve first?
Draft a text/email reply	Yes — tone and accuracy matter, low cost to check
Pay a bill or send money	Yes — irreversible, use `idempotent: false`
Add a calendar event	Often skip — low stakes, easy to undo
Delete a photo or file	Yes — irreversible
Order something online	Yes, especially above a $ threshold you set
Read-only lookup (weather, search)	No — nothing to approve

The judgment call is yours: gate the actions that are hard to undo or embarrassing to get wrong, skip the ones that aren't. Approve from your phone covers the notification side so the tap-to-approve loop is actually fast enough to use daily.

What this doesn't give you

Impri is the approval gate, not the assistant. It doesn't know your contacts, doesn't draft the text, and doesn't decide what "looks wrong" — it just holds the proposed action until you decide and hands back exactly what you approved (including any edits you made). It's also only a real gate if your assistant's SMS/email/payment code path requires the approved decision to run — if the assistant still holds a raw Twilio key it could call directly, wrap that credential so the approval step is the only door through.

If your assistant also texts on a schedule unattended (nightly digest, morning reminders), see gate a cron job with human approval for handling actions that fire while you're asleep.

Next step

Start with the quickstart to get an API key, then wrap whichever action in your assistant is the one you'd least want to happen automatically.

Human Approval for Solo-Founder AI Automations

sekera-radim — Tue, 01 Sep 2026 17:30:03 +0000

Running support replies, invoice follow-ups, and social posts through separate AI agents only works solo if you can review all of it in one five-minute morning sweep instead of babysitting each one live.

The problem is review time, not automation

A solo founder running three or four small agents — a support-ticket responder, an invoice-chasing bot, a social post drafter — doesn't have the bandwidth to sit and watch each one work. But "fully unsupervised" isn't the answer either: one hallucinated refund promise in a support reply, one invoice sent to the wrong customer, one tone-deaf tweet, and you're doing damage control instead of building. What actually scales for one person is a single queue you clear in a batch, not three separate places to check.

One inbox, one pass, every action gated the same way

Every agent pushes its proposed action to Impri instead of executing directly, regardless of which agent produced it. You get one inbox — web, mobile, or wherever notifications land — and one decision loop instead of three integrations to babysit. Because the gate is identical across agents (kind differs, the shape doesn't), you write the wrapper once and reuse it.

import os
from impri import ImpriClient

client = ImpriClient(api_key=os.environ["IMPRI_API_KEY"])

async def propose_support_reply(ticket_id: str, customer_email: str, draft_body: str):
    action = await client.create_action(
        kind="support.reply",
        title=f"Reply to ticket #{ticket_id} ({customer_email})",
        preview={"format": "markdown", "body": draft_body},
        payload={"ticket_id": ticket_id, "customer_email": customer_email},
        editable=["preview.body"],
        expires_in=43200,  # 12 hours — long enough to survive an overnight batch
    )
    return action.id

async def propose_invoice_followup(invoice_id: str, customer: str, days_overdue: int, draft_body: str):
    action = await client.create_action(
        kind="invoice.followup",
        title=f"Chase {customer}: invoice {invoice_id} ({days_overdue}d overdue)",
        preview={"format": "markdown", "body": draft_body},
        editable=["preview.body"],
        expires_in=86400,
    )
    return action.id

async def propose_social_post(platform: str, draft_body: str):
    action = await client.create_action(
        kind="social.post",
        title=f"Post to {platform}",
        preview={"format": "plain", "body": draft_body},
        editable=["preview.body"],
        expires_in=21600,  # stale drafts aren't worth posting a day later
    )
    return action.id

Three agents, three kind values, one create_action call shape. Nothing executes until the corresponding decision comes back approved.

Clearing the queue in one pass, not three

This is where a solo founder's workflow diverges from a team's: nobody else is going to triage the inbox for you, so the morning routine has to be a single batch clear, not a card-by-card review across separate tools. Impri's bulk-decision endpoint approves or rejects several actions at once from a script, which is the shape a "review everything with coffee" habit actually needs:

pending = await client.list_actions(status="pending", kind="support.reply")
approve_ids = [a.id for a in pending.items if looks_routine(a.preview.body)]

if approve_ids:
    resp = client.bulk_decide(ids=approve_ids, verdict="approve", comment="morning batch")
    print(f"approved {resp['succeeded']}, failed {resp['failed']}")

Actions with editable fields still route through per-item decide() if you want to hand-edit one before approving — bulk_decide intentionally skips edits so a batch approval can't silently rewrite fifty drafts at once. In practice: skim the inbox, bulk-approve the obviously-fine replies, open the two that need a tweak individually, reject the rest. That's the whole morning review.

Why "just trust the agent" doesn't hold at this scale

The instinct to skip a gate entirely is strongest for a solo founder — every extra step feels like it's eating the time automation was supposed to save. But the actions with the most damage per mistake (a wrong refund commitment, a duplicate invoice chase, a post that goes out with the wrong numbers) are exactly the ones a solo operator has the least slack to walk back publicly and alone. A five-minute batch review is cheap insurance against the one incident that costs a weekend.

What this isn't

Impri doesn't decide which replies are routine, doesn't write the invoice-chase copy, and doesn't know your Twitter voice — your agents own all of that. It stores the proposed action, notifies you, and holds the decision until you clear the queue. And the gate only holds if the agent's actual send/post credentials live behind the approved-decision check, not in the agent's own reach — see integrations for wrapping the executor so there's no side door around it.

Agent	`kind`	Typical review
Support responder	`support.reply`	Bulk-approve routine ones, edit the rest
Invoice chaser	`invoice.followup`	Bulk-approve, reject anything past a write-off threshold
Social drafter	`social.post`	Individual review — tone matters more than volume

Next: quickstart to get an API key, the Python SDK for the full client including bulk_decide, and notifications to route the whole queue to one phone.