What Woke the Agent?

At 08:00, the renewal-risk agent wakes because it is 08:00. It checks Salesforce, scans the support queue, reads a Teams channel, asks for product-usage changes, and pulls the last account note, which was already stale when somebody wrote it. Nothing has happened, so it returns to sleep with a clean run log and a small bill.

By lunch, it has done this a dozen times. The team may call that proactive AI. The finance system will call it compute. The platform team will call it load. The account manager will ignore the notifications because most of them say nothing.

Then, at 14:37, the thing that matters happens. A support ticket from a renewal account is raised to severity one. Usage has already dropped. The executive sponsor changed jobs two weeks ago. Legal has an unresolved contract question. The event is sitting there in the business systems, crisp and timestamped.

The agent still waits for the next scheduled run.

When it finally wakes, it has to rediscover why the account matters. It loads too much context, misses the contract issue, pings the wrong owner, and drafts a generic account note that the customer-success lead quietly rewrites. Essentially, the save motion has started too late. The first internal escalation is noisy. The customer receives a thin response precisely when they need reassurance that someone truly understands their needs. Nobody built a broken model here, they built the wrong waiting architecture.

At OpenAI’s Intelligence at Work livestream, Sam Altman pointed to “constantly running proactive AI” as the next major phase after chat models and agent-style systems such as Codex. His larger point was that companies will have to change how they implement AI, starting now.

That implementation change is where things get interesting. If enterprises hear “constantly running” and respond by scheduling more model calls, they will recreate the oldest mistake in distributed systems with the most expensive component in the stack.

The architecture question has moved: what event gives the agent a reason to think?

That is the first question I would ask of any proactive AI design. If the answer is “a timer,” the system may still be useful. It can produce a Friday report, check a known queue, or send a recurring reminder. A timer proves that time passed. It says nothing about whether a business event occurred.

A serious proactive system starts with the event. A complaint crosses a severity threshold. Inventory falls below a buffer. A payment fails. A fraud score jumps. A supplier misses a milestone. A policy changes. A VIP customer goes quiet after a bad onboarding call. These are deterministic facts before they are reasoning problems.

Those signals rarely arrive ready for an agent. The runtime has to turn the raw change into a wake decision: resolve the business object, enrich the event just enough to route it, check the agent registry, and decide whether any hibernating agent should resume. Sometimes the answer should be no. Sometimes the event should be stored against an agent’s state and wait for a second signal. Sometimes it should wake the agent immediately because the next useful move requires judgment, language, or action.

That is the practical meaning of proactive AI at enterprise scale. The agent does not wander around the company looking for something to care about. The company tells the agent when something happened.

This distinction sounds small until it touches volume. Scheduled agents spend money on absence. Event-driven agents spend money on change. Once there are hundreds of agents watching thousands of queues, accounts, contracts, tickets, suppliers, documents, and policies, that difference stops being elegant architecture and becomes the operating cost of the AI program.

The agent runtime also needs a real lifecycle. Wake is only the first transition. A production agent should be able to acquire a work item, load its last checkpoint, take a lease on the relevant state, reason, call tools, write back a new checkpoint, and release the lease. If the work remains unresolved, it may stay active. If it is waiting on a human, a downstream system, a cooling-off period, or a future business event, it should hibernate with an audited state record.

That is the technical line I would draw. Perpetual loops are certainly not inherently wrong. Unbounded loops are. The problem is an agent that keeps thinking because nobody gave the runtime a safe way to stop, persist, and resume. A good design lets an agent stay awake while the decision is alive, and forces it to sleep once the next meaningful transition belongs somewhere else.

I think there are three somewhat unglamorous pieces that matter.

• The first is a trigger layer. Business systems have to publish state changes in a form other systems can trust. If a high-value account becomes a renewal risk, the signal should not live only as a human-readable note in a Teams channel. It should become a routable event.

• The second is an agent registry. Every serious agent needs a declared surface area: events it cares about, entities it owns, state it maintains, tools it may use, actions it can propose, actions it can take, and conditions under which it must hibernate. Without that registry, orchestration becomes vibes at machine speed.

• The third is audited state persistence. A hibernating agent has to remember where it left off, and the enterprise has to know what state it preserved. It should not rebuild its world from prompt fragments every time a scheduler wakes it. The account risk posture, last commitment, escalation history, open decision, pending dependency, and allowed next actions belong in durable state with a reason for the next wake-up.

This is where Enterprise Context Management becomes more than a governance phrase. Context is the condition that lets the agent resume intelligently after the business changes. It includes the event that woke it, the state it carried into hibernation, the business meaning attached to the customer or inventory item or policy, and the record of what the agent did next. At AI One, this is the architectural layer we think enterprises will have to get right as agents move from chat into operational workflows.

Governance must also be in the room, but I would not let it run the meeting. The more urgent implementation error is simpler: we are seeing teams use reasoning where infrastructure should do the waiting. That choice will show up as cost, latency, duplicate work, noisy escalations, and agents that seem busy while missing the moment they were supposed to catch.

It also changes vendor evaluation. Connector lists are table stakes. Scheduled runs are table stakes. Teams integration is table stakes. In a serious architecture review, I would ask for the wake trace: the source event, the routing decision, the agents left asleep, the checkpoint loaded into the agent that woke, the hibernation policy, the action boundary, and the record after execution. That trace tells you whether the product has an architecture for proactive AI or a scheduling feature with a model behind it.

OpenAI and Anthropic’s current workspace-agent direction is already pointing enterprises toward shared agents that can run workflows across tools, schedules, and applications like Email and Teams. That is a useful bridge because it gets companies thinking beyond chat sessions. The next step is richer than a schedule. Proactive AI needs a business event fabric underneath it and a runtime that knows when to stop thinking.

The cost pressure will help force this discussion. Axios reported Altman saying OpenAI’s top token user was using about 100 billion tokens per month, and that cost had become a huge issue amongst clients. Whether or not your enterprise is anywhere near that scale, the pattern is clear: once AI leaves the pilot budget, waste becomes visible. A single scheduled agent is easy to ignore. A fleet of agents polling every account, queue, channel, supplier, policy, and exception all day is a bill with an architecture diagram attached.

The right preparation is a wake-map exercise. Put one workflow on the wall. For renewal risk, write down the few events that deserve intelligence: severity-one ticket, usage drop, champion departure, procurement delay, legal blocker, failed implementation milestone. Draw the agents beside those events. Mark which agent owns account state, which one can act, which one should only recommend, what checkpoint it must write before sleeping, and which events wake a human immediately. If nobody in the room can say where the agent sleeps between those moments, the design is still a scheduled automation wearing an agent badge.

Altman also said that if there were one thing to prepare for over the next year, he would pick proactive AI. I agree. The preparation starts in the design review, with one awkward question on the table: what wakes this agent, what state does it carry back to sleep, and why is the model still thinking after the business event has moved somewhere else?