Nothing here is a technology problem first. It is an authorisation problem, a records-retention problem and a human-in-the-loop problem, and a deployment that treats those as paperwork does not reach production. The controls are the design input, not the obstacle.
The authorisation boundary decides the architecture. Whether a system can operate inside an existing boundary or would require a new one is the difference between a deployment measured in weeks and one measured in quarters, and it is a question to answer in the first conversation rather than the third month. Frequently the right design is a more constrained one that fits an existing boundary, and saying so early is worth more than a better architecture nobody can authorise.
Records retention is not a storage question. If an agent generates a draft response, that draft may be a federal record, and where it lives, how long it is kept, and whether it is retrievable are governed by a schedule that predates every system in the estate. Designing that in is straightforward; discovering it after go-live is a remediation project.
Human-in-the-loop is a design requirement rather than a reassurance. The specific decisions that must remain with a person, a determination, a release, a denial, anything with a right of appeal attached, get identified before the build, and the interface is designed so the person is genuinely deciding rather than approving a recommendation they have no practical ability to challenge. A confirm button on a decision nobody can inspect is automation wearing a human’s clothes.
And procurement shapes the sequencing more than the technology does. The work has to fit a vehicle, the vehicle has a period of performance, and the modernisation everybody wants may not survive a continuing resolution. Scoping in increments that each deliver something usable is not agile theatre here; it is how the work survives the funding calendar.