Agentic ops infrastructure

The direction was clear — we are automating — with no tool selected, no owner named, and no scope defined. Ops teams were working manually on loan routing, compliance review, and email production, and leadership wanted AI involved.

Talking it through with the teams, the underlying need was less about AI than about the manual bottlenecks slowing everything down. They needed to do more without adding headcount. The tool was the vehicle, not the point.

I took a hybrid architecture to the COO: Zapier for the messy integrations with existing systems, and self-hosted n8n on the AWS infrastructure we already had for the high-volume operational work. Zapier per-task pricing breaks at operational scale, so self-hosting kept both the cost and the ownership internal as volume grew.

The other half of the decision was who it was for. This had to be infrastructure the Ops teams could build on themselves, not a service a central team ran for them, or I would only be moving the dependency from Engineering onto me.

Underwriter close rate on the applications the system routed. It was the most direct measure of whether the automation was freeing up the right capacity for the right work, and if it did not move, the infrastructure was not earning its place.

DevOps handled the infrastructure setup; I owned the operational use cases, the workflow architecture and the rollout. The first production build was loan application profiling and routing. Loan Ops were sorting and prioritising applications by hand, and that sorting was where the delay actually sat, so I sat with them to learn how they were making those calls, mapped the criteria into scoring logic, and automated the routing into the right queues.

From there I went looking for the next use cases rather than waiting to be asked, and the infrastructure grew to more than fifteen production automations. Then I wrote the documentation, put the SOPs in Confluence, and ran sessions with each Ops lead so their team could build and maintain their own.