Act · task orchestration · ships with QuoxCORE
The orchestration spine powering agentic teams.
Every scheduled task and every autonomous objective in QuoxCORE runs through QuoxEngine. Built to recover, adapt, and deliver. The graph behind this page is the engine turning: an objective decomposed into tasks, each one igniting in dependency order as the execution front sweeps through.
Included in QuoxCOREFree, self-hosted, nothing to buy.
In plain words
What it is, where it lives, when to reach for it
- What is it
- The task scheduler inside QuoxCORE that runs objectives and scheduled work; it ships with every install.
- Where do I use it
- Inside your QuoxCORE instance; you watch its runs from the dashboard and the CLI.
- When would I use it
- When an agent's goal breaks into many tasks that must run in the right order.
- How do I use it
- You do not run it directly; it executes every objective, for example one made with
quox objective create.
QuoxCORE is the free, self-hosted platform underneath this. What is QuoxCORE
Why it exists
AI agents fail. What happens
next matters.
API timeouts. Malformed output. Rate limits. Model hallucinations. Service crashes. Every orchestrator hits these walls. Most give up or retry blindly. QuoxEngine recovers intelligently, adapts the approach, and keeps going. The graph behind this text is doing exactly that, on a loop.
- Crash mid-task→auto-detected, auto-recovered
- Task times out→retry with adjusted timeout
- Wrong output format→validated, guided re-execution
- Three failures in a row→circuit breaker, human escalation
What it is
The executive inside QuoxCORE.
QuoxEngine takes an objective in plain language and turns it into finished work. It decomposes the goal into a task graph with dependencies, agents and priorities, then sequences the tasks, delegates each one to the right specialist, and supervises the run until the objective completes.
It is the executive, not the workflow runner. Where QuoxFlow executes predefined node graphs, QuoxEngine plans at runtime: it decides what to do, in what order, with which agent, and what to do when something fails.
- Tasks survive service restarts and crashes
- Atomic task claim at the database level, so nothing runs twice
- Guided retry with exponential backoff
- Circuit breaker after three consecutive failures
- Structured JSON output, validated against schemas
- Shared team context updated after every completed task
How it works · live demonstration
Decompose. Execute.
Recover. Complete.
Describe what you want done. The engine does the rest. This is that loop, recreated: one sentence in, a task graph out, tasks running in parallel where they can, a failure recovered mid-run, a finished objective at the end.
Describe what you want done. The orchestrator breaks it into a task DAG with dependencies, agents and priorities.
Tasks run in parallel where possible. Each agent gets the right context from prior tasks. Heartbeats track liveness.
If something fails, the orchestrator decides: retry with a better prompt, skip and continue, or pause and escalate to a human.
Results are validated, structured and stored. The team context is updated. The next objective in the chain can begin.
▸ "Audit all hosts for security issues" becomes a task graph: enumerate hosts, scan each one in parallel, collate findings, file the report. You wrote one sentence. The hosts above are illustrative; the failure flow and log lines follow the engine's real kickback protocol.
Unique to Quox
Orchestrator-guided retry.
When a task fails, most systems retry with the same prompt and hope for a different result. QuoxEngine sends the failure to the orchestrator agent, which reviews the error, analyses what went wrong, and rewrites the prompt with specific fixes before retrying. You watched it happen in the run above.
The retry count, backoff schedule and error context are all included, so the orchestrator can make progressively different decisions. The first retry might adjust the approach. The second might try a different agent. The third triggers the circuit breaker.
Built for reliability
Every feature earned
in production.
Every capability here exists because something went wrong in a real run and we fixed it properly.
Crash recovery
Tasks survive service restarts. The orphan reaper sweeps on a 5 minute interval by default (configurable). Stale tasks are detected, recovered, and re-evaluated automatically.
orphan reaper · 5 min scanAtomic task claim
No double execution. Tasks are claimed atomically at the database level. If two schedulers reach for the same task, only one wins.
DB-level claim · exactly onceGuided retry
Failed tasks are not blindly retried. The orchestrator reviews the error, adapts the prompt, and tries a smarter approach. Exponential backoff included.
error-aware · adaptiveCircuit breaker
Three consecutive failures pauses the objective and escalates to a human. No more burning tokens on a broken plan.
3 strikes · human escalationStructured output
Tasks can define expected output schemas. Results are validated, stored as clean JSON, and passed to downstream tasks without lossy text truncation.
JSON Schema · validatedTeam context
Every completed task automatically updates the team's shared context. Later tasks build on earlier results without explicit wiring.
auto-accumulated · sharedSchedule resilience
Missed schedules are caught on restart. Overlap prevention stops stacking. Timezone-aware cron fires at the right time, everywhere.
tz-aware cron · no stackingObjective chaining
Objectives can depend on other objectives. Parent context flows to children. Save successful plans as reusable templates.
parent context · templatesTopology selection
Choose how your team coordinates: star (flat), hierarchical (pod leads), pipeline (sequential stages), or mesh (collaborative research).
4 modes · per teamLearning router
Tracks agent performance over time. Automatically routes tasks to the best-performing agent. Gets smarter with every objective.
performance-tracked · self-tuningEvery recovery action, retry decision and circuit break is recorded in the AEE/VOLT evidence chain for full auditability.
Policy-driven
Every team runs differently.
Retry limits, backoff schedules, circuit breaker thresholds, checkpoint frequency and concurrency are all configurable per team via the manifest. Same engine, different rules.
A security pod that checkpoints after every task and breaks the circuit early. A data pod that tolerates five failures before it stops. A content pod that never checkpoints at all. One engine reads them all.
# Example manifests. Yours can be stricter, # looser, or different per team. secops: max_retries: 3 backoff: [30s, 2m, 10m] circuit_breaker: after 2 failures checkpoints: after each task dataops: max_retries: 5 backoff: [1m, 5m, 15m] circuit_breaker: after 5 failures checkpoints: on failure only contentops: max_retries: 2 backoff: [30s, 2m] circuit_breaker: after 3 failures checkpoints: never
Two engines, one platform
QuoxEngine vs QuoxFlow.
Both ship with QuoxCORE. They solve different problems and work together. QuoxEngine handles adaptive, AI-driven objectives. QuoxFlow handles deterministic, pre-built automation pipelines.
| QuoxEngine | QuoxFlow | |
|---|---|---|
| What it does | Executes objectives: decomposes goals into tasks, assigns agents, handles failures, manages context | Executes workflows: runs predefined node graphs with conditions, loops and integrations |
| Input | A natural language objective ("Audit all hosts for security issues") | A pre-built workflow definition (JSON node graph) |
| Planning | Dynamic: the orchestrator LLM decomposes at runtime | Static: the workflow is defined up front by the builder |
| Agents | 49 specialist agents with a learning router | 28 node executors (SSH, HTTP, condition, and more) |
| Topology | 4 modes: star, hierarchical, pipeline, mesh | Fixed node graph (no topology selection) |
| Recovery | Guided retry, circuit breaker, fallback routing, crash recovery | Node-level retry, error branches |
| Best for | Complex, adaptive, multi-agent tasks that need reasoning | Repeatable, deterministic automation pipelines |
| Ships with | QuoxCORE (built in) | QuoxCORE (built in) |
QuoxEngine can convert successful objective runs into QuoxFlow workflows for repeatable automation.More about QuoxFlow →
Under the hood
The scheduling machinery.
Execution model
- DAG-based task decomposition
- Parallel execution with dynamic concurrency
- Fan-in with partial results from failed dependencies
- Task priority ordering, critical path first
Resilience
- Heartbeat persistence in the database, not just SSE
- Orphan reaper on a 5 minute scan interval, configurable
- Status state machine, invalid transitions blocked
- Cancellation guards on all completion paths
Intelligence
- Orchestrator kickback for retry decisions
- JSON Schema output validation
- Team context auto-accumulation
- Configurable per-team policies
Where it stands
What's proven, what's still beta.
This maturity map covers the objective-orchestration engine described above, not the marketing copy around it.
- Auto-approve into execution does not strand: the poll deadline was widened and a timed-out approval now logs a warning instead of leaving the objective stuck (Stable)
- Atomic task claim at the database level is real: two schedulers reaching for the same task cannot both win it
- Four topology types, star, hierarchical, pipeline and mesh, are validated by the team manifest loader, not just described in copy
- Objective creation and decomposition, the orchestrate_objective tool itself, is Beta: it works end to end for the happy path, not yet hardened against edge cases
- The learning router that scores agent performance over time exists in code with no formal maturity rating yet; treat it as unproven until it has been measured
- The nightly Engine Validation Suite that would prove out these reliability claims has never run in this deployment: the flag exists and is intentionally left off
- Browser-Q, one of the platform’s own agents, does not run its objectives through this engine yet; that migration sits behind an unset flag, out of stream
- The per-team policy manifest shown above (max retries, circuit breaker threshold, checkpoints per team) has no evidence of being read by the team loader or decomposer today; treat it as illustrative, not a wired, live path
Ready when you are
The spine is ready. Build on it.
QuoxEngine ships with every QuoxCORE installation. No extra setup, no add-on pricing. Every plugin, every team, every scheduled task runs through it.
Go deeper