Skip to main content
A reactive worker only acts when you open a task and type. A proactive worker notices work, proposes it, and — within limits you set — does it. This page describes how CogniAgent is designed to make that shift safely.
Proactivity is the roadmap layer on top of Cowork’s reactive core. Workers, Tasks, and the agentic loop are built today; ambient triggers, the proposals inbox, and the autonomy ladder described below are designed but not yet generally available. Treat this page as a preview of the direction, not a feature list you can turn on now.

​
Why reactive isn’t enough

A worker that waits for you to start every conversation is still useful, but it caps how much work it can take off your plate — it can only do what you remember to ask for. The next step is a worker that watches for the right moment and starts the work itself: a recurring report that drafts before you ask, a failed run that gets retried overnight, a stale document that gets flagged before it becomes a problem. That shift happens along two independent dials, and keeping them separate is what keeps proactivity safe:
  • Initiation — what starts a task. Today that’s always you, typing. Proactive work moves this to a schedule, an event, or the worker noticing something on its own.
  • Autonomy — how far the worker acts before a human is involved. This stays conservative by default regardless of what started the task — see the autonomy ladder below.
Moving initiation away from “you type” does not mean moving autonomy away from “you approve.” A worker can start itself and still land its output in front of you before anything irreversible happens.

​
The trigger kinds

Proactive work is designed to start from one of five trigger kinds:
Recurring work on a cadence you set — “every weekday at 9am, summarize overnight support tickets.” The lowest-risk trigger: you already approved the work by authoring the schedule, so a scheduled task starts a session directly rather than waiting in a review queue.
A change in a connected app — a CRM record updates, a calendar meeting starts, a GitHub issue gets labeled. Routed through the same Connection Manager that gives workers their tools today.
An email, Slack message, or chat arrives and a worker picks it up. This is the trigger kind most exposed to untrusted content, so it gets the tightest governance — see safety and governance below.
An arbitrary external signal from a system that isn’t a first-class connection yet.
The worker scans its own surroundings and notices something worth acting on — an unfinished checklist item from a prior task, a run that failed, an asset going stale, a deadline approaching. This is the most “employee-like” trigger and the hardest to scope, since unbounded scanning is unbounded compute.
Except for schedules and rules you’ve explicitly pre-approved, every trigger is designed to produce a proposal rather than a committed action — which is where the proposals inbox comes in.

​
The ambient worker pattern: propose, then review

The pattern is: a signal fires, a worker runs in the background, and instead of silently taking action it produces a proposal — a draft message, a plan, a suggested next task — that lands in a shared review queue. You decide what happens to it. Nothing is hidden and nothing external happens without a checkpoint you can see. This is deliberately not “the worker does things while you’re away and tells you afterward.” The proposal sits in a queue — grouped by worker or by workspace — until you act on it. Four resolutions are designed for each item:
  • Accept — run it as proposed.
  • Edit — approve with modified details (change the recipient, tweak the draft, adjust scope) before it runs.
  • Respond — reply in free text instead, redirecting the worker.
  • Ignore — dismiss it. A dismissal is itself a signal: the worker is designed to learn not to re-propose the same kind of thing.
The reason this matters at scale: proactivity turns a 1-to-1 relationship (you and one conversation) into 1-to-many (a fleet of workers noticing things in the background). Reviewing a queue of proposals is what makes that fan-out manageable — you triage instead of conversing with each worker individually. The inbox’s usefulness lives or dies on signal-to-noise, so proposals are designed to be capped, deduplicated, and digested rather than fired at you one at a time.
This inbox pattern is the proactive counterpart to human-in-the-loop approvals inside a running task. Both put a person at the checkpoint before something irreversible happens — the inbox is just the entry point for work you didn’t start yourself.

​
The autonomy ladder

Not every proposal needs the same amount of oversight. The autonomy ladder is a dial — set per worker, promotable as a worker earns trust — that controls how far it can act before a human is involved: This ladder governs whether a worker can pick up proactive or ambient work in the first place. It’s a different question from the task-level run mode, which governs what a worker already working on your request can do unattended, turn by turn. There’s a deliberate ceiling: a tier where a worker acts with no checkpoints at all is not offered. Every worker starts conservative — notify or propose — and moves up the ladder only as it demonstrates it gets things right. The gate that decides whether an action needs review isn’t set per worker as a blanket switch; it’s evaluated per action, based on how reversible that specific action is. The same worker might auto-run a read or a draft while still routing a “send this email” or “delete this record” to you.
In practice, most actions a worker takes are reversible — drafting, reading, summarizing. The design principle is to let the reversible majority run and reserve human review for the small, high-stakes tail: sending, deleting, paying, publishing.

​
Safety and governance

Autonomy without a prompt is a bigger risk surface than autonomy with one: a worker that ingests untrusted content on its own schedule and holds real credentials can act on something malicious before anyone looks. Proactivity is designed with a governance layer that sits outside the worker’s own reasoning — budgets, rate limits, and kill switches that a compromised or confused worker can’t reason its way around. The intended safeguards include:
  • Guardrails against manipulated input. A proactive worker reading inboxes, tickets, or scraped pages all day is exposed to content it didn’t ask for. Untrusted content is not allowed to authorize an outbound or destructive action on its own — that always routes to human approval.
  • Spend limits that actually stop. Hard budget ceilings at the task, worker, and workspace level, enforced before a model call is made — not just an alert after the fact.
  • Loop and runaway protection. Caps on steps, retries, and how deeply a worker can delegate to other workers, so an unattended run can’t spiral.
  • A kill switch and automatic circuit breakers. A human can halt a worker or the whole workspace; automatic breakers trip on cost or error thresholds without waiting for a human to notice.
  • A notification budget. A hard daily cap on how many proposals reach you, plus digests instead of a stream of pings — so the inbox stays something you read, not something you mute.
  • Per-worker identity and audit. Every unattended action is logged against the worker, the policy that allowed it, and the human who ultimately resolved it.
None of this replaces the checkpoints described in human-in-the-loop — it extends them to work you never explicitly started. The design principle throughout is: the more autonomous the tier, the more guardrails surround it.

​
Where proposals surface

Proposals are designed to reach you through the same surfaces you already use, rather than a separate inbox to check:
  • Tasks home groups pending proposals so you can accept, edit, or dismiss them alongside your active work — see Tasks.
  • Accepted proposals are designed to flow into your existing task backlog rather than opening a new, disconnected view.
  • Overnight or batched activity is designed to summarize as a digest — “here’s what I noticed, drafted, or did” — rather than a notification per event.
  • Longer term, proposals and approvals are designed to reach you through channels like Slack or email, so you can act without opening Cowork at all.

​
How this relates to self-improvement

Proactivity and self-improvement are complementary but distinct. Proactivity is about when a worker acts — starting itself from a schedule, event, or observation instead of waiting for you. Self-improvement is about a worker getting better over time from what it learns in its tasks. A worker that notices its own unfinished follow-ups and proposes to finish them sits at the intersection of both.

​
Next steps

Human-in-the-loop

See how approvals and checkpoints work inside a running task today.

Channels

Learn how workers communicate through Slack, email, and other channels.

Self-improvement & learning

See how workers are designed to get better from what they learn on the job.

The agentic loop

Understand the plan-act-observe loop that every task — reactive or proactive — runs on.