The process, compiled.
Describe how the work should go, from the AI client you already use. ConvOps compiles it into structure the engine actually evaluates: steps that arrive one at a time, gates that refuse, decisions that detour into sub-workflows, groups that run in parallel.
A workflow engine for AI agents is the piece that makes the same work come out the same way twice. Without one, every process lives in a prompt: pages of instructions handed over all at once, drifting silently as people copy and edit their own versions, with checkpoints that are only wording. ConvOps stores the process as structure instead. A workflow is a sequence of typed steps with instructions, conditions, and gates, held in the database, owned by your workspace, versioned by editing in one place.
The engine holds the cursor. Your AI client, connected over MCP, asks for the current step, does the work, and asks to advance. The engine evaluates the gate on that step against real state: has a human approved, are the children finished, was context recorded. If the answer is no, the cursor does not move and the agent is told exactly what is unmet. This is the difference between a process the model is asked to follow and a process the model is unable to skip.
There is no visual canvas and no pipeline DSL to learn. You describe the process in plain language from the client you already use, the engine compiles it into steps, and from then on every task that matches the routing runs it. The sections below are the mechanics, each shown as the real payload the engine speaks.
Work finds its workflow.
Define the process once. From then on every new task is matched to the workflow that owns it, by type, vertical, tags, project, or plain language. Nobody wires anything per task.
{
"applies_to": [{
"type": "bug",
"vertical": "development",
"default": true
}]
}A step is not a prompt.
The workflow hands over one instruction at the moment the work reaches it. No forty-page brief, no system prompt that quietly goes stale. Edit a step once and every future run inherits it.
{
"id": "failing-test",
"name": "Failing Test",
"status": "in_progress",
"instructions": "Write the test that
reproduces the crash. Red first.
Notify me when it goes green."
}Gates are evaluated, not suggested.
A gate lives in the workflow, not in wording a model can talk its way around. The engine checks it on every advance; one that is not met returns its unmet conditions and the cursor does not move.
- requires_approval: a human has to say go
- wait_for_children, sequential_children, task_status: structural conditions on real state
- require_context: the step will not close without a recorded why
{
"current_step": "approve",
"unmet_conditions": [
"Requires explicit user approval"
]
}Branches are detours, and they come back.
A decision step reads real task fields and picks a condition. A branch can invoke an entire sub-workflow, run it to the end with its own steps and gates, and merge back. Loops are the return trip pointing backward: fix cycles that repeat until the work passes.
{
"decision": true,
"conditions": [
{ "id": "simple",
"when": { "task_field": "complexity",
"equals": "S" } },
{ "id": "unclear",
"invoke": "deep-research" },
{ "id": "go", "when": "default" }
]
}Three agents. Same instant.
A parallel group runs steps concurrently, each lane with its own agent, on its own runner if you want. The group merges before the run moves on.
{
"parallel": [
{ "id": "fix", "agent": "implementer" },
{ "id": "tests", "agent": "test-writer",
"executor": "your-runner" },
{ "id": "docs", "agent": "docs-writer" }
]
}Authored in conversation, validated before it runs.
Templates live in the database, composed from steps, reusable fragments, and org-wide globals. Surgical edits go through a full dry-run validation, and runs already in flight survive template changes.
- Fragments: reusable sub-flows embedded across templates
- Globals: org-wide hooks injected into every applicable template
- Raw vs resolved views: see the stored definition or the fully expanded run
The prompt dump vs the workflow
| a process in a prompt | a process in the engine |
|---|---|
| The entire process arrives at once, up front | One step arrives at the moment the work reaches it |
| Instructions go stale silently, per copy | Edit the step once; every future run inherits it |
| The model juggles every constraint at all times | The model sees only what is next |
| Checkpoints are wording a model can talk past | Gates are evaluated by the engine and refuse |
| The process lives in whoever wrote the prompt | The process lives in the template, with an audit trail |
questions
Is this a prompt library?
No. A prompt hands the model the whole process at once and hopes. Here the engine holds the cursor: steps are delivered one at a time as the work reaches them, gates are evaluated server-side on every advance, and a refused gate returns its unmet conditions instead of moving.
Can a decision branch the flow?
A decision step evaluates its conditions against real task fields and records what matched. A branch is a detour: the condition invokes a sub-workflow, which runs to completion with its own steps and gates and then returns. The trunk itself stays linear by design, so every run remains one auditable line.
How do loops work?
On the return from an invoked sub-workflow, resume_at can point backward. That is the fix-loop primitive: review finds problems, the run re-enters the fix step, and the cycle repeats until the work passes the gate.
Can steps run in parallel?
Yes. The engine runs parallel groups concurrently, and each lane can carry its own agent and target its own executor. The group merges before the run continues.
Where do workflows live?
In the database, scoped to your workspace: steps, reusable fragments, and org-wide globals. You install starting points from the template catalog and edit them conversationally over MCP from your own client.
What happens to runs already in flight when I edit a template?
They survive. Edits are surgical and validated with a full dry run before they land, and live instances continue against the updated definition.
How does a new task get its workflow?
Routing. Templates declare what they apply to, by task type, vertical, tags, or project, and matching work attaches its workflow automatically at creation. Nobody wires anything per task.