DEV Community: orbiresearch

The kill switch pattern, and why your CIO needs to know where it is at 3 AM

orbiresearch — Fri, 16 Oct 2026 07:15:03 +0000

"You need a kill switch. And you need someone who knows how to use it. The CIO should know where that kill switch is, and multiple people should know where it is if it goes sideways."

That is John Bruggeman, CISO at CBTS, in a recent interview about AI operational risk. He is right. He is also describing a control that almost nobody in the agent ecosystem has actually built.

This is the pattern, end to end.

§ 01 · What a kill switch actually is

A kill switch is not a button on a dashboard. It is not "ssh into the server and kill the process." It is a runtime control that satisfies four properties.

Atomic. One action stops the agent. Not a sequence of seven steps. Not a Slack message to engineering. One action.

Authoritative. When the kill switch fires, the agent stops. There is no negotiation, no graceful degradation, no "let me finish this turn first." The runtime forcibly terminates the agent's loop and revokes its credentials.

Observable. Everyone who needs to know that the kill switch fired, knows. The on-call rotation, the SRE channel, the audit log, the affected downstream systems. No silent kills.

Reversible at the system level, not the agent level. Pulling the switch should not corrupt the data the agent was writing to. The runtime needs to handle in-flight transactions cleanly, either committing them with a marker or rolling them back to a known-good state.

If your kill switch satisfies fewer than four of these, it is not a kill switch. It is a stop button on a vending machine.

§ 02 · The three failure modes a kill switch must handle

A kill switch is not just "the agent is doing something I do not like." It is a response to one of three specific failure modes, each of which has different signals.

Mode 1: goal drift. The agent is technically doing what you asked, but the cumulative effect is no longer what you wanted. The Elloe AI Lab paper this week put hard numbers on this: nearly 90% of tested agents showed measurable goal drift after about 30 steps. The signal is usually a slow degradation in some downstream metric, visible only if you are looking at trend lines rather than individual actions.

Mode 2: tool surface compromise. The agent has been redirected by adversarial input, a memory-poisoning attack, a prompt injection in retrieved content, a malicious tool response. The signal is anomalous tool call patterns, especially calls to destructive or high-privilege tools that the agent does not normally use. This is the failure mode that 94% of memory-retentive agents are vulnerable to, per the same paper.

Mode 3: cascading economic damage. The agent is doing exactly what it was designed to do, at scale, but the unit economics broke and nobody noticed. The classic example is the beverage manufacturer whose vision system kept ordering production runs because new holiday labels confused it, several hundred thousand excess cans before anyone caught it. The signal is volume, not anomaly. The actions look normal individually.

A single kill switch design does not handle all three. Mode 1 needs trend-based triggers. Mode 2 needs anomaly detection on tool calls. Mode 3 needs hard rate limits on the tools themselves. You need all three.

§ 03 · The implementation, in three layers

Here is how I build this in our four-layer architecture.

Layer I (Miro): the kill paths are mapped. Every agent diagram includes the kill paths as first-class elements. Not as an afterthought in the corner. The whiteboard answers: who can pull the switch? What signals trigger an automatic pull? What state does the system enter after the pull?

Layer II (Notion): the protocol is documented. A SOUL.md section dedicated to kill switch operation. Names of the on-call humans. Slack channel. Phone numbers. The runbook for what to do in the first five minutes after the switch fires. This sounds like security theater. It is not. At 3 AM, when something is wrong and the on-call engineer is half-asleep, the runbook is the difference between a 15-minute incident and a 4-hour incident.

Layer IV (Hermes): the tools enforce it. A kill endpoint on the agent runtime that does the four things from §01. Credentials revocation, in-flight transaction handling, downstream notification, audit logging. Plus rate limits on every destructive tool, with hard caps that fire automatically when exceeded. The agent does not need a human to pull a switch if its delete_records tool refuses to execute past 100 calls per hour.

§ 04 · The team protocol that makes it work

The technical pattern is the easy part. The team protocol is harder.

Three rules from incidents I have lived through.

Rule 1: at least three people know how to pull the switch, and at least two of them are not on the engineering team. The CIO and the head of operations should be on this list. If only engineering can stop the agent, you have a single point of failure that is also the team most likely to be biased toward "let me try one more fix first."

Rule 2: pulling the switch is never blamed. If the on-call engineer pulls it and it turns out to be a false alarm, that is fine. Better to false-positive on a kill than to false-negative on a real incident. Cultures that punish unnecessary kills get fewer kills, including the necessary ones.

Rule 3: the switch is tested monthly. Not in production. In a staging environment with realistic traffic. Every month. If you have not pulled the switch in the last 30 days, you do not know if it works. Fire drills are not optional.

§ 05 · What this looks like in practice

For our manufacturing client (the Lead Discovery Agent in §01 of /cases), the kill switch is wired into three triggers. A manual pull from the operations dashboard. An automatic pull when outbound message volume exceeds 3x the seven-day average. An automatic pull when any single contact receives more than two messages in a 24-hour window.

