Personal Agents in Practice: Where Does Proactivity Come From, and What Holds It Back?

This article introduces a framework for safely scaling Personal Agent proactivity by explicitly defining goals and acceptance criteria to manage execution risks.

Learn More about Qoder

Explore Qoder – The All in One AI Coder

The previous article, "Qoder Cloud Agents Help Developers Enter the Personal Agent Era," explained how Qoder Cloud Agents connects identity, memory, instant messaging (IM) channels, scheduled tasks, and cloud execution into a unified foundation for development. This article shares some of Qoder's thinking on putting these capabilities into practice: once an Agent can work continuously, what should it proactively address, and how far should it go?

1. The Phenomenon: What Does "More Proactive" Really Mean?

Since this wave of Personal Agent products launched, one phrase has dominated the discussion: “more proactive.” They reach out on their own, remember something you mentioned in passing last week, and move things forward before you ask. They seem more proactive, but proactivity is not a single feature. On closer inspection, it is the visible result of three elements working together.

01_Proactivity_English
Figure 1 · Three Elements Behind Greater Proactivity

Product	Standout Capability	What It Also Covers	Role in Proactivity
Cue	Independent Identity	The Agent has its own email account, phone number, wallet, and computer; it can connect to email, calendars, and messaging services, run automations on a schedule or in response to supported events and conditions, and retain memory across sessions	Lets the Agent keep working with its own identity, triggers, and context after the user goes offline
Muse	Cross-App Execution	Uses connectors and an isolated, secure environment to work across email, business systems, and transaction workflows; checks back with the user when the state changes or authorization is needed, and retains long-term context	Integrates changes in external systems into a “detect–assess–act” loop
Today	Structured Long-Term Memory	Connects calendars, email, notes, files, and health data; proactively organizes information through morning briefings, evening wrap-ups, and change detection, and performs cross-app actions after confirmation	Turns scattered signals into next steps relevant to personal goals

Proactivity falls short if any of the three is missing:

With identity but no data sources, the Agent is present but has nothing to do.
With data sources but no memory, every notification feels like a generic broadcast.
With memory but no identity, even when the Agent has an idea, it must wait until you next open the chat.

With an Identity, Changes in Data Sources Become Events

One point is easy to overlook: once an Agent has an independent identity, changes in its data sources naturally become event sources.

Take Git, for example. An Agent can check repository state on a schedule—one way to detect changes. Pushes and merges are also events in their own right; in DevOps, they trigger pipelines. These events still occur when the user is away. With its own account and permissions, the Agent can be triggered by them just as a pipeline can.

An Agent can therefore determine “when to act” in two ways:

Trigger Source	Mechanism	Example
Scheduled Checks	Polling: checking state at regular intervals	Reviewing the day’s messages and documents each evening
Changes as Events	Subscription: waking the Agent whenever data changes	A PR is merged, someone @mentions me in a group chat, or a calendar event changes

At this point, the question of whether an Agent can be proactive is largely answered. But a more important question remains: what should it take initiative on?

2. The Core Idea: Proactivity Comes from the Gap Between Goal and Current State

Let us return to the simplest question: why do people take initiative?

Because they have a goal in mind and see a gap between the current state and that goal. The gap reveals that “there is a problem here,” and the problem is then broken down into tasks.

02_Delegation_Map_English
Figure 2 · Goal − Current State = Gap → Problem → Task

The same applies to an Agent. Without a goal, there is no gap; without a gap, being proactive is merely a way to draw attention to itself.

This Already Happens with Task-Level Agents

Today’s coding Agents and general-purpose task Agents already work this way: the user provides a goal, and the Agent runs a loop—acting, checking, and comparing the result with the expected outcome to determine whether the task is complete. It fills in whatever is missing along the way. This is, in itself, action driven by the gap.

A Personal Agent (PA) does not introduce a new mechanism. It extends the task-level goal/outcome model in two directions:

03_The_Lever_English
Figure 3 · From Task-Level Goals to Long-Term PA Goals

Dimension	Task-Level Agent	PA (Long-Term Goals)
Scope	A single task	A project, a milestone, or even a person’s goal (such as “become an expert in a particular field”)
Duration	Ends when the task is complete	Spans multiple tasks—like pausing and resuming a loop over a much longer period
User Presence	Present for almost the entire process	Absent most of the time
Source of Problems	Provided directly by the user	Derived by the Agent from the gap
How Authorization Is Granted	Authorized once per task	Authorized separately for each subtask

