Your Agent Isn't Too Autonomous. It's Too Loud.

TL;DR

Everyone is chasing more autonomy: agents that act without a human. The harder, more valuable problem is proactivity: deciding whether and when to act, and treating silence as a real decision. The agents that scale you aren’t the ones that do the most. They’re the ones that interrupt you least, and best. A 2026 audit of five deployed coding agents found none of them treats silence as a first-class action, and the best frontier model on the only benchmark that measures this scores about 42%. This is the frontier most teams skip past on their way to chasing autonomy.

The framing everyone gets wrong

Ask most teams what they want from their agents and the answer is some version of “more autonomy.” Let it run longer. Let it touch more files. Let it merge without asking. Autonomy is the slider everyone wants to push right.

It’s the wrong axis to optimise first.

Autonomy is whether an agent can act without a human. Proactivity is whether it gets the whether and when right when it acts unprompted. The two get blended constantly, in product copy and in planning meetings, and the blend hides the more interesting problem. A 2026 position paper from Google Labs, Agentic Coding Needs Proactivity, Not Just Autonomy, keeps them strictly apart and argues the field has been optimising the less valuable one.

The distinction lands the moment you make it personal. The assistant that interrupts you with the wrong thing at the wrong moment isn’t too autonomous. It didn’t do anything reckless. It just spoke without judging whether speaking was worth the interruption. More autonomy wouldn’t have fixed that. Less noise would have.

The idea isn’t new. It traces back to Eric Horvitz’s 1999 CHI paper, Principles of Mixed-Initiative User Interfaces, which framed human and machine as sharing the initiative. The system continuously decides which contribution is worth surfacing, weighing the benefit of acting, the cost of interrupting, and the value of leaving the human in control. That third one is what we forget.

The substrate is new. The aspiration is twenty-five years old. We’ve spent most of that time building agents that can do more, and almost none of it building agents that know when not to.

The three levels

The Google Labs paper offers a clean taxonomy. Once you see the three levels, you can place any agent you use.

Level 1: Reactive. Runs only when you prompt it. No memory of you between requests, no presence when you’re not looking. This is the chat box. You ask, it answers, it forgets. Cursor’s background agents sit here: real work, but only when you start them.

Level 2: Scheduled. Runs on a timer or a trigger. It can filter, batch, and rank. What it can’t do is learn when to interrupt you, and it doesn’t treat silence as a choice. Every item that clears its filter gets surfaced. This is where the bulk of today’s “proactive” tooling lives: GitHub’s Copilot coding agent, Google’s Jules, Cursor Automations, Claude Code routines. They run on a cadence and show you what they found. They don’t ask whether now is a good time.

Level 3: Situation-Aware. Monitors a continuous stream of events. Weighs the value of acting against the cost of interrupting, across the full set of options, including saying nothing. Learns a model of you from your feedback. This is the one almost nobody has built.

The honest reading is uncomfortable. The paper audited five deployed coding agents and found none computes a meaningful interruption cost, and none treats silence as an explicit, recorded action. Most cluster at Level 2. The only example reaching Level 3 is LangChain’s ambient agents, and even that is a reference architecture, not a shipped product. Keep the paper’s own line: the gap isn’t capability, it’s judgment. Knowing when to interrupt, what to show, and when to stay quiet.

Let me be concrete, because I run a Level-2 system every day.

What Level 2 feels like to run

First, picture the loud kind you actually dread. You’re forty minutes into a hard problem, the whole thing held in your head, and a notification slides in: an agent has found a non-urgent dependency advisory. Nothing is on fire. It could have waited. But it pinged you, synchronously, mid-thought, and now you’ve context-switched and have to rebuild that state (the cost comes in numbers later). That’s the expensive loud: a mistimed push that forces an interruption you didn’t choose.

Almost none of my own system works that way, and that’s deliberate. I run a personal AI OS: memory, scheduled jobs, and named specialists (wrote about it here). A morning briefing at 06:00, a strategy memo with one high-leverage decision, an agentic coding digest at 20:00. On the dev side, a dependency lane raising grouped update PRs, a coverage lane writing tests for one weak module a week, a daily review sweep ranking open issues and PRs into cards I approve.

What they all have in common matters more than the list: every one is async. Nothing pings me. Each rolls up on a cadence and waits in a queue I pull from when I want it. That sidesteps the synchronous loud entirely, and it isn’t a workaround, it’s the recommended shape: an inbox, a PR list, a stack of cards is exactly where a good agent’s notify and draft output belongs. LangChain’s ambient agents route theirs into an “Agent Inbox” for the same reason. A queue doesn’t bury you the way a stream of push notifications does.

