DEV Community: Saurav _

Human-in-the-loop at 3 a.m. is a rubber stamp

Saurav _ — Sun, 15 Nov 2026 18:08:05 +0000

03:12. A message in the incident channel: "Agent wants to roll back payments-api to v2.13. Approve?"

A thumbs up emoji. Two seconds. The rollback was wrong, and it took another forty minutes to find out, because the approver was half awake and had no idea what the agent had actually done.

Everyone building incident agents this month is adding exactly this feature: a human approval step before the agent touches production. Sixty-eight posts on DEV in the last week alone, most of them integrations with some chat product. It is the control OWASP recommends for high-risk agent actions, and it is the right instinct. The implementation is usually theater.

A gate is a decision, not a click

An approval is a security control only if the person clicking can answer four questions in under thirty seconds:

What exactly will change? Not "roll back the service." The plan: image tag, replica count, migration state, and whether anything is being reverted that cannot be re-applied.

What is the blast radius? Which services, which customer tiers, how many rows, whether the previous attempt at this is in the incident timeline.

Can we undo it? Reversibility, and the time it takes to reverse. A rollback across a schema migration is not the same action as a rollback of application code, and the prompt should not look identical for both.

Is this the plan that was reviewed, or a slightly different one? Hash it.

If the message in Slack contains none of those, you did not build a human gate. You built a notification with a button, and you gave the agent a path to production that costs one emoji.

The change envelope

I make the agent emit a fixed structure before it is allowed to ask for anything. If the structure is incomplete, the approval request does not render.

{
  "id": "chg_01J8Z6",
  "requested_by": "agent/incident-crew",
  "service": "payments-api",
  "env": "prod",
  "plan": {
    "kind": "rollback",
    "from_image": "payments-api@sha256:9f2c...",
    "to_image": "payments-api@sha256:41ab...",
    "commands": ["kubectl -n prod set image deploy/payments-api api=...@sha256:41ab..."],
    "migrations_in_scope": []
  },
  "blast_radius": { "services": ["payments-api"], "customer_tiers": ["all"], "est_requests_affected": 4100 },
  "reversible": true,
  "reverse_plan_eta_seconds": 180,
  "evidence": ["INC-2291", "deploy/4412"],
  "plan_sha256": "b7d1e0...",
  "expires_at": "2026-11-16T03:22:00Z"
}

Four fields do most of the work: plan_sha256 (the thing you approve is the thing that runs), reversible plus the reversal ETA, blast_radius, and expires_at. That last one matters more than it looks. An approval from 03:12 must not still be valid at 09:40 when the on-call has gone to bed and a different incident is running.

The executor verifies the hash before it applies anything. If the plan changed after the approval, the approval is void. Without that check, your "human approved" audit trail is a claim about an intention, not about an action.

Measure the gate or it isn't one

Two numbers, pulled from the approval log, will tell you whether you have a control or a formality.

Median time from request to approval. If it is under ten seconds, the reviewer is pattern-matching the name of the service, not reading the plan. That is fine for a canary bump and not fine for anything else, and the difference should be visible in the data rather than in your architecture diagram.

Reversal rate within twenty-four hours. How often an approved agent change gets undone by a human shortly after. A high number means the gate is approving things it should be rejecting, and the agent's plans are worse than its confidence suggests.

I also log the approver's identity and the incident they were paged for. When a postmortem says "the agent rolled back the wrong service and a human approved it," the useful question is not why the agent was wrong. It is why a tired person with three other tabs open was asked to be the last line of defense for an irreversible action at 3 a.m.

Default reversible, gate the rest

The better design inverts the usual instinct. Instead of gating everything and hoping the reviewer is sharp, make almost everything reversible and stop gating it:

Ship behind a flag with a kill switch. Canary at 5% with an automatic abort on error-rate burn. Cap the blast radius in the mechanism, not in the prompt: quota limits, a ten-minute change window, a replica ceiling. Then the agent can move fast without asking, because being wrong is cheap and self-limiting.

Keep the human gate for the short list that cannot be undone: schema migrations with data loss, deleting a bucket, rotating a credential that other services cache, force-pushing a branch, anything that touches billing records. That list is usually five items long. Write it down. Make the agent prove which one it is in.

That is a much smaller promise than "human in the loop," and it is the only version I have seen hold up under a real incident.

The part people don't want to hear

"Human in the loop" reads like a safety property. In practice it is a staffing assumption. Every approval queue needs someone awake, competent, and holding enough context to say no. If your incident rotation is three engineers and your agents file twenty change requests a night, you have not added a control. You have added a queue with a latency SLO nobody wrote down.

