Madison AI Retired Microsoft Azure Blob Storage SFTP and Standardized Government Onboarding With Files.com

Madison AI builds private AI assistants for US city and county governments. Each one is constructed entirely from the government’s own records: board and council minutes, staff reports, zoning codes, master plans, internal policies. The company was born of an equity partnership with the county government it first served, and its roster of local governments grew steadily.

That model has one structural consequence. Before any assistant exists, the government has to hand over its records. Every engagement begins with a delivery: decades of minutes, planning case files, scanned documents, whole databases. For Madison AI, file intake is not back-office plumbing. It is the first thing every new client does. As more governments signed on, the intake side job scaled one-for-one with the thing the business most wanted to grow.

Client Records Came In Through a Storage Container and a Shared Password

Intake ran through the infrastructure that happened to be closest to hand: an Azure Blob Storage container exposed as an SFTP endpoint. When a new government signed, an engineer created a username and password and shared them with the client by hand. It worked, in the sense that files arrived. Everything around it was a tax. The endpoint needed key management, patching, and user administration, all of it done by hand at a small company serving a growing roster of government clients. And a government’s first hands-on contact with Madison AI was a bare storage login.

“We’re using SFTP via Azure Blob containers, and we want to get away from that. That’s super risky.”

The deliveries were not small. Government record libraries arrive as 50 GB database dumps, individual scanned files of 10 GB and more, and compressed directories running to hundreds of gigabytes. The people sending them are agency staff, and many are not file-transfer specialists. The intake had to absorb all of that, and it was doing so as an engineering side job.

The arrangement survived because it started small. With a handful of clients, sharing a password by hand was tolerable, and nobody at a young AI company was going to divert engineers to build an intake portal. Growth is what broke it. Every new client meant another credential to cut and another account to administer, and the work sat on the critical path of every engagement.

What replaced it had to take uploads from agency staff who might have nothing but a browser, and from municipal IT departments that already run SFTP clients. It had to keep every government’s records apart from every other’s, and carry individual files of 50 GB and deliveries far larger. It also had to run without an endpoint to patch or credentials hand-built against a storage account, while presenting a government client with something better than a raw login.

A Folder, a Credential, and a Dropoff for Every Government

Madison AI selected Files.com to provide that intake layer. The first government’s flow was stood up as its own workstream. New clients then came onto the same pattern.

Each government gets its own folder on the Files.com site, with a dropoff area inside it for inbound records. A client whose IT department runs an SFTP client connects with a Files.com SFTP account, scoped through folder-based permissions to that client’s folder and nothing else. Staff who have only a browser upload through the web interface or a Files.com Inbox, an upload page that requires no account and no installed software. Either way, the files land in that government’s dropoff area and enter the processing that turns a records library into that client’s knowledge base.

The endpoint itself became Files.com’s job to run. There is no server for Madison AI to patch and no key management carried as a side project. Each client’s account is provisioned and scoped on the platform, and standing up the next one means creating a folder and a credential.

Intake Became a Standard Part of Onboarding

With intake in production on Files.com, Madison AI replaced an engineering exception with a standard step in bringing on a client.

New clients are now told during onboarding that their SFTP is being set up on Files.com. Intake no longer trails the engagement as a separate engineering task; it is part of the standard script. Client records now arrive at roughly a terabyte a month through the same channel.

The Handover Is Now Part of the Product

Madison AI sells AI built entirely from what its clients hand over, and since the move to Files.com, the handover runs through the platform. Bringing on a city used to begin with an engineer sharing a password to a storage container. Today it begins with the client being shown their own intake: here is your folder, here is your account, start sending records. An agency clerk with a browser can deliver the same library a municipal IT department delivers over SFTP, and either way the records land isolated and in the right place, ready for processing.

A storage container wearing an SFTP endpoint had turned every new customer into a credential and maintenance task. A managed, per-client intake on Files.com turned that same moment into a standard step of onboarding. For a company whose product begins the day the records arrive, that first day now works like the rest of it.