AI workers are easy to misunderstand.
Give a model a ticket, a repository, and a terminal, and it can produce a remarkable amount of visible activity: commands run, files change, tests pass, pull requests appear. That activity can look like progress. Sometimes it is. But it is not, by itself, a reliable definition of delivery.
Sextant began as an attempt to take that distinction seriously. The goal was not to create an autonomous factory that turns every request into code. It was to build a control plane for AI-assisted work: one that can break a desired outcome into bounded tasks, route work deliberately, preserve evidence, and distinguish a worker finishing from a result actually being ready to trust.
The project has been most valuable where it has failed. Those failures have made the operating model more concrete.
Why it is called Sextant
Sextant is the orchestrator around the workers. It measures and estimates work, breaks it into bounded tasks, schedules and routes those tasks deliberately, and optimizes how work moves through the system. It also retains the evidence needed to judge the result. It is not the name for the workers themselves.
The name comes from the navigational instrument. A sextant does not steer a ship or choose its destination. It helps a navigator establish position by taking a measurement against known reference points. That is the role I want this system to play in AI-assisted delivery: measure the work, estimate its shape and effort, coordinate its movement, and make the state of work legible. It should show what was requested, what a worker actually did, what evidence exists, and what still requires a decision or verification.
The metaphor is intentionally modest. Sextant is meant to provide orientation and discipline around automation, not to pretend that an automated system can replace judgment.
The original idea: workers need a system around them
The attractive story about agents is simple: describe the goal, dispatch several workers, and collect the result. The harder reality is that software delivery is full of dependencies, hidden assumptions, ownership boundaries, and quality gates.
A useful worker therefore needs more than a prompt. It needs a clear unit of work, an explicit definition of done, the right repository and branch context, limited authority, and a way for another system—or another person—to inspect what happened.
That is the role Sextant is meant to play. It treats work as a sequence of progressively smaller, reviewable units: an outcome can be decomposed into stories, then atomic tasks. Each task should have a concrete scope, acceptance criteria, and a record of the evidence expected at the end.
The point is not bureaucratic ceremony. It is to make it possible to answer a basic question honestly: what do we know happened, and what still needs to be checked?
The first hard lesson: finished is not successful
One early mistake was allowing the end of a worker run to carry too much meaning. A process can exit. A worker can report completion. A test command can return green. None of those facts alone establishes that the requested outcome was achieved.
This is especially important with AI-generated work because a plausible-looking implementation can be incomplete in ways that are not obvious from the last message. It may satisfy a narrow test while missing a requirement. It may change the right file in the wrong checkout. It may make a local improvement without proving that the intended workflow still works end to end.
The correction is an explicit state model. A worker can finish its assigned execution and enter a reviewable state. Verification is a separate step. Only evidence that matches the intended task, revision, and acceptance criteria should allow work to be called successful.
That may sound obvious, but it changes behavior. It prevents a dashboard from treating a completed run as a completed product decision.
What failed in practice
The system has encountered more ordinary failures than dramatic ones, which is exactly why they matter.
Some tasks were not sized well enough. A worker cannot recover clarity from a request that bundles architecture, implementation, tests, deployment, and business judgment into one opaque instruction. The result is often either shallow work or an unhelpful attempt to solve the wrong problem.
Queue and execution reliability also matter. A task marked ready is not useful if the pickup loop does not reliably turn that state into a visible, attributable run. A model endpoint being healthy does not prove that the worker has the repository access, credentials, or tool path required for the task.
Review evidence created another class of failure. A reviewer can produce malformed output, evaluate the wrong revision, or hit a tool limit. A positive-sounding summary is not enough if the underlying checks and findings cannot be inspected. Similarly, a passing local test suite is useful evidence, but it is not a substitute for validating the behavior that the user actually needs.
Finally, shared workspaces create their own risk. When multiple workers touch a repository, an apparently correct change can be contaminated by unrelated local edits or collide with another worker’s assumptions. Isolation is not a convenience feature; it is part of the reliability model.
The controls that are improving it
The improvements have been less about making workers seem more autonomous and more about making their boundaries clearer.
Smaller, explicit tasks. Work is decomposed until a worker has a bounded objective, known inputs, and acceptance criteria that can be checked. If a task remains too broad, it should be sized or clarified before implementation—not disguised as a single “do everything” prompt.
Isolated execution. Per-job checkouts reduce the chance that one worker silently relies on, overwrites, or is confused by another worker’s local changes. The resulting evidence can be tied to a specific task and revision.
Decision receipts and evidence. A worker should leave more than prose. The system needs a record of the selected task, the relevant revision, commands or checks performed, outputs, and the relationship between those outputs and the acceptance criteria.
Independent verification. Verification is deliberately distinct from execution. It checks the actual artifact and intended behavior rather than accepting a worker’s self-report. This is where tests, review, and human judgment each have different roles.
Bounded recovery. Some failures are transient or mechanical: malformed review evidence, a constrained tool session, an interrupted run. A limited retry can be sensible when it is targeted and preserves the original evidence. Unlimited retries are not resilience; they are a way to hide a system that is not learning from its failures.
Honest states. “Queued,” “running,” “worker finished,” “needs verification,” “verified,” and “blocked” should mean different things. Clear states make it easier to see whether the next action is to wait, repair infrastructure, clarify scope, review an artifact, or involve a human decision-maker.
The human role did not disappear
The more I work with AI workers, the less interested I am in the fantasy of removing people from the loop. The valuable human work moves upstream and downstream.
Upstream, someone has to decide what is worth doing, what the constraints are, and what success means. Downstream, someone must decide whether the evidence is sufficient, whether the result fits the larger system, and whether to accept the tradeoffs. Workers can accelerate execution and surface information, but they do not eliminate accountability.
That is why I think the right comparison is not “AI worker versus engineer.” It is closer to a new form of instrumented delivery system. The workers are components. The task boundaries, evidence model, verification gates, and human decisions are what make the components safe to use.
What I am watching next
The interesting questions now are operational. Can the system size work accurately enough to avoid both over-fragmenting it and handing a worker an impossible bundle? Can it preserve provenance as tasks move between planning, execution, review, and release? Can it report uncertainty clearly enough that a human knows where attention is needed?
I do not think reliable AI-assisted delivery will come from a single breakthrough prompt. It will come from disciplined systems that make the limits of each worker visible, retain the evidence of what occurred, and refuse to confuse motion with progress.
That is the lesson Sextant keeps teaching me: the purpose of a worker is not to look busy. It is to make a trustworthy contribution to a result that can be verified.
If you are building with agents, I would be interested in the controls that have made your own workflow more reliable—and in the failure modes you discovered only after the first impressive demo.
Leave a Reply