Infrastructure Primitives That Make Proactive Agents Wake With Full Memory Intact

Persistent and scheduled autonomous agents at scale need four infrastructure primitives working together, which are persistent state stores, wakeup schedulers, event triggers, and context-restoration protocols. Memory-intact wakeup depends on their coordination. Choosing a platform therefore means deciding which primitives it manages and which integration work it leaves to the developer.

The four primitives are persistent state stores, wakeup schedulers, event triggers, and context-restoration protocols. The state store keeps core, recall, and archival memory between sessions. The scheduler wakes the agent on a clock, and the event trigger wakes it when something happens, such as a Slack message, GitHub push, or monitoring alert. The restoration protocol then hydrates the context window from memory before the agent decides to act or sleep, and writes updated state back before it sleeps again.

Why request-response is the wrong model for autonomous agents

A request-response system can answer brilliantly and still wait forever for someone to ask because of its architectural limit. A reactive assistant needs a model and a fast inference path, while a proactive agent also needs stored state, independent activation, external signals, guardrails, and rules for when to interrupt a human. The model alone provides none of those.

Sharma and Shah’s June 2026 work on agent operating systems identifies the underlying mismatch. Traditional operating-system abstractions assume deterministic programs, explicit control flow, and human-initiated workflows with bounded behavior. Agentic systems break those assumptions because they carry work across sessions and act without a fresh request. For memory-intact proactivity, the gap between a convincing demo and a production agent comes down to a small set of infrastructure primitives.

What an agent operating system is supposed to provide, and why existing tooling doesn't

The Agent Operating System (AOS) proposal separates responsibility into a Control & Governance Plane and a Runtime & Coordination Plane [1]. The first governs intent, policy, trust, authority, confidence, auditability, and human oversight. The second coordinates execution, including agent lifecycle, workflows, model and tool routing, memory, scheduling, traffic, and runtime assurance. Execution and permission are distinct responsibilities, but they must agree.

This is a proposed operating architecture. Its premise is that existing frameworks and cloud tools improve execution without supplying stable, implementation-independent rules for governing the whole system. Scheduling, context management, capability registries, and trust enforcement become explicit responsibilities. Builders assembling separate cloud services are approaching the same target, but composition alone does not establish shared guarantees. The missing specification is how those services preserve state and authority when execution crosses their boundaries.

Persistent state stores: what agents remember and how they remember it across sessions

Persistent state gives an agent work it can pick up again. Without it, a wakeup creates another fresh session. Context hydration retrieves relevant stored information and puts it into the active context window before an interaction begins. The store and the context window therefore serve different roles, with one preserving information across sessions and the other supplying what the current execution needs.

The memory stack has three tiers with different retrieval duties. Core memory stays in context and holds identity, goals, and active task state, with the agent editing it through tool calls. Recall memory provides searchable conversation history for recent episodic context. Archival memory uses external vector or graph databases for long-term knowledge and semantically similar summaries from earlier conversations. These distinctions make memory selection part of execution. An agent can read, write, and modify persistent blocks rather than treating memory as a transcript saved after the fact.

The same state must also survive changes of interface. If a conversation begins in one interface and continues in another, separate session stores make context loss structural. A platform-agnostic database accessible to all agent instances addresses that boundary, while dependable stored state requires durability and consistency. Yet shared memory only answers what the agent knows. Something still has to decide when it runs.

Wakeup schedulers: how an agent initiates action without a human prompt

A wakeup scheduler activates an agent independently of user input. Cron-based daily digests and nightly reports are straightforward examples. Unlike an event-triggered agent responding to an incoming message, a scheduled agent can begin a chain of consequential work without a human initiating it. That makes scheduling part of the operating infrastructure rather than merely a choice inside the reasoning loop.

A heartbeat offers a familiar version of this mechanism. An external scheduler pings the agent at regular intervals, after which the agent evaluates its context and either acts or returns to sleep. The heartbeat functions as both a keepalive and a trigger surface. Does every heartbeat need to lead to work someone can see? No, because waking to evaluate a situation is different from deciding that action is warranted.

To make that choice, the agent needs the memory store described earlier. Activation must also start context hydration, or the scheduler keeps waking an agent that cannot remember its task. A reliable clock is insufficient on its own. The scheduled process must resume with enough state to decide whether work is due.

Event triggers: letting external signals, not clocks, initiate agent work

A scheduler asks whether it is time, while an event trigger asks whether something happened. The distinction becomes important when the next heartbeat would arrive too late. A Slack message, GitHub push, or monitoring alert can each call for work outside the fixed schedule. The trigger layer must normalize these different sources into a consistent wakeup signal.

The 2026 proactive-assistant architecture preprint separates an always-on trigger, a context provider, and a downstream agent. The trigger decides when to interrupt, the provider selects memory entities, and the agent produces the user-facing action. Its lightweight temporal graph trigger, TGL, had per-event latency of 11.13 ms, roughly 4–7× faster than the two single-forward LLM-as-trigger configurations tested. A single TGL checkpoint served every language-agent backend.

Having the model gate its own wakeups spends inference on a decision a dedicated component can make more efficiently. This does not make scheduling obsolete, because clocks and external changes serve different workflows. Both must connect to persistent memory through a common activation path. But a trigger and a store still leave a question unanswered. How does the agent arrive with the right context already loaded?

How does an agent wake up with the right context already loaded?