What I’m left with is the milder loud: low-signal volume. Each job surfaces everything that clears a static filter and never learns what to stop showing me. The triage stays on me. The briefing arrives at 06:00 even when there’s nothing worth saying. Its gap isn’t that it interrupts, it’s that it can’t decide to skip a day or send less: a relevance-and-learning gap, not a timing one. On a noisy week the risk isn’t a blown interruption. It’s that I start skimming the channel and tune it out.

A Level-3 version would learn what I consistently ignore, go quiet there, and judge whether an item is relevant now rather than just whether it cleared a fixed filter. Inbox automation that decides which messages are worth raising. Meeting prep that knows which calls need a brief. Neither is held back by model capability. Both wait on the system learning, from my reactions, what not to surface, which is exactly the judgment Level 2 lacks. The good news is it’s closer than it looks. More on that at the end.

Silence as a feature

Here’s the move that separates the levels, and it feels wrong at first: the best action is often to do nothing.

The proactivity paper makes silence a first-class action. Every candidate insight, every “I noticed something,” resolves to one of four choices:

Notify. Surface a state change, don’t act on it.
Question. Ask for the missing intent rather than guess.
Draft. Produce low-ambiguity work: a PR comment, a patch, a review thread.
Stay silent. Decline to interrupt when the value is low or the timing is wrong.

LangChain’s ambient agents converge on nearly the same set from the product side: notify, question, review. Two research lines arriving independently at the same shape usually means the shape is right.

Silence belongs on that list because interruption is expensive, and the cost is measurable. Recovery from an on-screen interruption runs roughly 10 to 15 minutes for a bug fix and 30 to 60 minutes for architecture or security work. An agent that interrupts an architecture session to flag a minor style nit has just cost its developer the better part of an hour. It was trying to help. It was net negative anyway.

The paper’s worked example is the cleanest illustration I’ve seen. A payment provider announces it’s deprecating an old API in two weeks. What should a proactive agent do? At first: nothing. There’s a release note, no failing tests, and the developer is heads-down on an unrelated incident. The right action is stay silent. It only shifts to notify once the situation changes: the branch touches checkout, a ticket starts depending on that endpoint, CI throws a deprecation warning, a thread confirms a migration is planned. Then, and only then, surface it. Possibly even draft the change. The information was true the whole time. What changed was whether saying it was worth the interruption.

This reframes what a good agent is. Not the one with the most to say. The one with the judgment to know that most of what it could say isn’t worth your attention right now.

Want a read on where your agents sit on this? Book a 15-minute working session.

What this means if you’re building or buying

If you’re rolling out agents to a team, or building an AI OS for yourself, the practical takeaway is a shift in what you design. Most teams design the capability: what the agent can detect, fetch, summarise, act on. Far fewer design the interruption policy: whether, and when, it should bring any of it to a human.

That policy decides whether people keep the agent on. An agent that’s right 90% of the time but interrupts constantly gets muted within a week. An agent that’s right 70% of the time but only speaks when confident gets trusted. And there’s evidence the second one is measurably the better agent. On PARE-Bench, the one benchmark that scores judgment about when to act, the best frontier models reach only about 42% success: they get it right under half the time. The detail worth tattooing on the wall is that the model proposing least often got accepted most often. Claude paired the lowest proposal rate, 12.8%, with the highest acceptance, 78.2%. Propose less, get accepted more. Restraint isn’t the absence of proactivity, it’s the skilled version of it, and it shows up in the numbers.

A starting insight policy, in plain terms:

Default to silence. An item has to earn the interruption. Make the agent justify surfacing, not justify staying quiet.
Match the action to the confidence. High confidence and low ambiguity can draft. Medium can notify. Unclear intent should question, not guess. Low value should stay silent.
Price the interruption. Use cheap proxies you already have: is the person heads-down, their recent edit cadence, their calendar, how many recent items they’ve dismissed. The paper’s own list of Cost_int signals is buildable from telemetry most setups already log.
Batch what isn’t urgent. Most “notify” items aren’t time-sensitive. A once-a-day digest beats ten interruptions. The morning briefing is a batching strategy, whether or not you called it one.
Learn from the reaction. Track what gets acted on versus dismissed, and let that history quiet the categories that consistently get ignored. The benchmark’s third metric, Learning Lift, is exactly this: does feedback make tomorrow’s decisions better.

None of this requires a frontier model or a research budget. It requires treating “should I say this now” as a real decision the system makes, instead of a question it never asks.

