Approach · Agent orchestration
Work handed between AI systems, without a person carrying it.
When several AI systems share a job, something has to assign the work, track whether it finished and check the result. That is orchestration. We build it so the difference between generated output, deployed software and proven behavior stays visible.
How we approach it
- 01
Keep authority where a person can read it.
Tasks, decisions and results live in a record people can inspect, such as a code repository. A chat thread is for watching the work, not for deciding it.
- 02
Never let the model choose the target.
Which repository, site or environment an agent writes to is resolved from a trusted identity, not picked by the model.
- 03
Treat claimed and verified as different states.
Work moves from submitted to claimed, working, checkpointed and verified. Most failures hide between claimed and verified.
- 04
Route by completed work.
Which model takes which kind of task is set from measured completions and cost, per class of work.
Questions it answers
- Which agent does which part of the job, and who checks the handoff?
- How do we know a task finished, not just started?
- What stops an agent from acting on the wrong system?
In practice
Where this shows up in our own work, with each item's current status.
- A control plane that hands work between two AI systems; first version paused September 17Experiment (Running experiment)
- Website changes that count as done only when they are seen on the live sitePrototype
- One task routed to two models, compared by the cost of a finished resultExperiment (Running experiment)
Tell us what you're trying to accomplish.
We'll talk through the problem, whether Lehvel is a good fit, and a sensible next step. The scope comes from the problem, not a package.