---
title: "How to build an agent factory for company IT, stage by stage"
url: "https://sovereos.com/blog/how-to-build-an-agent-factory-for-company-it"
description: "An agent factory is the old work cycle closed into a loop. Eight stages, shown on IT requests in a mid-sized company: why each one matters and where to start."
---

# How to build an agent factory for company IT, stage by stage

November 6, 2026·9 min read·SovereOS

A young IT specialist points at a green loop of eight empty boxes joined by arrows on a whiteboard while a colleague holding an open laptop looks on.

An agent factory is not a faster version of the old work cycle. It is the same cycle closed into a loop, in which every stage leaves a record and the person moves from doing the work to three decision points: approving the plan, confirming the verification and agreeing to the release. Agents prepare everything in between.

Copy the old process one to one, with an agent where a person used to be, and you get more changes, not better IT.

We show the loop on the work we know best: requests and changes in the IT of a mid-sized company. The same shape works in accounts and purchasing, as we argued in [agent factories will reach accounts and purchasing](https://sovereos.com/blog/agent-factories-will-reach-the-back-office).

## The old cycle in one paragraph

The classic software development lifecycle (SDLC) is a relay of people. An analyst gathers requirements, an architect designs, a developer writes, another reviews, a tester tests, an administrator deploys. IT support in a mid-sized company is the same relay, only shorter: an employee emails the IT person, the IT person rings a supplier, the supplier changes something, someone checks whether it works. Every pair has a handover. The knowledge of why something was set up one way and not another lives in people’s heads.

“Who remembers why the warehouse printer has a fixed address?” The previous IT person did. They left two years ago.

That model worked because a specialist’s time was the expensive resource, and handovers were the price of people working together. In a factory, doing the work becomes cheap and a person’s attention becomes expensive. That turns the logic of the whole cycle around.

## The loop in eight stages

1.  **Intake**: a request, a question or an alert lands in one queue.
2.  **Triage**: an agent sorts it and tries to reproduce the problem.
3.  **Plan**: an agent writes up the change; a person approves.
4.  **Execution**: an agent prepares the change.
5.  **Review**: a second agent checks the change against the plan.
6.  **Verification**: an agent walks the user’s path and records evidence; a person confirms.
7.  **Release**: a person accepts and the change goes in.
8.  **Monitoring**: an agent watches the effects and opens new requests, which return to stage 1.

Above the loop sits a coordinator. It is an agent that receives the trigger, works out which stage the work is at, and starts the right agent with the right model and context. A cheaper model for sorting. A stronger one for the plan. For review, whichever scored best on your own test tasks.

### 1\. Intake: work arrives in one place

An email to the IT person, a chat message, a call to the office, an alert from the backup system. All of it lands in one queue.

**Why it matters:** a factory with six front doors does not know what is on its table. It cannot measure throughput or cost.

**What breaks without it:** half the work happens outside the loop, in personal inboxes, with no trail and no numbers.

### 2\. Triage: the cheapest saving in the loop

An agent reads the request, checks what it concerns and puts it in one of three bins. _Ready to do:_ a new starter needs access to the shared folder their own team already works in. _Unclear, needs a plan:_ “the VPN is down” from three people at once. _Needs a person:_ access to the finance folder for someone outside finance, because that is the data owner’s decision, not IT’s.

**Why it matters:** sorting and first diagnosis eat the hours of the most experienced person. Here they get requests already sorted, and small, clear jobs move on without them.

**What breaks without it:** the execution agent gets a vague task and efficiently solves the wrong problem.

### 3\. Plan: where the quality of the loop is decided

For unclear work an agent prepares two short documents. _A plan for the user:_ what the employee will see and do after the change. _A technical plan:_ which group, rule or setting changes, what else depends on it, and how to undo it. A person reads both, corrects them and approves them before anything changes.

**Why it matters:** this is the point with the most leverage. Fixing a sentence in the plan takes a minute. Undoing a firewall rule change that cut the warehouse off from its printers takes a morning. The person stops reviewing a finished change. They review the intent.

**What breaks without it:** review turns into archaeology. Someone tries to work out from the configuration what the agent meant to do, and finds it did something other than what the company wanted.

### 4\. Execution: the least interesting stage

An agent takes a request from triage or an approved plan and prepares the change: in configuration kept as files, in a test environment, or as a script ready to run.

**Why it matters:** less than it seems. If intake, triage and the plan work, execution is the most predictable part of the loop. Everyone wants to start here because this is where the results show. That is a mistake.

**What breaks if you only start here:** a fast agent changes things based on requests nobody sorted or planned. People spend their time rolling back instead of approving.

### 5\. Review: the stage that teaches itself

A second agent reviews every change before a person sees it. It has the plan in front of it, so it judges the change against the intent. It has access to the test environment, so it can check its own comment before leaving it.

Then there is an outer loop. Another agent collects the comments people leave on reviews and, every so often, proposes a change to the reviewer’s instructions. That proposal is an ordinary change for a person to approve.

**Why it matters:** the company’s habits (“permissions go to groups, never to individuals”, “no changes on Friday afternoon”) do not have to be written up front in a document nobody reads. They accumulate in the reviewer’s instructions with every comment.

**What breaks without it:** a person repeats the same five comments every week.

### 6\. Verification: the person confirms instead of investigating

An agent signs in as a test user and walks the path from start to finish: opens the folder, prints a page, connects from outside. It attaches screenshots to the change and compares the result with the plan. For backups this means a test restore, not a green tick, as we argued in [a backup you have never restored](https://sovereos.com/blog/a-backup-you-have-never-restored).

**Why it matters:** automated tests check what someone anticipated. Walking the path catches what nobody did. The person does not reproduce the change themselves. They look at the evidence and say yes or no.

**What breaks without it:** the last step before release depends, again, on whether somebody had time.

### 7\. Release: the decision stays with a person

A person accepts the change and releases it, ideally in an agreed maintenance window.

**Why it matters:** this is the moment risk moves from IT to the whole company. Someone has to sign for it. The agent prepares, checks and suggests. A person decides and answers for it.

### 8\. Monitoring: the loop closes

An agent watches the effects: sign-ins, backups, service availability. It spots unusual behaviour and opens a request itself, which goes back to stage one. One full run up to approval: the nightly backup did not complete, monitoring opens a request, triage finds the cause, execution prepares a fix, review and verification check it, and in the morning a person receives a ready change with evidence.

**Why it matters:** without this stage the factory is an assembly line. With it, it is a loop in which the environment reports what needs fixing.

## The second loop: a factory that improves the factory

Above the work loop runs a second, less visible one. An observer agent scores every run: what it cost, how many times a person had to correct something, whether the change came back later as a new request. On that basis it proposes changes to the factory itself: a different model at triage, a sharper instruction for the plan, a new skill for the reviewer.

To make that safe, the factory’s definition has to be kept like code: with version history, the ability to roll back a bad change, and a fixed set of test tasks to try the new version on. A change to the factory takes the same route as a change to the environment: proposal, review, a person’s approval. A factory that rewrites its own instructions will, within three months, be doing things nobody understands.

Where those files and that history should live is the subject of [who owns your agent factory](https://sovereos.com/blog/who-owns-your-agent-factory). In short: with you.

## The old cycle and the factory

Dimension

The old cycle

The agent factory

Shape

a relay: handovers between people

a loop: monitoring feeds new requests

Where the person looks

at the finished change, or at the fallout

at the plan before the change and the evidence after verification

Most expensive resource

a specialist’s time

a person’s attention at the decision points

Knowledge of the environment

in heads and in outdated documentation

in agent instructions and run history, versioned

Checking

“works for me” and a call from a user

a walked path with evidence, compared with the plan

Improvement

a review every so often

scoring every run and proposing changes to the factory

Work in progress

private, in somebody’s inbox

visible, in the factory’s queue

Who answers for the release

a person

still a person

The last row matters most. Requirements, approving the plan and the decision to release stay with people. Everything in between changes.

## Where automation does damage

**Tasks that only look simple.** “Update the switch firmware” sounds like agent work. Until the new version changes the default network settings in the warehouse. Start with tasks where a mistake is cheap and shows immediately: folder access within a team, a password reset with identity confirmed, obvious service failures.

**Skipping the plan because the agent is fast anyway.** Acting fast without an approved plan is the most expensive way to find out that everyone understood the task differently.

**An agent with administrator rights.** The execution agent gets exactly the permissions its stage needs, on its own account in the directory, not an admin account with a password in a file. Otherwise you cannot tell its actions from a person’s, as we described in [offboarding an employee](https://sovereos.com/blog/offboarding-an-employee-how-many-accounts-stay-open).

**Self-improvement without a brake.** A change to the factory without a person’s approval is drift, not progress.

**A factory instead of people.** Tell the IT person the factory is there to replace them and they will leave before it works, taking the knowledge the factory needs. Building the loop is a step up in responsibility, not a sentence.

## How to tell the factory is working

Vanity metric

Outcome metric

tickets closed

how many times a person touched one case from request to release (should fall)

tokens consumed

the cost of one closed case and its month-on-month trend

agents running

the share of cases that went through the loop with no corrections after approval

time to first response

time from request to a working change, how often changes go in, the share that had to be rolled back, time to restore service

The last row is the four classic DORA measures, carried over from software deployments to changes in the environment. First response, which many support contracts measure, says nothing about whether anything got fixed, as we set out in [what your IT support contract actually promises](https://sovereos.com/blog/what-your-it-support-contract-actually-promises). Scoring by a second model can be a supplement. If the number of cases that come back is rising, no model’s score will cover that up.

## The order to build it in

Every step gives you a working system. You can stop after any of them and still have something that helps.

1.  **One intake and triage.** All requests in one queue, an agent sorting them into three bins. The result: the IT person starts the day with a sorted list.
2.  **Plans.** For unclear cases an agent writes the user plan and the technical plan, and a person approves. The result: larger changes stop stalling, because it is clear what exactly should happen.
3.  **Review with a learning loop.** Every change gets a first review before a person sees it, and people’s comments feed the reviewer’s instructions.
4.  **Verification with evidence.** An agent walks the user’s path and compares the result with the plan. The result: the person confirms instead of checking.
5.  **Join it up and measure.** The coordinator links the stages, monitoring feeds intake, the observer scores the runs. Only now does the second loop work.

Underneath, the whole way through, sits the same groundwork: agent accounts in your own directory, configuration kept as files, run history in your own account and covered by backup. That is the shape in which we are designing how SovereOS runs environments. We have not launched yet, so this describes the approach, not a report from deployments.

## Where to start on Monday

Take the last twenty IT requests, from email, chat and notes of phone calls, and sort each one by hand, in a spreadsheet, into the three bins. If more than half land in “unclear”, the first agent in your factory should not be the one that changes configuration. It should be the one that writes plans.

That leaves a decision. You can give the IT person an agent that clicks faster and watch the queue of things to check and roll back grow. Or you can build a loop in which that person stops doing and checking everything alone, and starts approving the things that genuinely need their judgement.

-   agent factory
-   IT support
-   tickets
-   processes

## Keep reading

-   [Your agent factory runs at a vendor. Who owns what it learns?](https://sovereos.com/blog/who-owns-your-agent-factory)
-   [Agent factories will reach accounts and purchasing, not just developers](https://sovereos.com/blog/agent-factories-will-reach-the-back-office)