The third trigger fired once in the last six months. A bug in the deduplication logic was about to send the same lead a fourth follow-up. The switch caught it before it sent. The bug was fixed in 90 minutes. The client never noticed.

That is what a working kill switch looks like. Most of the time, it does nothing. The one time it matters, it saves the engagement.

If your production agent does not have one, you are operating without a seatbelt. The crash you are not having yet is not evidence that the seatbelt is unnecessary. It is evidence that you have been lucky.

Originally published on the OrbiResearch Lab. We build production AI agents at orbiresearch.com.

The identity forgery pattern: why your agent's credentials need an expiry, not just a scope

orbiresearch — Tue, 13 Oct 2026 07:15:04 +0000

§ 01 · The problem

Most teams scope an agent's credentials carefully, read-only here, write access there, this API but not that one. Scope answers "what can this agent do." It does not answer "how long is this credential good for" or "can I tell this agent apart from a copy of itself." Both of those gaps are how identity forgery happens: a credential gets replayed, cloned into a second process, or reused long after the task it was issued for has finished.

── The standing key ──

§ 02 · Why scope alone isn't enough

A tightly scoped credential with no expiry is still a standing key. If it leaks, into a log, a prompt, a tool-output, a forked process, it stays valid until someone notices and revokes it manually. In practice, nobody notices for days. Scope limits the blast radius of a single call. It does nothing to limit the blast radius of time.

── The pattern ──

§ 03 · The pattern

Treat every agent credential as short-lived by default, not as a static secret with a scope attached.

1. Issue per-session, not per-agent. A credential is minted when a run starts and dies when it ends, not a long-lived key the agent reuses across every run.

2. Set an expiry shorter than your longest expected task. If your agent's longest normal run is 20 minutes, the credential expires at 30. A stuck or hijacked process cannot keep operating past that window even if nobody is watching.

3. Bind the credential to a run_id. Every credential carries the identifier of the specific run that issued it. If two requests arrive using the same credential from two different process contexts, that's not a scaling event, it's a forgery signal, and it should fail loud, not fail open.

4. Log every credential issuance and every use separately. Issuance tells you what should be able to act. Usage tells you what did act. The gap between those two logs is where forgery hides.

5. Revoke on completion, not on schedule. Don't wait for a cron job to clean up expired credentials, revoke the moment the run reports done, failed, or killed.

── What this catches ──

§ 04 · What this catches that scope doesn't

A well-scoped but long-lived credential still lets an attacker who steals it act indefinitely, within scope, indistinguishable from the legitimate agent. A short-lived, run-bound credential turns "stolen and replayed" into "stolen and useless within the hour", and turns "cloned into a second process" into an immediate, loud signal instead of a silent duplicate.

── The hard case ──

§ 05 · Where this gets hard

Long-running agents, the ones that legitimately operate for hours or days, break the simple "session-length expiry" rule. For those, don't extend the expiry window; rotate the credential on a fixed interval within the run instead, the same way a long-lived TLS session rotates keys without dropping the connection. The rule stays the same: no credential should outlive its usefulness by more than a few multiples of a normal task.

── Checklist ──

§ 06 · Checklist

[ ] Does every agent credential expire, independent of its scope?

[ ] Is the expiry window shorter than your longest normal task, not your longest possible one?

[ ] Is every credential bound to a specific run_id?

[ ] Do you log issuance and usage as two separate events you can diff against each other?

[ ] For long-running agents, do you rotate credentials mid-run instead of issuing one that lives for the whole duration?

── End of pattern ──

◆ If any answer is no, an attacker doesn't need to break your agent's logic, they just need to find a credential nobody thought to expire.

ORBIRESEARCH

Originally published on the OrbiResearch Lab. We build production AI agents at orbiresearch.com.

The payment authorization pattern: giving an agent a wallet without giving it your bank account

orbiresearch — Fri, 09 Oct 2026 07:15:02 +0000

§ 01 · Why this matters now

Agent-initiated payments stopped being hypothetical this year. Protocols for autonomous agent transactions are shipping with real adoption, and industry alliances are forming specifically around agent-driven commerce. If your agent roadmap touches purchasing, subscriptions, refunds, or vendor payments, even narrowly, you need an authorization architecture before you need a use case, because retrofitting one after the first bad transaction is much more expensive. For a worked example, read about an agent that approved its own refund.

── The naive version ──

§ 02 · The naive version, and why it fails

The naive approach gives the agent direct API access to a payment method, a stored card, a linked bank account, scoped to "this vendor" or "this category." It fails for the same reason unscoped file access fails: the agent's job is to interpret ambiguous instructions and act, and payment amounts are exactly the kind of number a misread instruction gets wrong. A scope restricts where money can go. It does nothing to restrict how much, how often, or whether a human should have seen this first.

── The pattern ──

§ 03 · The pattern

Separate "the agent can request a payment" from "the payment executes" with three independent limits, none of which the agent controls.

1. A hard ceiling per transaction. Set below the largest legitimate transaction you expect, not above it. The agent should never be able to construct a request that clears this ceiling, the limit lives in the payment layer, not in the agent's instructions.

