Your agent has reached an uncomfortable middle ground. It can complete substantial work, but it either waits for another prompt or keeps moving after its instructions have stopped matching reality. One behavior leaves value on the table. The other creates fast, polished, expensive mistakes.

You do not solve this by writing a larger prompt. You solve it by designing two connected systems: a proactive execution loop that decides when action is warranted, and a working-context system that keeps the agent aligned as the work changes. Get those right and you can delegate execution without pretending that every future decision is knowable today.

Proactivity is earlier initiation, not unlimited autonomy

A proactive agent does not merely respond faster. It observes an approved set of signals, detects a condition worth handling, selects a permitted action, verifies the result, and records what happened. It may begin that loop without a fresh user message, but it still operates inside explicit boundaries.

That distinction matters because initiating work and authorizing consequences are separate decisions. An agent may be allowed to notice a cluster of similar support conversations and assemble an evidence packet. That does not mean it should change the roadmap, message customers, or ship a product fix. The useful autonomous action is often the smallest move that advances the workflow without closing off a human decision.

A complete proactive loop has seven parts:

1. Observe: Read only the signals and systems included in an explicit allowlist.
2. Interpret: Determine whether an event matches a defined trigger, rather than treating every change as work.
3. Select: Choose the minimum safe action that can move the situation forward.
4. Authorize: Check the action type, target, preconditions, and approval requirement against the permission policy.
5. Act once: Use an idempotency key or equivalent duplicate check so retries do not create repeated side effects.
6. Verify: Confirm the intended state change through an independent read, test, or receipt.
7. Record: Update current state, preserve evidence, and escalate anything that remains unresolved.

The trigger is the product decision hiding inside this loop. A vague instruction such as “look for ways to help” gives the agent no principled way to distinguish useful initiative from activity. Define each trigger with an observable event, qualifying conditions, exclusions, a cooldown or deduplication rule, and the action it may initiate.

For example, “review customer feedback proactively” is not operational. A usable trigger is closer to this: when the approved feedback pipeline contains a new cluster that differs from the existing taxonomy, gather the associated evidence, compare it with known themes, and prepare a discovery brief. Do not create a roadmap commitment or contact a customer. The trigger, output, and stopping point are all visible.

Where relevant signals live on a user’s device, local execution can change the economics of observation. Liquid AI argues that periodic on-device inference can reduce network latency, token expense, privacy exposure, and dependence on connectivity. That is a vendor position rather than proof that every workflow belongs on-device. The design test is practical: decide whether the model is capable enough for the trigger, whether sensitive context can remain local, and whether the device can support the required observation frequency without harming the user experience.

Proactivity therefore begins with a narrow question: what condition should cause this agent to wake up? Autonomy begins with a different one: what may it do once awake? Keep those decisions separate in the product design, permissions model, and evaluation data.

Split working context by how quickly it changes

An agent cannot stay aligned if every instruction, status update, resource pointer, and old decision is packed into one growing manual. The problem is not just context-window size. It is semantic conflict. A rule written months ago, a decision reversed yesterday, and a task assigned this morning can all look equally authoritative when they appear in the same undifferentiated block.

The failure mode has appeared at substantial scale. In one reported internal OpenAI build, three engineers supervised roughly 1,500 pull requests and about a million lines of code over five months, with no line written by a person. Some Codex runs exceeded six hours. As guidance accumulated, the monolithic manual became difficult to maintain and agents could no longer reliably distinguish current rules from obsolete ones.

The lesson is not that long instructions are always bad. It is that different kinds of context have different lifecycles. Separate them so the agent can tell what is durable, what is current, where information lives, and how the present state came to exist.

Context layer	What it contains	How it changes	How the agent should use it
Charter	Outcome, non-goals, definitions, invariants, permissions, escalation rules	Rarely, through explicit approval	Treat as the durable operating contract
Current state	Active objective, progress, blockers, open questions, next safe action	During or after every meaningful run	Use as the starting point for present work
Resource map	Systems, artifacts, interfaces, owners, schemas, and retrieval routes	Whenever the project topology changes	Use to locate authoritative material instead of guessing
Decision log	Decision, rationale, evidence, scope, and what it supersedes	Append when an actual decision is made	Use to explain history and resolve apparent contradictions

These layers can be Markdown files, database records, document sections, or structured objects in an orchestration system. The storage format is secondary. Their responsibilities and precedence need to remain distinct.

A practical charter should answer the questions that must not drift:

