Home Use Cases Work Insights About Contact
Back to Our Work

How a Growth-Stage Technology Company Built Request Handling with Human Approval Before Customer Changes Go Live

Operations2
Open the walkthrough

Five-Step AI Workflow with Human Oversight

Each step shows the workspace, what the AI completed, and what still needs human review.

Steps 3 and 5 need a person. Step 3 is waiting for approval right now. Click it to open the full walkthrough.

Estimates are directional and based on stated assumptions. All names, organizations, and identifying details have been anonymized in accordance with our confidentiality agreements.

The Transformation

How a Growth-Stage Technology Company Built Request Handling with Human Approval Before Customer Changes Go Live

Before
A person used to re-key every request into a spreadsheet and chase the gaps by hand.
A person used to open three systems side by side for every request.
A person used to make every change in every system by hand, one screen at a time.
After
everything that arrived, matched to its account, the gaps asked back
the whole record pulled, every field with its source, conflicts named
three actions, drafted, evidenced, waiting on your say
every cleared change applied, read back, and stopped where the record moved
where the day's requests ended, and what to run differently
Executive Summary

Every operations request, from the moment it arrives to the moment its change is live and read back in every system it touches. The agents take each request in, pull what billing, the CRM and the product database already say about it, draft the action, apply the ones policy already answers, and hand a person only the changes to what a customer pays or gets. Five stations, run as a loop: the rules a person accepts at station 5 are the rules station 1 holds against and station 3 answers tomorrow.

What Was Broken

A person used to re-key every request into a spreadsheet and chase the gaps by hand
A person used to open three systems side by side for every request
The real cost
A person used to make every change in every system by hand, one screen at a time.

What We Built

Five stations and 11 subagents. Each subagent carries its own tasks and its own refusal.

A4
Request Sweep
Collect every request from the form, the shared inbox and the two system queues
A3
Completeness Check
Check each request carries every field its kind needs before it moves
A4
Record Pull
Pull the account's records from billing, the CRM and the product database
A3
Consistency Check
Check every field that lives in more than one system against the others
A1
Action Writer
Draft the action for each request from its assembled record
A3
Policy Match
Match each drafted action against what its kind of request has always got
A3
Change Record
Record what was cleared, by whom, and what evidence was on screen
A4
Write Runner
Queue each cleared action as one job per system it touches
A3
Write Verify
Read every record back after its write and compare it with the draft
A4
Day Close
Check every request that arrived today against where it ended
A2
Rule Proposal
Propose the intake or policy rule that would have stopped each repeated mistake

How It Runs

1

Request Intake

Nobody is asked anything here

Agents collect every request off the form, the shared inbox and the system queues, match each one to its account, merge the duplicates, and hold anything missing the fields its kind needs. Nothing waits on a person here. A held request is never worked from a guess; the missing piece is named and asked back.

2

Record Assembly

Nobody is asked anything here

Agents pull every field the request touches from billing, the CRM and the product database, trace any disagreement to the write that caused it, and stop a request whose systems disagree on money. Nothing waits on a person here. A money conflict is never settled by picking a side; it goes forward with both lines named.

3

Action Drafting

A person answers here

Agents draft the action for every request from its assembled record, pass the ones policy already answers straight to write-back, and hold every change to a price, a plan or an access right for a person. This is where a person works. Everything else exists so that three actions, not a hundred and twenty, reach this screen.

4

System Write-Back

Nobody is asked anything here

Agents queue each cleared action as one job per system, apply the writes in the order the systems need, read every record back, and stop any job whose target moved since the draft. Nothing waits on a person here. A record that changed under a job is never written over; the job stops and the draft is redone from the new record.

5

Day Close

A person answers here

Agents check every request against where it ended, count what settled without a person, propose the intake and policy rules that would have stopped today's repeated mistakes, and show what each rule would hold wrongly. A person accepts or rejects each rule. What policy answers on its own, and what gets held at the door, is not something an agent changes quietly.

Where a Person Decides

Step 3, Action Drafting. Clear the Contoso upgrade, the draft and its rate card line are ready. Pick a side on Woodgrove, both system lines are on screen. money and access move on your say.
Step 5, Day Close. Accept or reject the two proposed rules. Say whether the renewal date should become a field the form asks for. the rules are yours to accept.

Operating Model

This changes how work flows through the team.