2. A velocity limit, not just a size limit. One large payment and fifty small ones can both drain an account. Cap total spend per run, per day, and per vendor independently, the same way you'd rate-limit an API.

3. A human gate above a threshold, by default. Anything over your comfort ceiling routes to an approval queue instead of failing or executing. This is the same approval-queue pattern we've written about for other high-stakes actions, payments are simply the category where skipping it is most expensive.

── The wallet ──

§ 04 · What the wallet actually holds

Don't connect the agent to your actual payment account. Fund a dedicated, capped wallet or virtual card that the agent transacts against, agent payment protocols and virtual-card issuers both support this now. The wallet's maximum balance becomes your real worst-case exposure, independent of any logic bug in the agent itself. If the wallet holds $500, a broken agent can lose you $500, not your operating account.

── Reconciliation ──

§ 05 · Reconciliation is not optional

Every agent-initiated payment needs a machine-readable record of why, which run, which instruction, which approval (if any) authorized it, logged before the payment clears, not reconstructed afterward from a payment processor's dashboard. When a payment looks wrong three weeks later, you need to answer "what did the agent think it was doing" without guessing.

── Checklist ──

§ 06 · Checklist

[ ] Does a hard per-transaction ceiling live in the payment layer, outside the agent's control?

[ ] Is there a velocity limit, spend per run, per day, per vendor, not just a size limit?

[ ] Does anything above your comfort threshold route to a human by default?

[ ] Is the agent funded through a capped wallet or virtual card, never your main payment account?

[ ] Is the "why" behind every payment logged at authorization time, not reconstructed later?

── End of pattern ──

◆ An agent that can pay for something is an agent that can be wrong about money. Build the ceiling before you build the use case.

ORBIRESEARCH

Originally published on the OrbiResearch Lab. We build production AI agents at orbiresearch.com.

The agent-to-agent circuit breaker: what changes when your agent calls someone else's agent

orbiresearch — Tue, 06 Oct 2026 07:15:02 +0000

§ 01 · The assumption that just broke

Retry logic, timeouts, circuit breakers, the standard reliability toolkit, was designed around calling APIs with predictable failure modes. A 429 means slow down. A 500 means try again later. A timeout means the service is overloaded. None of that logic accounts for what happens when the thing you're calling is itself an agent: something that can fail slowly and confidently, returning a well-formed, plausible-looking wrong answer instead of an error code.

── The wrong signal ──

§ 02 · Why a standard circuit breaker doesn't catch this

A circuit breaker trips on error rate or latency. An agent-to-agent call that returns a confident, malformed, or subtly wrong result looks like a success to every metric a standard circuit breaker watches. The call didn't fail. It just didn't do what you needed, and your circuit breaker has no way to know that, because it's watching the wrong signal.

── The pattern ──

§ 03 · The pattern

Add a second failure category, quality failure, that trips independently of the standard error-rate breaker.

1. Validate the shape before you trust the content. Every response from an external agent gets checked against an expected schema before anything downstream touches it. This catches a large share of quality failures cheaply, before you need any semantic judgment at all.

2. Sample for semantic drift, don't just check the schema. Periodically, not on every call, that's too expensive, run a known-good test case through the external agent and compare the result against an expected answer. A schema-valid response that's drifted away from correct won't trip a shape check, but it will trip this.

3. Trip the breaker on quality failures, not just errors. When validation or sampling detects a bad result, treat it exactly like a 500 for circuit-breaker purposes, back off, fall back, or fail safe. Don't let "technically returned a 200" override "the content was wrong."

4. Never let one agent's failure silently propagate as another agent's fact. If agent A returns a low-confidence or failed-validation result, agent B should receive that as a flagged, uncertain input, not as ground truth to build the next decision on. Multi-agent systems that skip this step are how a false consensus forms: several agents individually operating "correctly" on a bad input none of them flagged.

5. Keep a fallback that doesn't depend on the failing agent. A cached last-known-good result, a simpler deterministic rule, or a human escalation, anything other than "retry the same agent and hope."

── Where it compounds ──

§ 04 · Where this matters most

The risk compounds with every additional agent in the chain. A single agent-to-agent call with a quality circuit breaker is a safety net. A four-agent pipeline where only the last hop validates anything is a system where an early, unflagged error gets progressively more confident-looking at each stage, exactly the failure mode we've seen in production multi-agent deployments that reach a wrong answer with more certainty than any single agent in the chain actually earned.

── Checklist ──

§ 05 · Checklist

[ ] Does every agent-to-agent call validate response shape before use?

[ ] Do you sample for semantic correctness, not just schema validity?

[ ] Does a quality failure trip your circuit breaker the same way an error code does?

[ ] Does a low-confidence result from one agent get passed downstream as uncertain, not as fact?

[ ] Is there a fallback path that doesn't depend on the same agent that just failed?

── End of pattern ──

◆ If your circuit breaker only watches HTTP status codes, it's blind to the failure mode that actually costs you in a multi-agent system.

ORBIRESEARCH

Originally published on the OrbiResearch Lab. We build production AI agents at orbiresearch.com.

