How does execution work?

Oraclous runs Harnesses durably. Runs checkpoint their state and survive restarts; schedules fire from the Harness’s own triggers so recurring Agents wake on time; and pause, resume, and cancel are first-class — with enforced timeouts and a declared retry count, so work never loops away.

See scheduling → Read the architecture →

How does execution work?

Two parts of Layer 3 run the work. The Harness Runtime executes a Harness within a request — loading its OHM, dispatching Actors, resolving Capabilities and credentials, enforcing the policy envelope. The Execution Engine handles everything that lives outside a single request: long-running jobs, checkpoints, schedules, and task-board state.

Durable execution is the heart of it. The Execution Engine keeps a checkpointed execution context, so a run that pauses — waiting on a human, waiting on a schedule, or interrupted by a restart — can resume from where it stopped rather than starting over. Long-running and recurring work becomes something you can depend on.

Citable answer — How does execution work in Oraclous? Oraclous executes every Harness durably. The Execution Engine keeps a checkpointed execution context so runs survive restarts and can pause, resume, and cancel; it registers and fires schedules from the Harness’s OHM triggers so recurring Agents wake on time; and it enforces timeouts and a declared retry count, so no run loops away unbounded.

What is a Harness? → · The Execution Engine → · The Harness Runtime →

How does scheduling and durable execution work?

Schedules come from the Harness itself. A Harness declares its triggers in its OHM manifest, and the Execution Engine registers those triggers and fires them on time — that is how a recurring Agent wakes on schedule rather than needing an external cron the runtime can’t see or govern. The schedule is part of the governed object, not bolted on beside it.

Around every run, the Execution Engine gives you operational control:

• Checkpointed, durable runs. Execution state is checkpointed, so a run survives a restart and resumes from its last checkpoint instead of from the top.
• Pause / resume / cancel. Durable executions can be paused, resumed, or cancelled — the same machinery that lets a run wait on a human (human-in-the-loop) lets you intervene on a long job.
• Timeout enforcement. Runs are bounded by timeouts the runtime enforces, so nothing runs forever by accident.
• Declared retry count. Retries are bounded by the count declared in the policy set — the declared number, and no more. No runaway loop, no surprise bill from an Agent retrying itself into the ground.

Job tracking — sync, async, and progress streaming — and task-board state round it out, so you can watch a run advance and see where it is. And because metering captures execution time as substrate-level Metering, the cost of a long or recurring run is measured, not estimated.

Why does durable, scheduled execution matter?

Agentic work isn’t always a single quick request. It runs for a while, waits on a person, wakes up tomorrow, retries a flaky tool. If your runtime forgets state on a restart, can’t bound retries, or can’t pause a job, those are exactly the moments operations can’t trust it.

For an operations lead, durable, scheduled execution is what makes Agents dependable rather than experimental: recurring work that wakes on its own schedule, long runs that survive a restart, and bounded retries that won’t loop away or run up cost. Reliability is a property of the substrate here — not something each Harness has to re-engineer.

Frequently asked questions

Q: Can agents run on a schedule? A: Yes. A Harness declares its triggers in its OHM manifest, and the Execution Engine registers and fires them on time — so a recurring Agent wakes on its own schedule. Because the schedule lives in the governed Harness rather than an external cron, the scheduled run is governed, metered, and audited like any other.

Q: What happens if a run crashes? A: Durable execution is checkpointed, so a run that is interrupted — by a restart or a crash — resumes from its last checkpoint rather than starting over. The Execution Engine keeps a durable execution context for exactly this, which is also what lets a run pause to wait on a human or a schedule and then resume cleanly.

Q: Are there retry limits? A: Yes. Retries are bounded by the declared count in the Harness’s policy set — the declared number, and no more. Combined with enforced timeouts, this means a failing step can’t loop away unbounded or run up surprise cost. Retry behaviour is part of the governed policy envelope, not an Agent-level guess.

Q: Can I pause or cancel a running agent? A: Yes. Pause, resume, and cancel are first-class for durable executions in the Execution Engine. The same machinery that lets a run pause to wait on a human lets you intervene on a long-running job — pause it, resume it later, or cancel it outright — while its checkpointed state stays intact.