Most AI agent systems poll constantly. They check for work, check for updates, check for changes—burning tokens and compute on the question "is there anything to do?" before they ever do anything.
Owen doesn't work that way.
The Cost Problem
Running an AI agent is expensive. Not "a few dollars a day" expensive—potentially "hundreds of dollars a day" expensive if you let it run unchecked. The naive approach is to have the agent constantly monitor your inbox, your calendar, your task queue, and react when something changes.
But monitoring is cheap. A simple daemon checking for new emails costs fractions of a cent. An AI agent evaluating those emails costs real money. The architecture insight: separate the monitoring from the execution.
Wake-Driven Execution
Owen follows a wake-driven execution model. The Owen daemon runs continuously, monitoring cheap signals:
- New emails arriving
- Calendar events approaching
- Tasks entering "ready" state
- External triggers via webhooks
When something needs attention, Owen wakes the AI agent. The agent doesn't poll—it gets invoked with context. This is push-driven, not pull-driven.
The difference matters. A polling agent might check email 100 times to find 1 message worth acting on. A wake-driven agent gets invoked once, with the message already identified as worth processing. That's a 100x reduction in agent invocations for the same outcome.
The Checkout/Checkin Lifecycle
When Owen wakes an agent, it doesn't just say "go handle things." It uses a structured checkout/checkin lifecycle with a 30-minute TTL.
Checkout happens when Owen assigns work to an agent. The agent receives:
- The specific task(s) to work on
- Relevant context from the task system
- Constraints (time budget, scope limits)
- The persona to operate as
The agent then has 30 minutes to complete the work and checkin. If it doesn't checkin, Owen assumes something went wrong and can escalate or reassign.
Checkin Statuses
When the agent checks in, it reports one of five statuses:
- resolved: Task complete, nothing more needed
- partial: Made progress, but more work remains
- escalated: Needs human decision or approval
- deferred: Can't do now, try later (with reason)
- cannot_do: Fundamentally blocked, needs human intervention
This isn't just status reporting—it's structured handoff. Each status carries different implications for what Owen does next. A resolved closes the loop. An escalated pages me. A deferred goes back in the queue with context about when to retry.
Four Personas
Not every task needs the same agent behavior. Owen uses four personas:
mail — Email triage and response. Conservative, professional, careful about sending anything externally without approval.
code — Development tasks. Can commit, can create PRs, operates within the codebase.
plan — Planning and organization. Breaks down large tasks, sequences work, manages dependencies.
claw — General purpose. The default for tasks that don't fit the others.
Each persona has different default permissions, different prompt context, and different escalation thresholds. The mail persona won't send an email without explicit approval flags. The code persona won't push to main without CI passing.
Agent-Safe Tags Default False
Here's a design decision that saved me grief: agent-safe tags default to false.
Every task in Owen can be tagged with whether an agent can safely work on it autonomously. But the default is "no"—if a task doesn't explicitly say it's agent-safe, the agent treats it as requiring human oversight.
This is defense in depth. New tasks, imported tasks, tasks created by humans who didn't think about agent safety—they all default to the safe behavior. The agent only operates autonomously on tasks that have been explicitly marked for autonomous operation.
Defaults matter. Safe defaults matter more.
OpenClaw as the Runtime
OpenClaw provides the actual agent runtime—the ability to invoke Claude, manage sessions, handle tool calls. Owen provides the orchestration layer on top.
The integration is clean:
- Owen monitors and decides when to invoke an agent
- Owen prepares context and decides what the agent should do
- OpenClaw handles how the agent executes
- The agent checks back in to Owen with results
This separation means I can swap runtimes (if a better one emerges) or swap orchestration layers (if someone else's Owen-equivalent is better) without rebuilding everything.
Why This Matters
The wake-driven model solves the economics of AI agents. Running an agent 24/7 is expensive. Running an agent when there's work to do is affordable. The checkout/checkin lifecycle solves reliability—I know if an agent is stuck, and I know when work completes. The persona system solves scope—different tasks get different agent behaviors. The safe-by-default tags solve trust—the agent only acts autonomously where I've explicitly said it should.
None of these are novel ideas. Wake-on-LAN has existed for decades. Job queue systems have used checkout patterns forever. Role-based access is as old as computing.
The insight was applying them to AI agent orchestration, where the cost model makes the architecture choices unusually consequential.
Current State
This is running in production for my personal task system. Owen processes several hundred tasks per week, with the AI agent handling probably 30% of them autonomously. The rest require human input at some point—usually quick approvals or decisions that the agent correctly identified as needing escalation.
The cost is reasonable. A few dollars a day in API calls, mostly because the agent only wakes when there's actual work to do. The naive polling approach would cost 10-50x more for worse results.
Wake-driven execution isn't just cheaper. It's better—because the agent always has context, always has a specific job, and always knows how to report completion. Structure enables autonomy.