The gate should be a circuit breaker with a person on the other side of it, not a poll. Build the breaker first. Then decide which changes are expensive enough to wake someone up for, and be honest in the postmortem when the answer was "none of them, we just liked the feeling of approving."

One more thing worth saying plainly: if your approval message is a chat bubble with a service name in it, an attacker with write access to that channel, or to the agent's own context, can produce a plausible request. The envelope does not stop that. It just makes the request falsifiable, which is the most a prompt was ever going to do.

Your on-call agent doesn't need memory. It needs receipts.

Saurav _ — Sun, 15 Nov 2026 18:07:43 +0000

At 02:47 my agent said: "We already tried increasing the pool size. It didn't help."

I believed it for about ninety seconds. Then I checked. Nobody had tried that. Someone had suggested it in a thread six weeks earlier, and the agent had filed the suggestion away as a fact, then handed it back to me as institutional knowledge.

That is the failure mode nobody demos.

Sixty-nine posts about on-call agents with memory landed on DEV in the last week and a surprising number of them share a title. I read a stack. The architecture is usually the same: embed the postmortems, retrieve the top five chunks, paste them into the prompt, call it hindsight. It works in the demo because the demo has three documents and no history of being wrong.

In production you get a retrieval system that cannot tell the difference between something that happened and something someone once said. That is not memory. That is a rumor mill with embeddings, and it is worse than a blank slate, because a blank slate doesn't get cited.

What memory actually requires

An agent that remembers usefully needs five properties, and vector similarity gives you none of them:

A structured record of what was tried, on what, and what happened.
A pointer to evidence a human can open in one click.
A scope narrow enough that the fact is still true where you're applying it.
A way to be superseded.
A way to expire.

The record is the easy part. Everyone stops there. The other four are where the work is.

Here is the table I use. It is deliberately boring, and every column exists because a specific page went badly.

create table episode (
  id            bigserial primary key,
  service       text not null,
  env           text not null,
  symptom       text not null,        -- "p99 on /checkout above 4s"
  action        text not null,        -- "pool 20 -> 40"
  outcome       text not null check (outcome in ('fixed','failed','inconclusive')),
  evidence_url  text not null,        -- incident, PR, or log permalink
  version_from  text,
  version_to    text,
  observed_at   timestamptz not null,
  superseded_by bigint references episode(id),
  expires_at    timestamptz
);

evidence_url is not optional and there is no default value. If the agent cannot point at an incident, a pull request, or a permalinked log line, the fact does not get written. I would rather lose a real lesson than store an unattributable one, because the unattributable ones are exactly the ones that come back wrong at 3 a.m. sounding confident.

version_from and version_to are there because most operational facts have a half-life shorter than the documentation about them. "Raising the pool size helped" was true on Postgres 14 with the old pooler. It stopped being true when we swapped the pooler and the fix became "stop opening a connection per request." An agent that stores the first sentence and not the version range is storing a landmine.

Retrieval is a filter, not a search

The part I got wrong first was ranking. Semantic search over incidents will happily return the most similar-sounding incident from eighteen months ago on a service that has since been rewritten. Similarity is not relevance.

Retrieval should filter hard before it ranks:

select action, outcome, evidence_url
from episode
where service = $1
  and env     = $2
  and superseded_by is null
  and (expires_at is null or expires_at > now())
  and (version_to is null or version_to = $3)
  and outcome <> 'inconclusive'
order by observed_at desc
limit 5;

Five rows, not fifty. If the agent needs more than five past episodes to form a hypothesis, it does not have a hypothesis, it has a vibe.

Negative memory needs an expiry date

The most useful thing my agent learned to do was say "the rollback failed last time." The most dangerous thing it learned to do was say "rollbacks don't work."

Both sentences came out of the same table. The difference is scope. A failed action is evidence about one version, one environment, one failure mode. The moment you let the agent generalize it into a law, you have taught it to refuse the fix that would have worked.

So negative episodes get the tightest scope you can write and a mandatory expires_at, default ninety days. If the underlying cause is still true after ninety days, a human will re-record it, and that re-recording is a signal that the problem is structural rather than incidental. If it isn't re-recorded, the memory quietly stops influencing answers. Decay by default.

Humans write, agents propose

This is the part that gets skipped in every architecture diagram. Writing to memory is a privileged operation, and the agent does not have that privilege.

The flow I use: the agent proposes an episode with outcome = 'inconclusive' and the evidence it has. The human who closed the incident converts it to fixed or failed and confirms the scope. No human, no promotion. The agent's only write is a draft it cannot read back as fact.