Extending the Model Changes Three Things

① Proactivity shifts from a nice-to-have to a necessity. A task-level Agent can still deliver without being proactive because the user is present and can nudge it at any time. With long-term goals, the user is absent most of the time. If the Agent does not track progress and identify problems on its own, the goal stalls. Long-term goals make proactivity a requirement.

② Authorization follows subtasks, not goals. Giving the Agent a goal—“Get this milestone shipped”—does not authorize it to message everyone on my behalf or change production configuration. A goal sets direction, but each subtask carries different risks, so authorization must be granted one subtask at a time.

③ The longer the time horizon, the more important continuous goal alignment becomes. In a single task, the goal is stated at the outset and usually remains stable. Over several weeks, the goal itself can drift: priorities change, upstream decisions change, and my own thinking changes. If the Agent keeps pushing forward based on its understanding from three weeks ago, it is “driving hard toward a goal that is no longer aligned.” This is the most dangerous failure mode of long-term proactivity.

3. Proactivity Has Levels

If proactivity comes from "gap → problem," the basis for distinguishing its levels follows naturally: who defines the problem? We can examine this along two axes.

Horizontal Axis: Who Defines the Problem?

Level	Name	Who Defines the Problem?	Typical Example	What This Level Addresses
L1	Instructions	User	"Summarize this document for me."	I ask; you do it.
L2	Time	The user sets the rules; the Agent determines when to act.	Summarize yesterday's messages every morning at 9:00.	Recurring tasks no longer require repeated prompts.
L3	External Events	The user sets the conditions; the Agent detects events.	Automatically run checks after a PR is merged; provide an initial response when someone @mentions me in a group chat.	Timely responses, with nothing missed even when I am away.
L4	Ongoing Goals	The user provides the goal; the Agent calculates the gap and defines the problem.	Given a milestone, the Agent independently notices that "no one has taken ownership of this dependency yet."	Things I had not thought of, but that need to be done.
L5	Agent-Inferred Goals	The Agent infers goals and independently creates schedules and tasks.	From my conversations, the Agent infers that I have recently been considering a move in a particular direction and starts making arrangements for me.	Goals I have not yet recognized myself.

04_Goal_to_Task_English
Figure 4 · Horizontal Axis: Who Defines the Problem? (L1–L5)

The shift from L3 to L4 is a qualitative leap.

From L1 through L3, however intelligent the Agent may appear, the problem is always defined by the user: the user sets the timing rules at L2 and the trigger conditions at L3. The Agent simply executes at the appropriate time.

At L4, the user provides only the goal, and the Agent determines "what is currently missing and what needs to be addressed." L4 has one prerequisite: the gap must be computable. The goal must be clear—either quantifiable or associated with a verifiable state.

At L5, the Agent infers the goal itself. If an L4 goal cannot be articulated clearly, it effectively becomes L5.

Goal Formulation	Is the Gap Computable?
"Launch three features by the end of October, with each one passing acceptance testing."	Yes: the target count, deadline, and status are defined.
"The knowledge base must cover these eight core concepts in a particular domain, each supported by a primary source."	Yes: it has a checklist and acceptance criteria.
"Make the team more efficient."	No: the Agent can only guess, so it drifts into L5.

Vertical Axis: How Far Does It Go?

The horizontal axis answers "where does the problem come from?" but not "how far can the Agent go?" Even at the same L4 level, "notifying you that no one has taken ownership of a dependency" and "taking ownership of it directly on your behalf in the group chat" are entirely different things.

That is why we need a second axis:

05_Who_Defines_the_Problem_English
Figure 5 · Vertical Axis: How Far Does It Go?

Category	What the Agent Does	What the User Must Do
Notify	Tells you what happened.	Make the judgment and act.
Recommend	Tells you what to do.	Take action yourself.
Draft for Approval	Prepares what needs to be done.	Review it and approve.
Execute (Reversible)	Acts directly; mistakes can be undone.	Spot-check afterward.
Execute (Irreversible / External)	Acts directly, affecting others or in ways that cannot be undone.	Trust the Agent in advance.

The two axes are independent. An L5 Agent may stop at "Notify," while an L3 Agent may execute external actions directly. Any discussion of what a PA can do must specify its position on both axes.