A context-restoration protocol specifies what activation must restore. After a trigger fires and the scheduler activates the process, the protocol queries core, recall, and archival memory in priority order. It then injects relevant state into the active context window before the agent evaluates its situation. The agent can act or return to sleep. This sequence makes the agent seem aware all the time even though it does not run all the time.

Restoration also needs a defined response to stale memory. Without one, separate components may work correctly while the agent acts on an outdated account of its task. The protocol must include a write-back step that commits session state to persistent storage before the agent sleeps. Otherwise, the next wakeup can faithfully retrieve information that no longer describes the current situation. Scheduling and memory coordination must therefore share the same rules for durability, consistency, and failure recovery.

Would a much larger context window remove this requirement? It would increase capacity, but not determine relevance. Loading everything is context dumping, whereas restoration selects information for the current task. Memory tiers and retrieval logic remain necessary because the agent needs an appropriate working context.

How MCP and A2A fit into the primitive stack as the connective tissue between agents and their environment

MCP and A2A extend the four primitives beyond internal state. An agent requesting database records uses MCP, while an agent delegating a subtask to another agent uses A2A.

That division gives the primitive stack a way to reach its environment. Memory retrieval can draw on connected data sources, outside systems can send signals, and an agent that wakes can act through tools or peers. The Agentic AI Foundation includes Anthropic, OpenAI, Google, Microsoft, AWS, Block, Cloudflare, and Bloomberg, reflecting the broader push toward shared agent infrastructure. Standardized interfaces let the restoration contract operate across component boundaries.

What platforms let agents run on a schedule without rebuilding persistence?

A runtime choice determines which primitives arrive managed. The relevant criteria are durable state, scheduler integration, event-source support, and context-restoration guarantees, with isolation and observability underpinning all four. The platform landscape divides into managed hyperscaler runtimes, framework-native platforms, and sandbox or serverless runtimes. These categories offer different starting points.

AWS Bedrock AgentCore bundles Runtime, Memory, MCP Gateway, Identity, Browser, Code Interpreter, and Observability. It went GA on October 13, 2025, with its harness reaching GA on June 17, 2026. Its 8-hour execution limit and session isolation are constraints for long-running work. A buyer still needs to establish how activation and stored state reconnect.

Google Gemini Enterprise Agent Platform, announced April 22, 2026, includes an Agent Runtime with sub-second cold start and multi-day workflows, plus Agent Sandbox, Memory Bank, and Agent Studio. Those capabilities make workflow duration and managed memory useful comparison points against AgentCore. Azure AI Foundry Agent Service also belongs to the managed hyperscaler category. The details given do not show that these services make the same scheduling or restoration guarantees, so treating their features as interchangeable would make it harder to choose what to build on.

Framework-native platforms provide orchestration and some state management but typically leave scheduling and trigger design to developers. Modal, Daytona, Fly.io Machines, and Cloudflare Agents occupy the sandbox and serverless category, which emphasizes isolation and cold-start performance. Cloudflare Agent Memory, announced April 17, 2026, adds managed extraction and retrieval of conversation information without filling the context window.

How the four primitives compose in practice, and what breaks when one is missing

In the complete sequence, an event arrives, the trigger fires, and the scheduler activates the agent process. The restoration protocol hydrates context from the memory store before the agent evaluates and acts. Write-back commits the updated state, and the agent sleeps until another event or scheduled interval. Each handoff has a distinct responsibility. That separation makes missing components diagnosable rather than leaving every failure to look like poor model reasoning.

Without persistent state, the agent can react to the immediate signal but cannot recover prior goals or preferences. It wakes as a fresh session every time. Without a scheduler, an agent with intact memory still has to wait for incoming activation and cannot start scheduled work on its own. Without event triggers, scheduled work continues, but time-sensitive changes between heartbeats cannot initiate a response. Each omission removes a different part of proactivity.

The trigger, scheduler, and store can all exist while the agent runs with stale or incomplete context. It may then behave confidently on the basis of information that was correct in an earlier session. The system looks assembled, but its handoffs are incomplete. The AOS two-plane model helps explain why these handoffs need OS-level invariants, guarantees that hold across components so each component can rely on more than what it assumes about its neighbor.

What building on these primitives requires from the infrastructure layer beneath

Running hundreds of long-running agents asks more of the infrastructure beneath the four primitives. Durable execution means the scheduler keeps its jobs when its host process restarts. Consistent state requires transactional guarantees, because a silently failed write-back contaminates the next restoration. Low-latency dispatch keeps event-driven work responsive to incoming signals. These are baseline properties of a durable, event-driven, stateful workload.

Auditability must reach inside the restoration process itself. The protocol needs to log what was loaded, which memory tier supplied it, and why it was selected. Otherwise, diagnosing a wrong action cannot distinguish bad reasoning from bad context. The runtime also has to handle lifecycle, workflow coordination, routing, traffic management, and runtime assurance.

General-purpose cloud services offer these features through separate schedulers, stores, event buses, and logging pipelines. An agent operating layer built for this job can give teams one interface and hide the work of connecting those services. Low-friction onboarding, ideally through a curl-installable runtime, is valuable when it delivers the correct composition without requiring every team to rebuild it. Ease of installation is not itself a reliability guarantee. The decisive property is whether the runtime preserves the wakeup-to-write-back contract when sessions end, processes restart, and the next signal arrives.