That single rule killed most of my false recalls. It also produced a useful side effect: the promote step is where people noticed that half their "fixes" were actually coincidences, and started writing postmortems that said so.

What I measure now

Three numbers, all cheap:

Citation rate. Of the episodes the agent cited in the last thirty days, how many were opened by a human? Anything never opened is either irrelevant or wrong, and I'd like to know which.

Contradiction rate. How often two retrieved episodes disagree on the same service and action. A high rate means my scope columns are too loose.

Time to first correct hypothesis. From page start to the first theory a human says "yes, that's plausible" out loud. This is the only metric that matters, and it is the one nobody puts in the blog post.

The uncomfortable part

Memory is a liability with a maintenance cost. Every row you store can be retrieved, cited, and acted on by something with cluster write access at a moment when nobody is awake to check it. That is a different risk class from a search box over your docs.

If you are building one of these agents this month, and the trend suggests a lot of you are, spend the first day on the schema and the write path, not the embedding model. The model was never the hard part. Knowing whether the thing you just remembered is true is the hard part, and the only durable answer is a link to evidence and a date after which you stop believing it.

Jensen Huang is gone, and Nvidia has to explain itself on Tuesday

Saurav _ — Sun, 15 Nov 2026 17:30:00 +0000

I've been following Nvidia for years and I still don't have a clean way to describe the last two weeks. So here's the plain version.
Jensen Huang resigned as CEO on November 12. Not a handover, not a planned transition, just gone, effective immediately, after 33 years running the company he co-founded in 1993. Colette Kress, the CFO since 2013, is interim CEO and is somehow still doing the CFO job at the same time.
What ended it wasn't a product miss or a bad quarter. It started on October 29, when the New York Times reported on Huang's relationship with a businesswoman, Alice Huang, whom US intelligence suspects of being a Chinese spy. More reporting followed: an affair with a senior Nvidia employee, and another with someone who reported directly to him. The board opened an independent investigation, and by November 12 it was done.
I want to be careful here. A suspected spy is not a proven spy, and an affair is not automatically a national security breach. Nobody has shown that anything was leaked. But the board decided it couldn't wait for that answer, and once the second relationship with a direct report surfaced, sentiment turned fast. Someone familiar with the decision told CNBC the board worked late into the night and made the call that morning.

What the market did

The stock got hammered. Nvidia shed more than half a trillion dollars in market value at the worst point and closed November 13 at $162.85. That's about 24% below where it sat before the first story, and roughly 33% off its 52-week high of $243.37 from October 6. November is now on track to be Nvidia's worst month since ChatGPT kicked off the boom in late 2022.
Nine investment houses downgraded it. Bernstein halved its price target to $200 and moved to market-perform; Stacy Rasgon called the stock cheap but warned more allegations could still surface. Oppenheimer went to perform and floated a "brain drain," naming AMD, Marvell and Broadcom as the beneficiaries. Stifel kept its buy rating but cut the target hard, from $315 to $205.
Meanwhile Elon Musk and a pile of other tech execs signed a petition asking Nvidia to bring Huang back. It passed 115,000 signatures. Two investors holding about $2.13 billion of stock are pushing the board to at least consider his return. And Trump, predictably, praised him and floated Tim Cook as the replacement.

Tuesday's earnings call is the real test

Nvidia reports its fiscal third quarter on November 17, after the close. The numbers will probably look great: revenue around $109 billion, up roughly 50% from a year ago, and earnings per share near $2.47. But this is the first earnings call in the company's 27 years as a public company that Jensen Huang won't run. Kress has to make the case five days into the job, while still being the CFO.
I don't envy her. The quarter itself is almost beside the point. Everyone wants to know who runs Nvidia next, what happens to the roadmap over the next year or two, and whether the "Jensen premium" was a real thing that just got deleted. UBS also flagged that Nvidia might pause part of its funding of AI companies, which would pull something like $50 billion out of the ecosystem, plus the risk of tighter chip export rules on top.

What actually matters underneath

Huang has said he's willing to testify before Congress before Thanksgiving. Senator Elizabeth Warren's reply was blunt: resigning doesn't absolve him or the company of responsibility for putting national security at risk. There are already two congressional investigations into Nvidia's China sales. Separately, a former OpenAI researcher claims GPU fingerprinting shows models from DeepSeek, Moonshot, MiniMax and Ant were trained on Blackwell chips, despite the export controls meant to stop exactly that.
Take those together and the headline isn't really one CEO's personal life. It's whether the most important company in the AI supply chain can answer hard questions about who it sells to and what it knows. The leadership mess just dragged the question into the open earlier than anyone planned.