What goes in an approval request: a short reason or a link to the trace?

orbiresearch — Fri, 02 Oct 2026 07:15:02 +0000

A reader left a comment on the approval queue post: should the request carry a short justification inline, or just link to the trace? Short answer: both, but they do different jobs, and they should never be mixed together in one block of text. Here is how we lay it out.

§ 01 · Two ways an approval request goes wrong

◆ Link only. The reviewer has to open a trace, scroll through tool calls and work out what happened before they can decide. Nobody does that forty times a day. They start approving from the title. The queue still exists, but it has stopped being a control.

◆ Reason only. The agent writes a tidy paragraph explaining why the action is fine. That paragraph is written by the same system that wants the action approved. It can be wrong, and it is usually persuasive. A reviewer who reads only that is being talked into the answer.

── ◆ ──

§ 02 · Split the request into three parts

◆ Facts the system computed. Amount, recipient, which record changes, whether it can be undone, and which policy rule sent it to a human. The agent does not write any of this. The gate does, from the tool call itself. This is the part the reviewer decides on. When the agent writes the amount instead, you get an agent that approved its own refund.

◆ The agent's reason, two lines at most. Labelled as the agent's claim. It shows intent, but it never carries the decision.

◆ A link to the trace. For the cases where the facts and the reason do not match, or something looks off. Most reviews should not need it. If more than one in five do, the facts section is missing something.

◆ On top of that, every request shows its deadline and what happens if nobody answers, as covered in the post on approval timeouts.

── ◆ ──

§ 03 · What it looks like

from dataclasses import dataclass

@dataclass
class ApprovalRequest:
    # computed by the gate from the tool call, never by the agent
    action: str          # "refund.issue"
    target: str          # "order 88214"
    amount: str          # "EUR 340.00"
    reversible: bool     # False
    triggered_by: str    # "amount above the 250 auto-approve limit"
    expires_at: str      # "2026-09-30T09:00Z"
    on_timeout: str      # "reject"

    # written by the agent, shown as a claim
    agent_reason: str    # trimmed to 200 characters

    # for the exceptions
    trace_url: str

def render(req: ApprovalRequest) -> str:
    undoable = "yes" if req.reversible else "no"
    return (
        f"{req.action} on {req.target}\n"
        f"Amount: {req.amount}   Undoable: {undoable}\n"
        f"Why it needs you: {req.triggered_by}\n"
        f"Agent says: {req.agent_reason[:200]}\n"
        f"If nobody answers by {req.expires_at}: {req.on_timeout}\n"
        f"Full trace: {req.trace_url}"
    )

The order matters. The facts come first and the agent's words come after them, with a label that says whose words they are.

── ◆ ──

§ 04 · Check that people actually read it

◆ Time to decision. If most approvals arrive within two or three seconds, nobody is reading. Track it per reviewer, not just as an average.

◆ Rejection and edit rate. A queue with zero rejections over several weeks is either a perfect agent or a rubber stamp. It is rarely the first.

◆ Planted requests. Once in a while, put in a request that should be rejected, with a wrong amount or the wrong recipient, and see whether it gets through. Tell reviewers that this happens, just not when. It is the only test that measures the control itself and not the agent.

── ◆ ──

§ 05 · When to leave the reason out

◆ For high value or hard to undo actions, consider showing the agent's reason only after the reviewer has looked at the facts, or dropping it altogether. A reason read first becomes the frame for everything after it.

◆ We do not have data on where that line should sit. We would start by showing it below the facts for every action type and tighten from there, using the planted requests to see whether it changes what gets through.

── ◆ ──

Facts from the system first. The agent's reason second, short and labelled as a claim. A trace link for the exceptions. A default for when nobody answers. Then measure whether anyone is actually reading.

The reference code for approval gates is in agent-reliability-patterns on GitHub, MIT licensed.

ORBIRESEARCH

Originally published on the OrbiResearch Lab. We build production AI agents at orbiresearch.com.

Approval timeouts: what your agent should do when nobody answers

orbiresearch — Tue, 29 Sep 2026 21:17:51 +0000

§ 01 · The missing fifth field

In the approval queue pattern I described four fields every approval item should carry: the action, the justification, the blast radius, and the confidence with an alternative. A reader on dev.to pointed out what was missing, and they were right. None of those fields answer a simple question: what happens when nobody answers?

Every real queue has items that age. People are in meetings, on holiday, or just busy. If you don't decide up front what an expired item turns into, the system decides for you, and it usually decides badly.

§ 02 · How queues rot without a timeout policy

There are two common ways this goes wrong.

◆ The graveyard. Nothing happens on timeout. Items pile up, the agent stalls, and after a few weeks people learn that the queue is where requests go to die. They stop looking at it, which is the opposite of what you built it for.

◆ The global auto-approve. Someone gets tired of the backlog and adds a rule: anything older than 24 hours gets approved. It feels practical. It also means the most dangerous item in the queue, the one nobody felt comfortable approving, now goes through automatically. You have rebuilt the rubber stamp, just with a delay.