4. A Personal Agent in Practice: What I Learned and How My Thinking Changed

I built myself a PA called Daisy. It runs several persistent loops:

daily consolidation loop: Every evening at 20:00, it scans the day's conversations, DingTalk group chats, key direct messages, and documents, producing two outputs: a list of action items (todo), and a list of "topics encountered today that may be worth preserving" (discover).
auto-reply loop: When someone @mentions me in an allowlisted group, it responds on my behalf according to predefined rules.

Plotted along the two axes:

Vertical Axis Horizontal Axis	L3 External Events	L4 Ongoing Goals	L5 Agent-Inferred Goals
Execute (Irreversible / External)	● auto-reply
Execute (Reversible)
Draft for Approval
Recommend		● todo
Notify			● discover

On the horizontal axis, it has already reached L4 and L5: todo represents gaps calculated against my work goals, while discover is based on its inference about "what I might care about."

On the vertical axis, both todo and discover remain almost entirely in the bottom two tiers.

The Data Does Not Lie

Since July 1, the daily loop has produced 276 todos, 138 of which were marked complete. Of those 138, I manually closed 126 in bulk during a single session on August 13. The loop itself executed and closed none.

Every day, it "discovers problems," but it never "solves problems." All execution and follow-through ultimately fall back to me.

Is It Too Cautious?

Apparently not. Consider the auto-reply loop in the same PA:

It replies directly to colleagues on my behalf in DingTalk group chats. This is an external, irreversible action: once a reply is sent, it cannot be taken back. The risk is far greater than closing a todo. Yet I am comfortable entrusting this to the Agent because I defined every rule myself:

Rule	Purpose
Reply only in allowlisted groups	Limit the scope of impact
Topic blocklist	Never engage with sensitive topics
Skip it if I am already handling it	Do not talk over me
Do not reply to messages more than 30 minutes old	Do not respond in an outdated context
Use a fallback response when there is only an image and no text	Do not guess at content it cannot understand

I defined the problem and drew the boundaries; if something goes wrong, the responsibility is mine. That is why I am willing to let it act.

A todo, by contrast, is a problem identified by the Agent itself. It decides that "this should be done"—but if its assessment is wrong and it takes the wrong action on my behalf, who bears the consequences? Until that question has an answer, I will keep it at "Recommend."

Knowledge-Base Promotion: The Same Task Can Move from L5 to L4

Here, “promotion” means moving vetted notes and insights into the main knowledge base.

discover is a more interesting example. It surfaced more than 80 topics in total, but I did not add them directly to the knowledge base from the list.

That does not mean I never add them to the knowledge base. When a topic seems worthwhile, I continue discussing it with the Agent until I am satisfied and understand it thoroughly, then ask the Agent to organize it and add it to the knowledge base. Of the items left unprocessed, some remained because I lacked the time—or simply could not be bothered. Others remained because I was concerned that automatically generated content would not be good enough to enter the knowledge base directly.

Change the setup, however, and the situation changes. Suppose that, in the PA context, I explicitly state, "I want to become an expert in a particular domain," while also defining clear criteria for adding content to the knowledge base:

The knowledge architecture is clear, and the content fits into the existing conceptual framework;
The sources are reliable, with priority given to official documentation and primary sources;
The content does not conflict with existing conclusions in the knowledge base; any conflicts are flagged.

With the risks under control, the Agent could then add some content to the knowledge base on its own.

06_Task_Agent_to_PA_English
Figure 6 · Moving the Same Task from L5 to L4

In this scenario, the Agent’s capabilities would remain unchanged. What would change is what I give it: a well-defined goal and a set of verifiable acceptance criteria.

5. When Can an Agent Act Proactively on Its Own? Look at the Cost of Failure

Whether a task can be delegated to an Agent for execution has little to do with its level, or with how cautious someone is. What really matters are two questions:

Who defined the problem? This determines accountability when something goes wrong.

What is the cost of failure? This comes down to three things: whether the action can be reversed, who it affects, and whether the outcome can be verified.

These two questions let us sort tasks into five categories. Here is a real-world example of each:

