“Can I let it run while I sleep?”
Most tools ask you to jump straight to autonomous, before you have ever watched it get the work right.
autonomy: Approve every step. Then let it run.
ConvOps runs the same governed workflow attended or on its own. Start with approvals on every step. As trust grows, let the work run on its own. Same workflow, same rules, with or without you watching.
attended by default · schedules · work pools · a record for every run
attendedyou, in Claude Code monday · 10:00
pick workrecallfixtestclose
same workflow · same rules
unattendednobody at the keyboard every night · 02:00
pick workrecallfixtestclose
in short
Can AI agents run autonomously in ConvOps?
Yes, once they have earned it. The same governed workflow runs attended in your client or unattended on a schedule, and its approval gates hold either way.
ConvOps is the operations layer for AI agents: an MCP server that holds your team's process as workflows, with approval gates, a shared memory and an audit trail. It runs no AI models.
key facts · october 2026
- Runs are attended by default: you work in your AI client and approve at the gates.
- Schedules use RRULE recurrence rules (RFC 5545), not cron. Each fire can create a new task carrying the whole workflow, or resume an existing task at its current step.
- Work pools are saved queries over your tasks. A run pulls its next task from a pool, or gets nothing to do; nothing is pushed.
- Every unattended run is recorded with tokens, cost, turns, duration and an error class when it fails.
- Neomanex runs 3 saved pools plus the Now, Next and Rotting horizon pools; 551 items were committed to Now in October 2026.
best for
- Recurring work such as nightly triage, weekly reports or dependency updates.
- Teams that want to start with approvals on every step and remove them as trust grows.
not for
- Letting an agent loop with no process and no gates. ConvOps adds structure, it does not remove it.
- Running steps of one workflow in parallel. Parallel work is child tasks with the same order.
updated
the problem
Autonomy is easy. Trusting it is hard.
Starting an agent on a timer takes a minute. Knowing it did the right thing, and what it cost, is the real work.
“What did it do at 3am?”
A script on a timer leaves a log line on some box. Nobody can tell what ran, or why.
“What is this costing us?”
Runs nobody watches, with no cost per run, are a bill you discover at the end of the month.
try it
Slide from every OK to on its own.
One workflow, four levels of trust. Watch which steps still wait for a person, and what starts the run.
workflow · bug sweep
you, in your chat
pick workapprovalrecallapprovalfixapprovaltestapprovalcloseapproval
You watch every step and give each one an OK. Your AI tool is connected, and that is the whole setup.
- starts it
- you ask, in your chat
- needs a person
- 5 of 5 steps
- runs on
- your AI tool, with you
drag, or use the arrow keys
watch it work
From Monday to every night.
The same bug sweep, run with you on Monday and on its own at 02:00 a few weeks later.
01you, in Claude Code
Monday. You ask in your chat.
In Claude Code you type "run the bug sweep". A task starts with its workflow attached. Nothing to install: your AI tool asks ConvOps for each step.
Run the bug sweep.
task created · Bug sweep · workflow attached
Step 1 of 5, pick work. I would take
Payment webhook returns 500 first. OK?attended · nothing installed
pick workrecallfixtestclose
02you approve
Every step waits for your OK.
You read what it picked, what it recalled and what it changed, and approve each step. Slow on purpose. This is how trust is earned.
waiting for you · step 1 of 5
pick work: approve and continue?
Send backApprove
pick work
recall
fix
test
close
approvals this run · 0 of 5
03you, editing the workflow
A few clean weeks later.
The routine steps never needed a correction. You keep one approval, before bugs are closed, and let the rest run straight through.
- pick workapproval
- recallapproval
- fixapproval
- testapproval
- closeapproval kept
one approval left, before bugs are closed
04you, once
You add a schedule.
Every night at 02:00. Each time it fires, a fresh task starts with the same workflow, the same rules and the same approval.
Run the bug sweep every night at 2.
schedule created · every night · 02:00
scheduleEvery night at 02:00each fire · new task · same workflow
- tonight · 02:00
- tue · 02:00
- wed · 02:00
- thu · 02:00
05the schedule
02:00. Nobody is at the keyboard.
The schedule fires. The run asks a pool for the next bug worth fixing and a runner you chose does the work.
02:00schedule fired · nobody at the keyboard
pool · bugs stale 3+ daysPayment webhook returns 500Export drops the last rowLogin link expires too early
runner · gpu-boxasking for work
pick workfrom a pool
recall
fix
test
closeapproval
06you, with coffee
Morning. One OK, a full record.
The close waited for you. The run left its log, its retries and its cost, on the task where you can read them.
Bug sweep · nightly
- pick workran on its own
- recallran on its own
- fixran on its own
- testran on its own
- closewaiting for you
execution logkept
retries0
cost$0.41
example data
Run the bug sweep.
task created · Bug sweep · workflow attached
Step 1 of 5, pick work. I would take
Payment webhook returns 500 first. OK?attended · nothing installed
pick workrecallfixtestclose
what it picks up
The run pulls its next task.
A pool is a saved question about your work, answered live. Each run takes one task, or learns there is nothing to do.
pool · rotting bugs
Bugs nobody touched for 3+ days
- Payment webhook returns 5006d
- Export drops the last row5d
- Login link expires too early4d
- Search ignores accents3d
gpu-boxyour runner
pulls the next task
asking the pool
asking the poolisolated-sonnetisolated run
pulls the next task
asking the pool
asking the pool- waiting for the first run to finish
every run keeps its session, log, retries and cost
the parts
What it takes to let go.
Attended is the default
Your AI tool asks for the step, does it, and moves on. No backend, no runner, nothing to deploy.
connect and go
Schedules
Calendar rules, not cron strings. Start a fresh task each time, or pick the same task back up where it stopped.
two modes
Work pools
A saved question about your work, answered live. The run gets one task back, or nothing to do.
pulled, never pushed
Executors
Named profiles for where runs happen: your machines, ConvOps cloud, your own OpenCode server or your own runner.
swap without touching tasks
the difference
A timer and a prompt, or a governed run.
# every night, whatever the state
0 2 * * * agent --prompt "$(cat sweep.md)"sweep.mda long prompt nobody reviews
- Fires whether or not there is work
- Selection logic is a query you maintain in code
- Retry and dedupe logic is yours to write
- The record is a log line on a box somewhere
- Approval means a human watches the clock
Schedules: two modes
RRULE (RFC 5545), not cron. Spawn creates a new child task each fire, carrying the whole workflow. Resume-attach picks the same task back up at its current step.
payload
{
"rrule": "FREQ=WEEKLY;BYDAY=MO;BYHOUR=9",
"mode": "spawn",
"creates": "task -> workflow: bug-sweep"
}Pools: one task or nothing
A pool is a typed, validated filter over tasks, resolved live on every call. pools_next returns exactly one task or an empty object, so a workflow can branch on emptiness.
payload
{
"slug": "rotting-bugs",
"filter": {
"op": "AND",
"nodes": [
{ "field": "type", "eq": "bug" },
{ "field": "stale_days", "gte": 3 }
]
}
}Executors: where runs happen
Named execution profiles. ConvOps dispatches to an isolated run on Kubernetes or your OpenCode server, or hands the envelope and a lease to your own runner. Precedence: step, then task, then workspace default.
payload
{
"executors": [
{ "slug": "local", "is_system": true,
"description": "claude code on your machine" },
{ "slug": "opencode", "is_system": true },
{ "slug": "isolated-sonnet", "backend": "isolated",
"description": "one pod per run, your kubernetes" },
{ "slug": "gpu-box", "runner": "custom",
"description": "your infra" }
],
"precedence": "step > task > org default"
}Dispatch you can rely on
The dispatch event is written in the same transaction as the task (outbox), redelivered idempotently, and orphaned runs are reaped. Each run records session id, execution log, retry count, status and cost in USD.
questions
Autonomous agent questions, answered.
Do I need to deploy anything to start?
No. Attended execution is the default: your AI client, connected over MCP, asks for the step, does the work, and advances. A backend is only involved when a run must happen with nobody at the keyboard.
What actually starts an unattended run?
A schedule. Schedules are RRULE, the calendar standard, not cron strings, and they run in two modes: spawn a fresh task each fire carrying the whole process, or resume the same task mid-workflow at its current step.
How does the agent decide what to work on?
It asks a pool: a saved, typed query over tasks that the engine resolves live on every call. pools_next hands back exactly one task or nothing, and empty is an answer the workflow can branch on. Work is pulled by capacity, never pushed onto a queue.
Where does the work actually execute?
Wherever you point it: the local clients on your machines, a custom runner on your infra that receives an envelope and a lease, your own OpenCode server with your models, or ConvOps cloud. Execution is per-org configuration; switching backends touches zero task definitions.
What happens when a backend is down?
The dispatch event is written in the same transaction as the task, so it cannot be lost. Delivery retries idempotently, unreachable backends degrade gracefully, and orphaned runs are reaped rather than leaking.
What does a run cost me?
Each executed task records its session, execution log, retry count, and cost in dollars, queryable from your client. Autonomy without a cost column is a bill you discover later.