In the original post I wrote that an SLA breach should escalate to a person and never auto-approve. I'd now make that more precise. For irreversible actions, that still holds. For some action types, a different default is the better answer.

── Defaults by reversibility ──

§ 03 · One default per action type

The fix is to give each action type its own timeout and its own default action, and to choose that default by asking one question: how expensive is it to undo this if the default turns out to be wrong?

In practice four defaults cover almost everything.

◆ Approve. For actions that are internal, reversible and low impact. Posting a summary to an internal dashboard, tagging a ticket, saving a draft. If nobody objects in time, the cost of doing it is close to zero and easy to reverse.

◆ Hold and escalate. For actions that leave your system or move money. Sending an email to a customer, issuing a refund, paying an invoice. These never go through on silence. On timeout, the item goes to the next person on the escalation list and keeps waiting.

◆ Cancel. For actions whose value expires. Booking a slot for today, replying to a quote request after the customer's deadline, reacting to a price that has already changed. Doing them late can be worse than not doing them. On timeout, the item is closed and the requester is told.

◆ Re-plan. For actions built on data that may now be stale. If a proposal was based on a stock level, a balance or a status from yesterday, approving it today can be wrong even if it was right when it was created. On timeout, the item goes back to the agent, which checks the facts again and creates a fresh request if it still makes sense.

The human who owns the queue picks the default per action type, in writing, before anything goes live. It is a product decision, not an engineering detail.

── Picking the numbers ──

§ 04 · Timeouts are per type, not global

One global SLA does not work, because a refund and a dashboard update do not deserve the same patience. Start with rough values per action type, for example 30 minutes for time sensitive customer replies, 4 working hours for refunds and 24 hours for internal changes, then tune them from real data.

The useful numbers are the median and the 90th percentile of how long approvals actually take for each type. If the 90th percentile is longer than the timeout, the timeout will fire on normal days, and people will start to ignore it. If the median is only a few seconds, reviewers are probably not reading, which is a different problem and a more serious one.

§ 05 · A small implementation

The policy is small enough to live next to the routing rules. A minimal version:

from dataclasses import dataclass
from datetime import datetime, timedelta
from enum import Enum

class OnTimeout(Enum):
    APPROVE = "approve"
    ESCALATE = "escalate"
    CANCEL = "cancel"
    REPLAN = "replan"

@dataclass(frozen=True)
class TimeoutPolicy:
    after: timedelta
    on_timeout: OnTimeout
    escalate_to: str | None = None

POLICIES = {
    "internal_dashboard_post": TimeoutPolicy(timedelta(hours=24), OnTimeout.APPROVE),
    "customer_email": TimeoutPolicy(timedelta(minutes=30), OnTimeout.ESCALATE, "support_lead"),
    "refund": TimeoutPolicy(timedelta(hours=4), OnTimeout.ESCALATE, "finance_lead"),
    "same_day_booking": TimeoutPolicy(timedelta(hours=2), OnTimeout.CANCEL),
    "stock_reorder": TimeoutPolicy(timedelta(hours=12), OnTimeout.REPLAN),
}

def resolve_expired(item, now: datetime):
    policy = POLICIES[item.action_type]
    if now - item.created_at < policy.after:
        return None  # still waiting
    return policy.on_timeout, policy.escalate_to

Two details matter more than the code. Any action type that is not in the table should fall back to ESCALATE, never to APPROVE. And every decision made by a timeout has to be logged as a timeout decision, with the policy that caused it, so that an audit can tell the difference between "a person approved this" and "nobody looked and the clock approved it".

── What you get ──

§ 06 · What changes when you do this

The queue stays short. Low stakes items drain on their own, expired time sensitive items close cleanly, and stale ones get rechecked instead of approved blind. The only items that actually age are the irreversible ones, which are exactly the ones you want a person to look at.

That is also why reviewers keep reading. When the queue only holds decisions that matter, people treat it with the attention it needs.

If you want to try this, add a fifth column to the table in your APPROVALS.md: the timeout and the default for each action type. It takes an hour to write and saves a lot of arguments later.

Thanks to the reader who raised this. The reference implementation of the other patterns is on GitHub (agent-reliability-patterns), and the original post is here (The approval queue pattern).

── End of pattern ──

◆ Every action type needs a timeout and a default: approve, hold and escalate, cancel, or re-plan.

◆ Choose the default by how expensive the action is to undo. Anything unknown escalates.

Log timeout decisions separately from human ones. "Nobody objected" is not the same as "someone approved".

ORBIRESEARCH

Originally published on the OrbiResearch Lab. We build production AI agents at orbiresearch.com.

Running Hermes Agent in production: what changes when the agent works for a business, not for you

orbiresearch — Tue, 29 Sep 2026 21:17:12 +0000

Hermes Agent, the open-source agent from Nous Research, is designed around a simple idea: one agent, one memory, available everywhere, terminal, Telegram, Slack, WhatsApp, email, and getting more capable the longer it runs, because it turns solved problems into reusable skills. For a single developer that is exactly the right design. For a business deployment, several of those defaults need a second look. This is the checklist we use when Hermes is the runtime behind an agent that does real work for a client.