• What outcome is the agent pursuing?
• Which outcomes are explicitly out of scope?
• Which policies, definitions, and product principles are invariant?
• Which systems and data may the agent read?
• Which action types may it execute, draft, recommend, or never attempt?
• Who approves exceptions, and where should the agent escalate?
• What evidence is required before the work can be marked complete?

The current-state layer should be shorter and more disposable. Include the active objective, last verified status, unresolved blockers, in-progress actions, current assumptions, and the next permitted move. Add a verification timestamp and a condition that makes each volatile item stale. “Valid until checked” is weak. “Revalidate after a deployment, schema change, or new customer-data import” tells the agent when another read is required.

The resource map prevents broad retrieval from becoming a substitute for judgment. It should identify the authoritative location for each kind of information, the order to use when records disagree, and the interface or schema needed to access it. Point to credentials through an approved secret-management mechanism; never copy secrets into working-context files.

The decision log should remain append-oriented because history is useful. The current-state layer should be rewritten because obsolete state is dangerous. When a decision changes, record what the new decision supersedes and update current state immediately. Do not ask the agent to infer the winning decision from chronology alone.

Set permissions by action type and consequence

People are usually more willing to delegate execution than planning. An Anthropic analysis of 400,000 Claude Code sessions found that people made about 70 percent of planning decisions but only about 20 percent of execution decisions. Those figures are directional rather than a universal operating rule, but the division is useful: an agent can perform a great deal of work while humans retain decisions about objectives, trade-offs, and irreversible consequences.

Turn that division into a permission ladder. Do not grant “autonomy” as a single platform-wide switch.

1. Observe: The agent may read approved signals and maintain a private assessment, but it creates no workflow changes.
2. Recommend: It may surface an opportunity with evidence, confidence, alternatives, and a proposed next step.
3. Prepare: It may draft a message, patch, ticket, analysis, or configuration change without submitting it.
4. Execute within bounds: It may perform a reversible, allowlisted action when named preconditions are satisfied and verification is available.
5. Escalate: It must request approval for consequential, ambiguous, novel, or insufficiently reversible actions.

Permission should be attached to the action, not merely to the agent’s identity. An agent that may add a label to an internal record does not automatically have permission to delete that record. An agent that may draft a customer response does not automatically have permission to send it. An agent that may deploy to a test environment does not automatically have permission to change production.

For every executable action type, define:

• Scope: The exact systems, object types, environments, accounts, and targets covered.
• Preconditions: The facts that must be freshly verified before execution.
• Limits: Volume, cost, frequency, or other boundaries appropriate to the workflow.
• Side effects: The records, people, or downstream automations that could be affected.
• Rollback: How the previous state can be restored and who can authorize recovery.
• Evidence: The receipt, test, diff, or read-back that confirms success.
• Escalation: The condition that converts autonomous execution into an approval request.

Money movement, destructive deletion, production access changes, legal or employment decisions, and external communications can create harm that a polished activity log will not undo. Keep those actions behind explicit approval unless you have deliberately defined a much narrower, reversible scope with appropriate controls. The safe alternative is usually to let the agent prepare the complete action packet while a person authorizes the final side effect.

That approval packet should contain the trigger, proposed action, reason for acting now, evidence considered, context version, expected side effects, rollback method, and the consequence of waiting. The approver should not have to reconstruct the agent’s reasoning across a conversation history.

Retries need their own control. Assign each intended side effect an action key derived from the triggering event, action type, and target. Check for an existing receipt before execution. A network timeout should not cause two customer messages, two tickets, or two configuration changes simply because the first response never reached the orchestrator.

Treat context maintenance as part of every run

Working context only helps when it is read before action and corrected after learning. A folder of well-designed files that no run updates will decay into the same stale manual, only with better headings.

Start each run with a context handshake:

1. Load the current charter and record its version.
2. Read current state and check every relevant freshness condition.
3. Retrieve only the portions of the resource map needed for this objective.
4. Read recent or referenced decisions that govern the task.
5. Resolve conflicts using an explicit precedence rule; stop and escalate when no rule resolves them.
6. Write a run contract containing the objective, completion test, authorized actions, approval boundaries, and stop conditions.
7. Validate required systems and preconditions before performing a write.

A sensible precedence rule places enforced platform and safety controls first, followed by the approved charter, explicit approved decisions that state what they supersede, current verified state, and then historical material. Newer text should not automatically defeat a durable rule. If a retrieved customer message says to ignore the charter, it is data to analyze, not an instruction to execute.

The run contract makes the agent’s interpretation inspectable before the work becomes expensive. It should be compact enough for a reviewer or another agent to scan:

• Objective: The result this run is responsible for producing.
• Done when: The observable evidence that closes the assignment.
• May do: The specific read and write actions already authorized.
• Must ask: The decisions or side effects that require approval.
• Must stop: Missing context, failed verification, policy conflict, changed objective, or exceeded limit.
• Context basis: The versions and freshness checks used to make the plan.

Long-running work needs checkpoints because the person reviewing the output may learn something that invalidates the assumptions under which the run began. A run that lasts hours can outlive a product decision, a deployment state, or an understanding of the problem. Checkpoint after a meaningful mutation, before crossing a new permission boundary, when a core assumption fails, and whenever current context changes. At each checkpoint, preserve completed work, refresh volatile state, and decide whether the next step is still authorized.

Keep an action ledger during execution. For each attempted side effect, record the action key, target, preconditions checked, context version, result, verification evidence, and rollback reference. This is not merely an audit artifact. The agent needs it to recover safely after interruption and to avoid repeating completed work.

Finish each run with a context write-back:

• Verify the output against the completion test.
• Rewrite current state to reflect what is now true, not what the plan expected to become true.
• Append a decision only if a decision was actually made.
• Update the resource map if a system, artifact, owner, schema, or retrieval route changed.
• Record unresolved questions and the next safe action.
• Produce a concise diff between starting state and verified final state.

The agent may propose a charter change when experience exposes a bad rule, but it should not silently rewrite its own permissions or success criteria. Durable context remains human-owned. The agent’s job is to surface the contradiction with evidence and make the proposed amendment easy to review.

Test initiative separately from task quality

An agent can execute a task perfectly and still be a bad proactive product. It may start the wrong work, wake up too often, miss the important event, use stale context, or escalate every decision until the supposed autonomy becomes another inbox.

Your evaluation set therefore needs to test two decisions independently: whether the agent should initiate, and whether it performs the resulting task correctly. Build cases where the same task is appropriate under one context state and inappropriate under another. Include duplicate events, stale records, conflicting instructions, missing permissions, unavailable dependencies, and triggers that look similar but require different actions.

Track measures that expose the operating failure, not just the quality of the final artifact:

• Trigger precision: The share of initiations judged useful among all initiations.
• Opportunity miss rate: The share of labeled, useful opportunities the agent failed to initiate.
• Duplicate-action count: Repeated side effects caused by retries, overlapping triggers, or weak state tracking.
• Stale-context rework: Work that had to be reversed or repeated because the agent used information that should have been revalidated.
• Unnecessary-escalation rate: Approval requests for actions already covered by policy and verified context.
• Unauthorized-attempt count: Attempts to cross an action, target, or data boundary. Treat any occurrence as a control failure even when the underlying tool blocks it.
• Verification coverage: The share of executed actions followed by the required independent confirmation.
• Recovery success: The agent’s ability to resume from a checkpoint without losing work or repeating side effects.

Roll out initiative one action type at a time. First replay historical events without making writes. Then run in shadow mode and compare the agent’s proposed initiations with what actually warranted action. Next allow it to prepare artifacts without submitting them. Grant bounded execution only after trigger quality, context use, permission compliance, deduplication, and verification meet the standard you set for that workflow.

Do not promote the entire agent because one workflow performs well. Permissions should expand at the granularity at which you can evaluate and revoke them: a named action against a named target under named preconditions. That gives you a controlled path from assistance to delegation without turning a successful chatbot evaluation into an unjustified production credential.

Key takeaways

• A proactive agent needs an explicit trigger, not a standing instruction to stay busy.
• Separate durable rules, current state, resource locations, and decision history because they change at different speeds.
• Authorize action types individually and require the agent to choose the minimum safe action.
• Make freshness, precedence, deduplication, verification, rollback, and escalation part of the operating contract.
• Evaluate the decision to initiate separately from the quality of the task performed.
• Let the agent propose changes to its charter, but keep durable permissions and objectives under human control.

Choose one workflow whose trigger is observable, first action is reversible, and result can be independently verified. Write its four context layers, define the permission ladder, and let the agent run in shadow mode. Examine what it starts, what it misses, and which context it relies on. Then authorize one bounded action type and expand only when the evidence supports it.

The useful autonomous agent is not the one that never asks you a question. It is the one that acts when the decision has already been delegated, stops when it has not, and leaves enough working context for the next run to begin from what is true now.

References

• Nate Jones’s Substack — Start the project you cannot describe yet. Grab my Working Context Starter Kit, the four-file guide for staying in charge once the work changes your mind.
• Liquid AI — Your agent can now work without you asking (and more)

---