How it works
How a governed AI agent
work-order system works
A governed agent system runs every piece of work through one work-order record. Each record names one specialised agent, moves through a fixed lifecycle, and ends with a written result that a reviewer reads before the work is closed. Agents may only write inside their own boundary, and tooling enforces that boundary at the moment of the action. For you, that means one place to see what is being done, agents that cannot wander outside the job you gave them, and nothing counted as finished until someone has checked it.
This is how SogaStudio runs its own work every day, and SOLODRIVE.PRO, a live software business, is developed and operated on SogaStudio's agent system the same way. Each section below says what the part is and what it does for the business that runs on it.
What you get from it
- One answer to "where does this stand?", for every job, without chasing anyone.
- Agents that can only touch what you gave them, so a mistake stays inside one job.
- A written record of what was done, how it was checked and what is waiting on you.
- Problems that announce themselves, instead of turning up later as a surprise.
1. One rail is the single source of truth
Every unit of work is a row in one work-order store, with an id, an owner lane, a status, a cost and a custody trail that records who held it and when.
- A request is not work until it is a row. Nothing you ask for depends on someone remembering a chat or an email.
- Status is data, not a folder. You can ask where any job stands and get an answer from the record.
- One store, not two. We do not keep a second tracker next to the rail, so you never have to work out which of two lists is right.
And because every row carries its cost, you can see what each kind of work costs to run.
2. Specialised lanes with enforced boundaries
Work is split into lanes: one agent with one kind of job, such as building one part of the product, operating infrastructure, research, marketing, design, or coordination.
- Each lane has a write boundary: the exact repositories and paths it may change. An agent drafting your marketing cannot change your code or your customer records.
- The boundary is backed by tooling, not only by instructions. Each lane has its own tool allowlist, and guards check writes and risky commands before they run. You are not relying on a model to remember the rules on a bad day.
- A path a lane can write is never also a path it can execute. An agent cannot give itself new powers, so the access you approved is the access it keeps.
- Ownership is not the same as write access: the lane accountable for a piece of work may hand the actual change to the lane that works in that code every day.
When something goes wrong, you know which agent touched it and what it was allowed to touch.
3. A fixed lifecycle
Every work order moves through the same states, from proposed and waiting for approval to queued, dispatched to an agent, delivered and finally closed, and a build that is on staging waiting for a production release has its own state. You can tell at a glance what is waiting on you, what is in progress and what is finished.
- An agent finishing its work marks it delivered, never done. Done means a reviewer read the result and accepted it, so "done" on your board always means someone checked it.
- Blocked is a first-class state. When an agent hits something it cannot fix, it says exactly what stopped it and stops. You hear about the problem instead of getting a workaround you did not ask for.
4. Every run leaves a durable result
Each run writes a result file for its work order: what changed, how the acceptance criteria were checked, where the deliverable lives, and what a human must decide. The result and every file it declares must be committed to version control.
A run that exits cleanly but commits nothing is recorded as blocked, not delivered, by a check that runs after the agent finishes and can override what the agent says about itself.
An agent cannot tell you a job is finished when nothing was saved. When a question comes up months later, the answer is in the record, not in someone's memory.
5. Messages carry signals, never work
Agents and monitors also raise alerts, flag problems and ask for decisions. Those travel as messages in the same store as the work orders.
- A message can never assign work. If a message needs action, a person turns it into a work order, so no work happens off the record.
- Every channel names who writes, who clears, and what happens if nobody clears it. A message meant for you cannot sit unread in a folder nobody checks.
- Alerts repeat until a person acknowledges them. A real problem does not go quiet just because nobody answered the first time.
- No channel is trusted until a test message has been seen travelling through it end to end. You do not find out a channel was dead from a missed alert.
6. Routing and coordination
A dispatcher picks up approved work orders on a schedule, starts the right agent with the right tools, and records cost and custody for the run. Dispatch is serialised so two agents never change the same shared tree at the same moment, which means your work is never half-overwritten by a second agent. A coordination role reads results, closes work, routes signals and mints follow-up orders.
Work you approve gets started without anyone having to remember to start it, and you have one place to look for the whole picture.
Why build it this way
Most failures we have seen in agent work are not bad answers. They are quiet ones: a task that never got queued, a check that went green because it could not see the problem, a message sent into a folder nobody reads. Each part above exists because one of those happened, so that you hear about a problem when it happens rather than from a customer later. What agents may and may not do on their own covers the other half: where a person has to say yes.