§ 01 · One client, one environment

Hermes keeps its state, configuration, sessions, memories and skills, under a data directory (~/.hermes by default, or HERMES_HOME). That makes isolation straightforward to reason about: never let two clients share a data directory, and preferably never let them share a machine. We run each client on its own server. It costs slightly more than a multi-tenant setup, but it removes an entire class of failures, one client's memory or skills leaking into another client's conversations, and it makes data deletion at the end of an engagement a matter of destroying one environment.

§ 02 · Choose the execution backend deliberately

Hermes can run commands through several backends, local, Docker, SSH, Singularity and Modal, and the docs describe container hardening and namespace isolation for the sandboxed options. For a production agent that executes tools on behalf of a business, the local backend is the wrong default: a tool call that goes wrong should hit a container, not the host that also holds credentials and the agent's memory. Pick a sandboxed backend, give it only the network access the workflow needs, and treat the host as something the agent should never need to touch.

§ 03 · Secrets never live in the conversation

Messaging gateways make it tempting to hand the agent a credential in chat. Don't. Anything pasted into a conversation can end up in session history and memory. Keep API keys in environment configuration on the server, scope each one to the minimum the workflow needs, and rotate them on a schedule, the same rule you would apply to any service account.

§ 04 · Plan for model failure, not just model choice

Hermes is model-agnostic: it works with Nous Portal, OpenRouter, direct provider APIs or your own endpoint, and it supports routing and fallback configurations. Use that. A production agent should have a primary model and at least one fallback from a different provider, so a provider outage or rate limit degrades the agent instead of stopping it. Then test the fallback path on purpose, a fallback nobody has exercised is a fallback that doesn't work.

§ 05 · Put a human gate in front of irreversible actions

Hermes can act autonomously and run scheduled tasks unattended through its gateway. That's powerful and it's exactly why the actions that can't be undone, sending money, emailing customers, deleting records, publishing, should route through an approval step. In our deployments that step is usually a message in the client's Telegram or Slack with the proposed action and an approve/reject choice. The agent does the work; a person owns the decision.

§ 06 · Memory is a feature and a liability

Persistent memory is what makes Hermes useful over weeks instead of minutes. In a business setting it also means that a wrong fact, an outdated price or a one-off instruction can persist and quietly shape future answers. Decide up front what the agent is allowed to remember, review what it has stored on a schedule, and make sure you can delete a specific memory when a client asks.

§ 07 · Back up the data directory

Everything the agent has learned lives in that data directory. Back it up like a database, on a schedule, off the machine, and test a restore. An agent that loses its skills and memory after a disk failure is back to day one.

── Checklist ──

§ 08 · Checklist

[ ] Does every client have its own environment and data directory?

[ ] Are tools executed in a sandboxed backend, not on the host?

[ ] Are all credentials in server configuration, never in chat?

[ ] Is there a fallback model from a different provider, and has it been tested?

[ ] Do irreversible actions require human approval?

[ ] Is there a policy for what the agent may remember, and a way to delete it?

[ ] Is the data directory backed up and has a restore been tested?

── End of note ──

For how we define an agent's identity and boundaries before any of this, see Anatomy of a SOUL.md.

ORBIRESEARCH

Originally published on the OrbiResearch Lab. We build production AI agents at orbiresearch.com.

The approval queue pattern: putting a human in the loop without putting them in the way

orbiresearch — Sat, 26 Sep 2026 14:00:56 +0000

§ 01 · The problem with "human in the loop"

Every serious agent deployment ends up with a human in the loop somewhere. The phrase has become a checkbox. It is treated as a safety property you either have or do not have. In production it is neither binary nor free.

A human in the loop has a cost, and the cost is latency plus attention. If the agent escalates everything, the human becomes the bottleneck the agent was supposed to remove. If the agent escalates nothing, the human is decoration. Most teams land in a worse place than either: the agent escalates an unpredictable mix of trivial and critical items, the human learns that most items are trivial, and they start approving without reading. Now you have a human in the loop who is functionally not in the loop. You have built a rubber stamp and called it governance.

The approval queue pattern exists to make the human expensive on purpose, and to spend that expense only where it changes the outcome.

§ 02 · The core idea

An approval queue is a durable, ordered list of proposed actions that the agent has decided it should not execute on its own authority. The agent does the reasoning and the drafting. It stops at the action. A human approves, edits, or rejects. The decision and the human who made it are recorded.

Three properties make this a pattern rather than a button:

◆ It is durable. An approval item survives a crash, a restart, and the human going home for the weekend. It lives in a table, not in memory.

◆ It is ordered and bounded. Items have priority and an age. An item that sits unapproved past its SLA is itself an event that triggers escalation, not silence.

◆ It is reversible at the boundary, not after. The human decides before the irreversible action, not after a notification that it already happened.

The unit of the queue is the proposed action, never the conversation. You are not asking a human to review a transcript. You are asking them to approve one specific, executable thing.

── The four fields ──