Role
Responsibility
Action Drafting owner
Clear the Contoso upgrade, the draft and its rate card line are ready. Pick a side on Woodgrove, both system lines are on screen. money and access move on your say.
Day Close owner
Accept or reject the two proposed rules. Say whether the renewal date should become a field the form asks for. the rules are yours to accept.
Request Intake, when it goes wrong
Look here only if a customer says their request vanished.
Record Assembly, when it goes wrong
Look here only if a record on the next screen surprises you.
System Write-Back, when it goes wrong
Look here only if a customer says a change never showed up.

What Transfers, What Must Be True

What transfers
A person is in the loop wherever a change to what a customer pays or gets moves, and wherever the rules the agents run on change. Two stations refuse to proceed on their own, station 3 Action Drafting and station 5 Day Close, and those are the two a person carries. Everywhere else the agents take in, assemble, apply and read back, and reach you only when the change is yours to clear.
Action Drafting stops for a person, and money and access move on your say.
Day Close stops for a person, and the rules are yours to accept.
Every subagent says what it will not do. 11 of them do.
What must be true in your environment
The agent can read the systems your records already live in. This one reads 17.
Somebody owns Action Drafting and has time for it.
Somebody owns Day Close and has time for it.

Failure Modes

What breaks this pattern:

✗ A Guessed Field Becomes the Record

An incomplete request comes in and the agent fills the blank itself. The wrong account or the wrong plan then moves through every step that follows.

✗ Two Prices, One Picked Silently

Billing shows one price, the CRM shows another, and the agent picks one. The customer pays the wrong amount, and nobody knows the two systems ever disagreed.

✗ The Customer Finds the Change First

The agent changes what a customer pays without a person seeing the evidence first. The first person to catch the mistake is the customer, on their invoice.

✗ Writing Over a Moved Record

The record changed after the draft was made, and the job writes over it anyway. Someone else's fix is erased, and nothing in the system shows it happened.

Directional Outcomes

What the agent counts, and the station that counts it.

These counts are the tallies from one monitored run of the agents. They are not monthly or annual totals.

Requests taken in
Counted at Request Intake
11,300
Worked from a guessed field
Counted at Request Intake
0
Held and asked back
Counted at Request Intake
74
Fields assembled
Counted at Record Assembly
214,000
Conflicts settled by guessing
Counted at Record Assembly
0
Conflicts sent forward named
Counted at Record Assembly
61
Writes applied and read back
Counted at System Write-Back
96,400
Wrong values left standing
Counted at System Write-Back
0
Jobs stopped and redrafted
Counted at System Write-Back
210
Our measurement policy: We do not publish precise ROI without baseline methodology. Every figure above carries its basis.

What Runs Where

Every step names the subagent that does the work, the record it writes, the thing that raises a question for a person, and what it is allowed to touch. This is drawn from the source, not from a diagram somebody kept in sync by hand.

1Request Intake
subagentrequest-intake
writesrequests/intake/<req-id>.json
raiseshold-incomplete-request
may touchrequests/intake/**, requests/held/**, the form and the queues read-only
2Record Assembly
subagentrecord-assembly
writesrequests/assembled/<req-id>.json
raisessystems-disagree-on-money
may touchrequests/assembled/**, billing, the CRM and the product database read-only
3Action Drafting
GATE
subagentdraft-action
writesrequests/drafts/<req-id>.md
raisesawait-your-clear
may touchrequests/drafts/**, everything else read-only
4System Write-Back
subagentwrite-back
writesrequests/applied/<req-id>.json
raisesrecord-changed-under-the-job
may touchrequests/applied/**, the three systems through their connectors only
5Day Close
GATE
subagentclose-and-learn
writesrules/proposed/<rule-id>.json, reports/requests-<date>.json
raisesaccept-rule-change
may touchrules/proposed/**, reports/**, the history read-only

Stack

Every system this agent reads or writes.

System
Read at
Stations
billing
Record Assembly
2 of 5
the CRM
Record Assembly
1 of 5
the CRM and the product database through their connectors
System Write-Back
1 of 5
the account directory
Request Intake
1 of 5
the assembled records
Action Drafting
1 of 5
the background job queue
System Write-Back
1 of 5
the day's request trail
Day Close
1 of 5
the drafts queue
Action Drafting
1 of 5
the held-request log
Day Close
1 of 5
the policy library
Action Drafting
2 of 5
the product database
Record Assembly
1 of 5
the rate card
Action Drafting
1 of 5
the reporting dashboard
Day Close
1 of 5
the request form
Request Intake
1 of 5
the request history
Record Assembly
1 of 5
the shared operations inbox
Request Intake
1 of 5
the two system queues
Request Intake
1 of 5
Next Step

Want to see if this pattern fits your technology platform?

No build commitment·Real samples, not a demo·Estimate in writing