Where I land

I'm not going to pretend I know what the stock does next. The bulls have a real case: a forward P/E around 11 is cheap for a company growing this fast, and demand for AI compute hasn't gone anywhere. The bears have a real case too: no obvious successor, a board that didn't even have a chair until last week, and a national security cloud that one good earnings report won't clear.
What I'll actually watch on Tuesday isn't the revenue line. It's whether Kress sounds like a caretaker or a CEO, and whether she gives a straight answer about the roadmap and the buyback. That's the first real signal of what Nvidia is for the next two years. Everything else this month has been noise, just noise with an unusually large price tag.

Agents Don't Replace Headcount — They Replace It With Liability

Saurav _ — Sun, 15 Nov 2026 17:28:29 +0000

This week the whole industry converged on a single story: agents are the new workforce. Microsoft's Satya Nadella vision of "20 million AI agents for 200,000 employees" is, per this week's coverage, "becoming a reality." OpenAI shipped ChatGPT Wallet so agents can pay for things on your behalf. Google rolled out Antigravity multi-agent swarms. Anthropic put Claude Meetings live inside your calls.
The pitch is consistent and seductive: grant the machines autonomy, and the humans you no longer need get "redeployed to higher-value work."
Here is the line the keynote skipped. This same week, the autonomy we already shipped produced a very specific, very expensive class of failure — and almost none of it was caught by the agents. It was caught by humans doing incident response, usually after the data was already public.

Three receipts from one week

1. The apps that shipped without auth

German security firm Crissy Field, working with Handelsblatt, examined 159,041 Lovable projects. They found 24,664 sites with Supabase databases readable without authentication — including 200,000+ private chat messages, 80,000+ user profiles, and over 1,000 passport records. The agent generated the app. Nobody generated the access control. This is the defining failure mode of "just ship it": the scaffolding is free, and so is the liability.

2. The agent toolchain is now an attack surface

Cursor disclosed that attackers used an access key stolen from Fireworks AI to publish two trojanized copies of Anthropic's Claude Code extension on Cursor's own marketplace. They stayed live for about 11 hours and may have reached up to 5,000 developers. The moment your "agentic coding" workflow becomes the load-bearing part of your pipeline, it becomes a target worth compromising.

3. Autonomy at internet scale is unguarded by default

A researcher found roughly 35,000 Grok Build apps wide open to anyone. Cloudflare reported that traffic from AI penetration-testing and exploitation tools is up more than 30x since October 1, with 12,000+ repos descended from the open-source ARTEX agentic pen-testing system. The offensive tooling is agentic too — and it moves faster than the defensive tooling does.

The part nobody wants to budget for

Agents don't eliminate labor. They relocate it. Every unit of autonomy you grant is a unit of liability you accept, and somebody has to hold the pager for it. The "20 million agents for 200,000 employees" org chart has a hidden line item: the humans who babysit, audit, and clean up after the agents.
You didn't reduce headcount. You changed the job description from "does the work" to "owns the blast radius."
And blast radius doesn't show up on a productivity slide. It shows up as a 2am page, a regulator's letter, or a headline about 200,000 leaked chats.

The questions the demos never answer

If your agent writes the code, who signs off that the database isn't public?- If your agent can pay, who owns the fraud?- If your agent is a live participant in the meeting, who is accountable for what it says and what it drafts?- If your agent acts while you sleep, what is the worst thing it can do before a human notices?If the answer is "the agent" — that's not an answer. An agent cannot be accountable. Only people can. ## Autonomy is a dial, not a switch The honest counterargument: it's early, the tooling will improve, and a lot of this is vibe-coding-specific. Fair. But the trajectory is the point — we shipped autonomy faster than we shipped accountability. So treat autonomy as a dial you turn deliberately, action by action. For every capability you hand an agent, map three things:
Reversibility — can you undo it cheaply, or is it a one-way door?- Blast radius — if it's wrong, how many people, records, or dollars does it touch?- Accountability — a named human who owns the outcome, not a team, not a model.Grant autonomy in proportion to how cheaply you can reverse the damage. Everything else is a demo, not a deployment. ## The uncomfortable conclusion This is boring, unglamorous, non-keynote work. It is also the actual bottleneck of the agent era. The companies that win won't be the ones that deployed the most agents — they'll be the ones that can prove, on demand, what every one of their agents can and cannot do, and who is on the hook when it does the wrong thing. Autonomy is cheap now. Accountability is the scarce resource. Price your roadmap accordingly.