§ 03 · The four fields every approval item must carry

An approval item that contains only "the agent wants to do X, approve?" forces the human to reconstruct context they do not have. They will either over-investigate (slow) or approve blind (dangerous). Every item must carry four fields.

◆ The action. The exact, executable operation, in plain language and in its concrete form. Not "send outreach." Instead: "Send this email, shown in full, to this address." The human approves the artifact, not a description of it.

◆ The justification. Why the agent proposes this now. The trigger, the rule, the data that led here. One or two sentences. If the agent cannot state why, that is itself a reason to reject.

◆ The blast radius. What this action touches and how hard it is to undo. "One outbound email, not recallable" is a different decision than "one row update, fully reversible." The human is pricing risk. Give them the price.

◆ The confidence and the alternative. What the agent would do if this were rejected, and how sure it is. A low-confidence proposal with an obvious fallback is a fast approve or fast reject. A high-confidence proposal with no fallback deserves the human's full attention.

These four fields turn a vague ask into a decision a busy person can make in seconds without becoming a rubber stamp.

── What belongs in the queue ──

§ 04 · What goes in the queue, and what does not

The discipline is in what you do not route. An approval queue that contains everything is a denial-of-service attack on your own operators.

Route to the queue when at least one is true: the action is irreversible or expensive to undo, the action is externally visible (a customer sees it, money moves, a record leaves your system), or the agent's confidence is below a threshold you set per action class.

Do not route when the action is internal, reversible, and inside the agent's defined scope. Reading data, drafting, summarizing, updating a record the agent owns and can roll back: these are inside the boundary. If you route them, you train your operators to stop reading, and the one item that mattered slips through behind forty that did not.

The threshold is a dial, not a default. Set it per action class. Outbound customer communication might require approval at any confidence. An internal tag update might require approval only below 70 percent. Write the thresholds down. They are part of the system, not a runtime guess.

── The failure modes ──

§ 05 · The failure modes

Rubber stamp. The queue fills with low-stakes items, the operator approves in bulk, and the queue stops being a control. Fix: aggressively reduce what enters the queue, and measure approval time per item. If median approval time drops below the time it takes to read the action, your operators are not reading.

Queue as graveyard. Items pile up unapproved because no one owns the queue. The agent stalls or, worse, starts taking the unapproved actions because a timeout was wired to "proceed." Fix: every queue has an owner and an SLA, and the SLA breach escalates to a person, never to auto-approve.

Context starvation. Operators approve blind because the four fields are missing or thin. Fix: treat a proposal with a weak justification as a defect in the agent, not a judgment call for the human.

Silent scope creep. The set of actions that bypass the queue grows over time, each addition reasonable, until the agent is doing things no one is reviewing. Fix: the routing rules live in version control and are reviewed on the same cadence as the trust boundary.

── The file that holds the queue ──

§ 06 · The contract behind the queue

Create an APPROVALS.md in the agent repository. It lists every action class the agent can propose, the routing rule for each (always, never, or below a confidence threshold), the SLA for each priority level, the escalation target when an SLA is breached, and the owner of the queue. It records the last review date.

This is the document your operations lead reads on day one and your auditor reads on the worst day. An approval queue without a written contract is not a control. It is a habit, and habits drift.

── End of pattern ──

◆ A human in the loop is a cost. Spend it only where it changes the outcome.

◆ The unit of the queue is one executable action with four fields, never a transcript.

If your median approval time is shorter than the time to read the action, you do not have a human in the loop. You have a rubber stamp.

ORBIRESEARCH

Originally published on the OrbiResearch Lab. We build production AI agents at orbiresearch.com.

Retry, Backoff, and Circuit Breakers for LLM API Calls

orbiresearch — Sat, 26 Sep 2026 14:00:20 +0000

Retry LLM API calls on 429, 5xx, and timeouts with exponential backoff plus jitter, honor the Retry-After header when the provider sends one, cap total retry time with a deadline, and wrap the whole thing in a circuit breaker so a degraded provider cannot take your system down with it. Never retry non-idempotent actions blindly, and never retry validation errors at all. That is the summary. The rest of this article is why each rule exists, what the naive version costs, and the code shape we ship.

§ 01 · LLM APIs fail differently

Every API fails. LLM APIs fail with personality. Four modes dominate:

Rate limits (429). The most common and the most misunderstood. A 429 is not an error in your code, it is the provider telling you to slow down. We once treated it as fatal and it cost us a night of production downtime, the full story is in our 429 postmortem.

Overload (529 and friends). Provider-side congestion. Distinct from 429 because slowing down helps your standing but the recovery timeline is not yours to control.

Timeouts. Long generations on loaded infrastructure can exceed any sane client timeout. The dangerous part: a timeout does not mean the request failed. The provider may have completed it after you hung up, which matters enormously if the call had side effects downstream.

Degraded output. The sneakiest mode: the API returns 200 and the content is wrong, truncated, or malformed. No retry logic sees this unless your validation layer feeds it. Silent regressions are their own topic, and we wrote one.

── The retry ladder ──

§ 02 · The retry ladder

