Proactive AI can save work while quietly creating an inbox of questions, approvals, and low-value updates. Design an attention budget that reserves human judgment for consequential decisions.
On October 31, DeepSeek published a research prototype called dsh-superagent with an unusual design principle: take as little human attention as possible while giving as much value as possible. Its philosophy document treats every notification, question, panel item, and comment as a cost. That is a better starting point for a business AI coworker than counting how many tasks it starts.
The prototype is a coding system for one GitHub repository, not a production-ready business product. But its central problem travels well. Imagine a small operations team with a Teammate that monitors customer renewals, a second that watches invoices, and a third that prepares marketing work. Each one can be helpful on its own. Together, they can fill the owner's day with proposed tasks, status pings, duplicate questions, and approvals that lack enough context to decide.
The result is a strange kind of automation: the machines do more work, but the people spend more time tending to the machines. A completed draft may be useful; six notifications announcing that draft is not. A human-in-the-loop policy may sound safe; if every routine step requires a click, the person becomes an exhausted approval service. Eventually the team ignores important exceptions alongside the noise.
An AI coworker human attention budget is a set of rules for when work may begin, when a person must be interrupted, what evidence must accompany that interruption, and how the team will tell whether the interruption was worthwhile. It is not a license for silent autonomy. It is a way to reserve human attention for the decisions only a human should make.
DeepSeek's prototype distinguishes a direct request from a system's inference that work might be useful. Its authorization documentation describes an “observe” default for inferred requests: record what the system would have accepted without starting that work. Explicit requests remain possible. The documentation also describes allowed requesters, policy versions, and a mandate tied to accepted work. These are design details in a research release, not proof that the prototype solves every security or governance problem.
For a business, the important distinction is between someone asked for this, a written rule allows this, and the AI merely noticed an opportunity. Those are different sources of authority. A customer email requesting a status update can authorize a bounded preparation task. A nightly rule can authorize a read-only report. A message in a shared channel saying a client seems unhappy should not silently authorize a credit or a new outbound campaign.
Even when a task is authorized, its progress does not automatically justify interrupting a person. “I found a renewal due next week” belongs in a scheduled digest if the existing process already assigns the account owner. “The contract expires today, the signed amendment conflicts with the CRM date, and a customer response is due in two hours” may deserve an immediate handoff. The difference is consequence, time, and whether someone can actually act on the information now.
The work gate answers whether this Teammate may initiate a task: which source triggered it, which requester or rule authorized it, which customer or project is in scope, and what actions are permitted. The attention gate answers whether a human needs a message now: what decision is pending, who owns it, what happens if nobody responds, and why it cannot wait for the next review window.
Keeping these gates separate prevents two common failures. A quiet Teammate can still do unauthorized work in the background. A properly authorized Teammate can still send ten unnecessary messages about one task. Permission and communication quality are different controls, and both need tests.
In the prototype's philosophy, the system speaks when a person must act or can use a result; otherwise it works quietly. Apply that rule with care. A business still needs a durable record of completed actions and failures, including events that do not merit an immediate notification. Silence in chat is not silence in the audit trail.
What bad looks like: An inventory Teammate detects a supplier's updated price list and sends the owner a message for every changed SKU. It drafts a new purchase order for all of them, asks “approve?” without showing historical quantities, and repeats the question after an hour. A busy owner clicks through until an unusual substitution slips past. The AI created activity, not capacity.
What good looks like: The Teammate compares the new list with the current contract, groups routine changes into one daily review, and separates a single high-impact exception: the substitute product does not meet the existing specification. It pauses the purchase decision, attaches the source document and affected orders, names the decision owner, and says what will happen if the deadline passes. A reviewer can approve a scoped substitution, reject it, or ask for another supplier. The record shows which choice was made.
The goal is not fewer messages at any price. It is fewer unnecessary interruptions and clearer consequential ones. If the supplier change affects safety or a contractual promise, a prompt interruption is a feature, not noise.
A budget makes the cost of a human handoff visible. It does not require pretending that a manager's judgment has a universal dollar value. Start with a measurable workflow and count four things: immediate interruptions, scheduled-review items, decisions made, and corrections after a decision. Track the time spent reconstructing context as well as the time spent clicking an approval.
Suppose a renewal Teammate creates forty review items in a week. Twelve need a customer decision, six are duplicates of existing account-owner work, and twenty-two are routine status updates. A dashboard that reports “forty issues found” flatters the system. A useful review asks which of the twelve decisions were time-sensitive, whether the duplicates were avoidable, and whether any of the routine updates could have waited. These numbers are a hypothetical example, not a claim about a real deployment.
For an immediate alert, require a short decision packet: the triggering fact, the authoritative source and its timestamp, the affected customer or obligation, the deadline, the options, the recommended next step, and the consequence of waiting. If the system cannot identify a decision owner, that uncertainty belongs in the packet too. A vague “urgent issue detected” is not an actionable handoff.
Different decisions deserve different lanes. A critical exception goes to a named owner through a channel they actually monitor. A routine but reviewable result goes into a daily queue. An informational completion goes into the task record, with a digest if the team wants one. A speculative opportunity belongs in an observation log until a human approves the rule that would initiate work.
The prototype's panel emphasizes items waiting on a person instead of spending space on healthy status. That is a useful interface principle, but the panel alone cannot define urgency. An overdue customer response and a low-confidence content suggestion should not share a single undifferentiated “needs review” queue. Sort by impact and deadline, not by the order in which the AI happened to notice things.
Some teams react to notification overload by telling the AI to “only bother me when absolutely necessary.” That is not an operating rule. Define an explicit maximum wait for each class of event and a fallback if the owner is unavailable. A payment release, a customer-facing promise, and a draft for next month's newsletter should not have the same clock.
Use the least intrusive channel that can still meet the deadline. Do not send private customer details into a broad channel because it is convenient. Do not interpret a lack of reply as approval for a consequential write. If the decision deadline passes, the default should be a documented stop or escalation, not an improvised guess. This is seam design: the transition from machine preparation to human judgment is specified before the exceptional case arrives.
You do not need a large governance program to start. Run this test with one existing task, one owner, and a short observation window. The same discipline applies whether the Teammate watches a shared inbox, a CRM, or a repository.
This test separates usefulness from mere activity. It also helps identify work that should not be automated yet: if nobody can say who owns a decision or which source is authoritative, a faster Teammate will only expose an unresolved management problem faster.
The principle extends beyond notification hygiene. We have written about action budgets for a single AI coworker task and approval packets that support real decisions. An action budget limits what the system can do; an attention budget limits the demands it places on people while preserving the handoffs that matter. Both are necessary for a useful operating role.
Q: What is an AI coworker human attention budget?
A: It is an operating policy for when an AI coworker may interrupt a person, what decision information it must provide, and how long work can wait. Measure both noisy messages and missed consequential decisions; minimizing notifications alone is not the goal.
Q: Should an AI coworker be allowed to start work without a direct request?
A: Only when a specific, approved rule defines the trigger, task scope, permitted actions, and owner. Record inferred opportunities first and review them before enabling proactive execution. A system noticing a pattern is not itself business authorization.
Q: Does fewer notifications mean less oversight?
A: No. Keep a durable record of work, decisions, and failures even when chat stays quiet. Send immediate messages for time-sensitive judgment, group routine review into a predictable queue, and retain audit evidence for both.
Q: How do I know whether an approval request is useful?
A: A reviewer should be able to decide from the request itself. It needs the source, affected party, deadline, options, consequence of waiting, and the exact action under consideration. If the reviewer must reconstruct the task from several applications, improve the packet before increasing volume.
Q: Is the DeepSeek prototype a production solution for a small business?
A: Its repository explicitly calls it a research prototype for one GitHub repository, not an official production-ready product. Its documented ideas about authorized requests, observe-first proactive work, and respect for human attention are useful design prompts; evaluate any implementation separately for your environment.
If your team needs AI coworkers that can carry routine work without turning every employee into a full-time approver, explore Associates AI Teammates and choose a plan. Associates AI provides a model-agnostic platform for configuring persistent roles, clear boundaries, and human handoffs around the work your team actually does.
Written by
Founder, Associates AI
Mike is a self-taught technologist who has spent his career proving that unconventional thinking produces the most powerful solutions. He built Associates AI on the belief that every business — regardless of size — deserves AI that actually works for them: custom-built, fully managed, and getting smarter over time. When he's not building agent systems, he's finding the outside-of-the-box answer to problems that have existed for generations.
More from the blog
Screenshots, voice notes, and business records can describe the same event differently. Give an AI c...
Oracle's new Deep Trust architecture puts access and business rules nearer the data. The practical l...
Gusto's new AI-assisted payroll features put preparation closer to the tools owners already use. The...
Want to go deeper?
Get started today. Hire your first Teammate in minutes and put it to work on what you're reading about.
Get Started