Not the one writing the code? The same five ideas become procurement criteria. Insist on a default-to-silence policy, not a firehose with filters. Ask to see the silence log, the record of what the agent chose not to surface. Require a standing review of the act-on rate, so low-value categories get quieter over time instead of louder. If whoever builds your agents can’t show you those, they’ve shipped capability without an interruption policy, and you’ll be the one muting it within a week.

Monday-morning: make your scheduled agents quieter

You probably can’t build Level 3 next week. Nobody’s shipped it. But you can move your Level-2 agents toward Level 2.5, which is most of the felt benefit, and you can start Monday.

Pick your noisiest scheduled agent, the one whose output you’ve started skimming. Then, in order:

Add a surface-or-skip gate. Before any item goes out, ask one question in code: is this useful now, given what else is queued and how much the person has recently ignored. If it doesn’t clear the bar, hold it. That hold is your first deliberate silence.
Log the silence. When the agent decides not to surface something, record that it chose to. Silence you can see is a decision. Silence you can’t see is just a gap, and it’s what you’ll learn from later.
Batch the non-urgent. Anything that isn’t time-sensitive goes into one scheduled digest, not a stream of interruptions. You almost certainly have per-event items that could wait for the daily roll-up.
Match action to confidence. Split the output. High-confidence, low-ambiguity items can draft something for review. Everything else notifies or asks. Stop treating “I found something” and “you need to act now” as the same signal.
Watch the act-on rate for two weeks. Track how often surfaced items actually get acted on. If a category is consistently ignored, raise its bar or move it to the digest. You’re hand-rolling Learning Lift, and it works.

That’s the achievable version of the frontier. Not an agent that does more. An agent that has learned to be quiet, and earns the moments when it speaks.

The models will keep getting better at acting. They are, by the only measure we have, still bad at knowing when to. The teams that win the next round won’t be the ones whose agents are the most autonomous. They’ll be the ones whose agents are the most considerate of your attention, because attention is the resource that doesn’t scale, and silence is the feature nobody’s shipped yet.

If you’re rolling agents out to a team, or building your own AI OS, book a 15-minute working session. You’ll walk out with a first-cut interruption policy for your noisiest agent, the one you’d actually ship Monday.

FAQ

Q: Are AI agents too autonomous? Autonomy isn’t the constraint most teams hit. Autonomy is whether an agent can act without a human. Proactivity is whether it decides correctly whether and when to act unprompted, including the choice to stay silent. The agents that frustrate people aren’t usually too independent. They surface too much, at the wrong time, without judging whether it’s worth the interruption. That’s a proactivity problem, not an autonomy problem.

Q: What is a proactive AI agent? A proactive agent notices what matters before being asked, connects signals across your tools, and decides whether surfacing it now is worth interrupting you. The 2026 Google Labs framing puts it on three levels. Level 1 (Reactive) runs only when prompted. Level 2 (Scheduled) runs on a timer and can filter or rank, but treats every result as worth showing. Level 3 (Situation-Aware) weighs the value of acting against the cost of interrupting, treats silence as a real decision, and learns your preferences over time. Almost everything deployed today is Level 2.

Q: What is the interruption cost of an AI agent? Interruption cost is the time and focus a person loses when an agent surfaces something at the wrong moment. The research puts recovery at roughly 10 to 15 minutes after a bug-fix interruption and 30 to 60 minutes after architecture or security work. A proactive agent should weigh that cost before it speaks. Most don’t model it at all.

Q: Is there a benchmark for proactive agents? PARE-Bench (Proactive Agent Research Environment, 2026) is the first benchmark to score agents against a simulated active user across a full observe, infer, propose, execute loop. The best frontier models reach about 42 percent. The standout finding is that the model proposing least often was accepted most often. Calibration beats eagerness.

Q: How do I make my scheduled agents less noisy? Start by making silence a logged decision, not an accident. Add a simple gate before each item is surfaced: is this useful now, given what else is in the queue and how much the person has recently ignored. Batch low-value items into a digest instead of interrupting per event. Track which surfaced items get acted on, and let that history quiet the ones that don’t. None of this needs a smarter model. It needs an interruption policy.

Q: How is this different from harness engineering? Harness engineering is about building the substrate that makes an agent reliable: identity, rules, skills, hooks, memory, scheduled agents. This article is about a decision that runs on top of that substrate, in the sixth layer specifically: once you have scheduled agents, the next question is when they should speak. Proactivity is the policy layer above the harness. See Harness Engineering for the substrate, and A Week in My AI OS for the scheduled agents this builds on.