The first decision is not how to retry, it is whether.

Retry freely: 429, 5xx, network errors, timeouts on read-only calls. These are transient by definition.

Retry carefully: timeouts on calls whose results trigger side effects. The request may have succeeded invisibly. Before retrying, the system needs an idempotency story, a way to guarantee the side effect happens once even if the call happens twice. We learned that one expensively.

Never retry: 400s, validation errors, authentication failures, content policy refusals. The request is wrong, and resending a wrong request is paying twice for the same no. Retrying a 401 in a loop is how you turn an expired key into a locked account.

── Backoff, jitter, and the Retry-After header ──

§ 03 · Backoff, jitter, and the Retry-After header

Immediate retries against a rate-limited endpoint are a self-inflicted denial of service: every client that failed at second zero retries at second one, together, and the stampede keeps the endpoint saturated. Two mechanisms break the stampede.

Exponential backoff spreads retries over time: wait 1s, then 2s, then 4s, then 8s. Jitter spreads them across clients: randomize each wait so a thousand failed requests do not become a thousand synchronized retries. And when the provider sends a Retry-After header, that number wins over your formula, it is the provider telling you exactly when to come back.

async function callWithRetry(request, opts = {}) {
  const maxAttempts = opts.maxAttempts ?? 5;
  const deadline = Date.now() + (opts.maxTotalMs ?? 60_000);

  for (let attempt = 1; ; attempt++) {
    try {
      return await llm.call(request);
    } catch (err) {
      if (!isRetryable(err) || attempt >= maxAttempts) throw err;

      const retryAfter = err.headers?.["retry-after"];
      const base = retryAfter
        ? Number(retryAfter) * 1000
        : Math.min(1000 * 2 ** (attempt - 1), 30_000);
      const wait = base / 2 + Math.random() * (base / 2); // jitter

      if (Date.now() + wait > deadline) throw err; // budget exhausted
      await sleep(wait);
    }
  }
}

Two details in that snippet carry most of the value. The deadline: retries consume time your user or your queue is waiting through, and unbounded patience is not resilience, it is a hung system with good intentions. And the cap on backoff: waiting 512 seconds because the formula says so helps nobody.

── Circuit breakers, or knowing when to stop knocking ──

§ 04 · Circuit breakers, or knowing when to stop knocking

Retries handle a request that failed. Circuit breakers handle a provider that is failing. The difference matters: when an endpoint is down for ten minutes, ten thousand well-behaved retrying requests are still ten thousand requests achieving nothing, burning your rate limits, your latency budgets, and your queue depth.

A circuit breaker watches the failure rate. When it crosses a threshold, the circuit opens: calls fail fast without touching the API. After a cooldown, a few probe requests test the water. Success closes the circuit, failure keeps it open. Three states, one job: stop paying for calls that cannot succeed.

In agent systems the breaker earns its keep twice over, because agents retry at the task level too. An agent that cannot reach its model will often rephrase, replan, and try again, multiplying the underlying API calls. Without a breaker, one degraded provider turns a patient agent into a very expensive metronome. Breaker state changes belong on your dashboard, and if they surprise you there, your instrumentation has gaps.

── The queue is your shock absorber ──

§ 05 · The queue is your shock absorber

Everything above assumes a request in flight. The system-level question is what happens to work that arrives while the provider is down. The answer that survives production: a persistent queue. Requests land in the queue, workers drain it through the retry and breaker machinery, and a provider outage becomes a growing queue instead of lost work. When the provider recovers, the queue drains, and nothing that mattered disappeared during the gap. Every system we ship is built on this shape, most visibly the nine-agent logistics fleet, where a restart or an outage resumes from the last confirmed message.

── The fallback model is uptime engineering ──

§ 06 · The fallback model is uptime engineering

This month a frontier model vanished from the market for twenty days on a government decision. No retry policy fixes that. The last layer of this stack is a fallback model: a second provider or a smaller model, pre-tested against your workload, behind the same interface. Not because the fallback is as good, but because degraded service beats no service, and because the switch has to be a config change, not an engineering sprint that starts the morning of the outage.

── The checklist ──

§ 07 · The checklist

[ ] 429 and 5xx retried with exponential backoff and jitter

[ ] Retry-After header honored over the local formula

[ ] Total retry time capped by a deadline, per request

[ ] Non-idempotent calls have an idempotency key before any retry

[ ] 400s, auth failures, and refusals are never retried

[ ] Circuit breaker per provider, state visible on the dashboard

[ ] Persistent queue in front of the model, drains after outages

[ ] Fallback model tested against the real workload, switchable by config

── Closing ──

§ 08 · Closing

None of this is exotic. Backoff, breakers, queues, and fallbacks predate language models by decades, and the teams that treat an LLM endpoint like any other unreliable dependency get boring, reliable systems. The teams that treat it as magic get to write postmortems. We know, we wrote ours, and building so the next one never happens is most of what production-grademeans.

── End of pattern ──

ORBIRESEARCH

Originally published on the OrbiResearch Lab. We build production AI agents at orbiresearch.com.