Category	Criteria	Position on the Two Axes	Example
Execute Directly	Affects only the user; reversible; verifiable outcome	Any Level × Execute (Reversible)	Check whether newly created work items have been added to the sprint
Execute Under Predefined Rules	Problem and boundaries predefined by the user	L3 × Execute (Irreversible / External)	Someone asks in a group chat, "Has the billing announcement been sent?" The Agent replies directly under predefined rules
Partial Execution with a Goal and Acceptance Criteria	Progress toward the goal can be calculated; acceptance criteria are explicit	L4 × Partial Execution	Under the goal of "becoming an expert in a particular field" and defined knowledge-base promotion criteria, add qualifying topics to the knowledge base
Draft for Approval	Involves fulfilling a commitment to someone else	L4 × Draft for Approval	I promise to send someone a revised slide deck the next morning: the Agent can prepare the revisions, but I send it
Notify Only	Irreversible; affects customers or the business; outcome cannot be verified in advance	L4 / L5 × Notify	How to define the semantics of an already published API (in principle, a published API must not be changed unilaterally)

A diagram makes this more intuitive:

07_How_Far_It_Goes_English
Figure 7 · Can This Be Delegated to an Agent?

The lower-left corner is best suited to direct execution: I defined the problem, and the cost of failure is low. The farther toward the upper right, the more human oversight is needed at critical checkpoints.

6. What Limits Proactivity, and What Is the Lever?

Returning to the levels, execution at L1 through L3 can already be delegated with reasonable confidence today: the user defines the problem and draws the boundaries, while the Agent "executes under predefined rules." The real bottlenecks lie in execution at L4 and in L5 as a whole.

L4: The Agent Defines the Problem, but Accountability Still Rests with the Human

At L4, the Agent identifies the problem by calculating the gap. If it gets that right, it saves me work; if it gets it wrong, I still bear the consequences. As long as this asymmetry remains, people will instinctively keep L4 at "Recommend."

Long time horizons make matters worse. Goals can drift over several weeks, and an Agent may keep advancing an outdated goal while the user is absent; the more diligently it calculates the gap, the farther off course it goes. For L4 to move upward, it therefore needs not only an initial goal but also a mechanism for ongoing alignment: at critical checkpoints, reconfirm, "Is this still the goal?"

L5: On Top of L4's Risks, the Agent May Infer the Wrong Goal

At L5, even the goal is inferred by the Agent, creating a second source of error:

L4 risk: the goal is correct, but the gap is calculated incorrectly.
L5 risk: the goal itself is inferred incorrectly, so every subsequent gap, problem, and task is wrong as well.

This is not hypothetical. According to media reports, Meta Muse's system instructions require it to infer users' goals, including goals they have "not stated"; to do so, it reads chats, messages, emails, and connected apps, which has also sparked considerable privacy controversy[5]. The capability to infer "unstated goals" may exist, but whether users want to be understood in this way is another matter. So, at least today, L5 is better kept at "Notify": tell me what you have observed, and let me decide whether it is my goal.

The Lever: Make Goals and Acceptance Criteria Explicit

Looking back at all the preceding examples, only one thing allows a task to move up the scale:

08_From_L5_to_L4_English
Figure 8 · The Lever: Make Goals and Acceptance Criteria Explicit

Make the goal explicit, and the Agent no longer has to infer it: L5 becomes L4.
Make the acceptance criteria explicit, and it becomes possible to verify whether the work was done correctly. Part of L4 becomes "execution under predefined rules," returning both problem definition and accountability to the user.

Knowledge-base promotion moves up the scale in exactly this way: from "inferring what I care about," to "calculating the gap against the goal of becoming an expert," and finally to "curating and adding topics directly to the knowledge base when they meet the predefined criteria."

How far a PA's proactivity can be extended therefore depends not only on how capable the Agent is, but also on how clearly people are willing to articulate their goals and rules. The Agent is responsible for calculating the gap accurately and moving the work forward; the human is responsible for defining the direction and boundaries clearly, and for recalibrating promptly when goals drift.

Proactivity is bounded by the goals that the human and the Agent can explicitly align on.

Turning This Framework into a Personal Agent with Qoder Cloud Agents

This framework is not only about how capable an Agent is; it also defines the infrastructure a PA product needs. Stable identity and memory sustain goals across sessions; Channel and Schedule provide events and timing; and a cloud execution environment allows actions to continue while the user is offline. Permissions, confirmations, and run logs address the risks associated with different execution categories.

If you also want to turn long-term goals, personal context, and continuous execution into a genuinely useful Personal Agent, start with https://qoder.com/en/cloud-agents.

Community