Automate the Process You've Learned to Trust
My manual orchestration process had become repetitive.
I would walk an agent through a specification, then planning, then task creation and sprint preparation. Once the work was ready, I would move into implementation with Skadi, Valdr’s sprint orchestrator.
I had spent time refining that process. The more dependable it became, the more annoying it was to keep driving the same sequence. I knew what should happen next. I had already worked out the instructions. I was still there to initiate the next stage and carry the process forward.
That is why I built Valdr Workflows: to turn the process I had learned to trust into a pipeline I could run, with human checkpoints where I still wanted to be involved.
The quality came from refining the agents
Most of the work went into my Valdr agents and capabilities: building up context, tightening instructions, and refining the process they followed to produce quality code.
Those are concrete engineering decisions. What context does an agent need before it changes code? What should a specification settle? How much detail belongs in a task? What evidence should a reviewer require?
An agent’s capabilities give those expectations a reusable home. As I refined them, I could carry more of the process into the next task without explaining it again from scratch.
That investment made automation worth pursuing. I had a sequence I wanted to repeat, supported by agents whose instructions I had put effort into improving.
The remaining repetition was in the orchestration: moving from one stage to the next, handing off the work, and keeping the sequence going.
Give the handoffs a place to live
The shape of my process was straightforward:
Skadi already helped coordinate sprint implementation. Workflows gives the surrounding sequence an explicit definition too: which steps depend on which results, what gets passed forward, and where execution must wait.
The distinction is useful when designing a pipeline. Agent instructions describe how to do the work. The workflow describes how that work moves between agents, tools, reviews, and people.
For example, a planning step produces something the next stage needs. A delivery step launches an executor and waits for its result. Review can send requested changes back through a bounded correction loop. A human gate pauses the run for a decision.
Those handoffs become part of the saved process. You can author them in the visual builder or in a workflow definition, then run the process with the inputs for a particular task.
The included idea-to-sprint workflow shows that composition at a larger scale: clarification and planning, human approval, sprint preparation, implementation and review, and approved pull-request publication. Smaller workflows handle the constituent work and remain separately inspectable inside the parent run.
Keep the units small enough to refine
Steps and workflows give me small units of work to reason about. A complicated pipeline can be broken into focused subworkflows, each with declared inputs, an expected result, and a clear responsibility.
That makes refinement more manageable. I can work on task preparation, launcher selection, or delivery and review as a smaller process. A subworkflow can be tested with known inputs and its results inspected independently, then tested again within the larger pipeline.
The Builder’s Test action runs a draft with supplied inputs and retains the run for inspection. Once a revision behaves as intended, the parent can select that version of the child workflow.
Small boundaries also make it easier to locate a problem. If launcher selection needs better instructions, there is a specific unit to refine. I can change its agent or capability, check the result, and bring that improvement back into the larger process.
Keep human gates while you learn
I currently keep human gates in the process while I work through it.
That gives me places to inspect the result before the pipeline continues. A specification or plan can be reviewed at the point where it will shape everything downstream. If it needs correction, I can address it there.
The important design choice is that supervision can change as the process matures. I can automate the handoffs while retaining the decisions I want to make myself.
For an engineer building a workflow, this separates three responsibilities:
- Agents and capabilities supply the context, instructions, and standards for doing the work.
- Workflow steps coordinate execution, pass results, and require the configured review evidence.
- Human gates identify the decisions that still require an operator.
That separation gives me somewhere specific to make an improvement. Weak instructions belong in the capability. An incorrect dependency belongs in the workflow. A decision that still needs my judgment belongs at a human gate.
A run gives me something to inspect
Reducing supervision depends on being able to understand what happened.
A workflow run records its steps, attempts, outputs, linked sessions, reviews, and human decisions. In the run inspector, I can follow the parent process into the child workflow or session responsible for a result.
Consider a reviewer requesting changes. The useful record includes the review findings, the correction attempt, and the later verdict. If a correction loop reaches its limit, the run blocks with its history intact. A failed step also needs enough context to explain where work stopped and which recovery action is available.
Recorded attempts and supported retries make those interruptions part of the process I can inspect. Earlier work remains visible as the run progresses or needs attention.
That evidence helps direct the next improvement. Repeated review findings can point to instructions that need tightening. Repeated intervention at a planning gate can point to missing context or unclear requirements. The pipeline gives those observations a stage and a result to investigate.
Use token visibility to focus the agents
Those small units also give me a practical way to optimize the process. Valdr exposes recorded token usage for workflow runs and steps, and lets me inspect the linked sessions behind that work.
The Session Comparison view groups sessions by agent, step, model, role, provider, or prompt. It separates average input, output, and cached tokens, helping me identify which part of a run deserves a closer look.
A step with one clear job gives me something concrete to tune:
- Focus the input. Supply the context and instructions relevant to that unit, reducing repeated material and unnecessary exploration.
- Constrain the direction. Tell the agent which decision or artifact it is responsible for, so it stays within that scope.
- Specify the output. When the next step only needs a defined result, ask the agent to omit conversational progress messages and return that result or an explicit error.
For example, a step that chooses a launcher preset can focus on the available choices, the selection criteria, and the required result. It has little reason to narrate the surrounding delivery process. Tightening that assignment can reduce both the input it consumes and the output it generates.
I can then rerun the smaller workflow with comparable inputs and inspect usage alongside the result and review evidence. The useful improvement is lower token usage while preserving the quality I need. That carries the same agent-and-capability refinement that built my confidence into a process I can measure.
Work toward the PR as the final gate
My intended next stage is to disable the intermediate human gates as I gain confidence and use the pull request as my gate at the end.
The specification, planning, task preparation, implementation, and agent reviews would still run. I would be changing where the process waits for me.
Valdr makes that an explicit authoring choice. A human gate can be disabled in a new workflow version. The disabled gate continues through its approved route without waiting for human input; an existing run keeps the gate configuration it started with. Disabling that checkpoint leaves separately configured review steps in place.
That is a direction I am working toward. For now, the intermediate gates let me keep refining the process before I ask it to run with less supervision.
Confidence has to come from the work I can inspect: the quality of the outputs, the reviews, and the corrections the process still needs. The appropriate place for a human decision will depend on the work and the consequences of getting it wrong.
Start with the sequence you already repeat
The starting point for me was a process I had already spent time improving.
If you have a similar sequence, pick one repeated handoff and make it explicit. Keep the human decisions you need. Inspect the results, improve the agents and capabilities behind them, and extend the workflow when that smaller process holds up.
You can begin with the included Deliver Task workflow, which takes a prepared task through implementation, independent review, bounded corrections, and verification. It is a smaller starting point than automating an entire sprint.
The more effort I put into making my agents reliable, the more I want to reuse that work. Workflows lets me carry it into a repeatable pipeline, with control over where I stay involved.
Valdr Workflows is part of Sovereign. Run your first workflow or explore the included idea-to-sprint pipeline.