Washington state agencies spent nearly $137 million processing public records requests in 2023. That is up from $100 million in 2019. Average response times climbed from 15 days to 25 over the same period. Some agencies are averaging north of 85 days. The Washington State Senate clocks in at 85.1. Washington State University sits at 111.6. And the Public Records Act does not grade on a curve.
RCW 42.56 requires an initial response within five business days. Penalties for noncompliance run up to $100 per record, per day, plus the requester’s attorney fees. One city got hit with a $2.6 million penalty after sitting on a request for nine months. This is not theoretical risk. It is budget risk, legal risk, and public trust risk, and it compounds every day a request sits in someone’s inbox unworked.
The spreadsheet-and-shared-mailbox problem
Most Washington agencies are still managing records requests through some combination of Outlook, Excel, and institutional memory. A request arrives by email or web form. Someone logs it in a spreadsheet. Someone else routes it to the right department by forwarding it. Deadlines are tracked manually or not at all. Exemption reviews happen in ad hoc threads. Redaction is a person with Adobe and a highlighter tool. Final delivery is a file share link or, worse, physical media.
Every step in that process is a failure point. Missed deadlines, lost requests, incomplete exemption logs, inconsistent redaction, no audit trail. The WashCOG “Winners and Sinners” list exists because the gap between agencies that have this under control and agencies that do not is enormous. Attorney General Nick Brown has proposed new guidance pushing agencies toward triage-based processing, prioritizing simple requests so they do not get stuck behind complex ones. That is good policy. But policy without tooling is just a memo.
What agencies are buying (and what they already own)
The vendor market for public records request management is real. GovQA, NextRequest, Hyland, CivicPlus. These platforms do intake, tracking, redaction, and delivery. They work. They also cost six figures annually, require procurement cycles, add a new vendor dependency, and store your data outside the systems you already govern. For agencies already paying for Microsoft 365 in GCC (Government Community Cloud), that is a hard trade to justify when the same capabilities can be built with tools sitting unused in the tenant.
Power Automate, Copilot Studio, SharePoint, Purview, and Power Apps are all live in GCC. They are already inside your compliance boundary, already covered by your existing licenses, and already subject to FedRAMP authorization at the platform level. The gap is not tooling. It is engineering: someone who understands the PRA, understands the M365 stack in GCC, and can wire the pieces together into a system that actually runs.
The automation layer, piece by piece
A records request lifecycle has discrete phases: intake, triage, routing, search, exemption review, redaction, delivery, and close-out. Each one maps to capabilities that already exist in the GCC M365 stack. Here is what that looks like when it is engineered properly.
Intake starts with a Power Apps portal or a Microsoft Form that captures the requester’s information, the description of records sought, and the preferred delivery method. That submission triggers a Power Automate flow that logs the request in a SharePoint list, assigns a tracking number, timestamps the five-day clock, and fires an acknowledgment email to the requester. No human touches it until the triage step.
Triage is where AI changes the math. A Copilot Studio agent can classify incoming requests by type, complexity, and likely department. Simple requests (a single document, a known record series) get fast-tracked. Complex requests (broad date ranges, multiple departments, likely exemptions) get flagged for manual scoping. The agent does not make legal judgments. It sorts the queue so the records officer spends time on the requests that need human judgment, not the ones that need a file copy.
Routing uses Power Automate to push classified requests to the right department’s SharePoint site or Teams channel based on the triage output. Each department gets a task with the request details, a deadline calculated from the intake timestamp, and escalation logic if the task is not acknowledged within a configurable window. Deadline math is no longer in anyone’s head. It is in the flow.
Search and collection is where most agencies lose the most time. Documents live across SharePoint, OneDrive, Exchange, and file shares. Purview Content Search and eDiscovery (both live in GCC) can query across all of these surfaces against keywords, date ranges, and custodians. Results stage into a review set. This is the same tooling litigation teams use for discovery, and it works for PRA response the same way.
Exemption review and redaction happen in the staged document set. Purview sensitivity labels can flag documents that contain protected categories: personnel records, law enforcement investigative data, attorney-client communications, protected health information. That flag does not make the legal call. It tells the reviewer where to look instead of reading every page. Redaction itself can be handled through Power Automate connectors that process PDFs against regex patterns and AI-trained PII models, covering Social Security numbers, dates of birth, and other data types that commonly trigger PRA exemptions under RCW 42.56.230 through 42.56.480.
Delivery and close-out loop back to the requester through the same Power Apps portal or a secure SharePoint link with time-limited access. The flow logs the final production, updates the tracking list, and closes the request with a full audit trail: who touched it, when, what was produced, what was withheld, and the exemption cited for each withholding. That audit trail is what keeps you defensible when the next lawsuit lands.
Why GCC changes everything about this build
If you have read a commercial blog post about automating document workflows with Microsoft 365, most of the architecture above probably sounds familiar. The difference in GCC is that half the assumptions break. Feature parity between commercial and GCC is not one-to-one. Connectors that work in commercial may not be available in GCC. AI features roll out on a different timeline. Copilot Studio’s agentic capabilities (Agent Builder, Researcher, Analyst) only reached GCC in April 2026. Purview’s expanded sensitivity label enforcement in Office apps is rolling out to GCC in June 2026.
This means the architecture has to be designed around what is actually live in GCC today, not what shipped in commercial six months ago. It also means every connector, every AI action, and every data flow has to stay inside the FedRAMP-authorized compliance boundary. No calling out to commercial Azure Cognitive Services. No third-party AI APIs processing government records. No data leaving the GCC tenant. These are not preferences. They are requirements. And they disqualify most of the “just use AI” advice floating around LinkedIn.
Washington state adds another layer. WaTech’s DATA-04 AI Policy, revised in late 2025, establishes governance requirements for any AI system used by state agencies. The Attorney General’s AI Task Force is delivering its final report in July 2026 with additional recommendations that will shape procurement and deployment standards. Any AI automation system built for records request processing needs to align with these frameworks now, not retrofit compliance after the rules land. That means transparency logging, human-in-the-loop review for exemption decisions, and clear documentation of what the AI does and does not decide.
And here is one more constraint that most agencies have not thought through yet: AI prompts and outputs are themselves public records. Washington courts established in Belenski v. Jefferson County that automatically generated logs of government computer use are public records. Cities across the state have already produced ChatGPT conversation logs in response to PRA requests. If your records request automation system uses AI, the system’s own inputs and outputs are discoverable. That is not a reason to avoid AI. It is a reason to build with a platform that logs everything inside a boundary you control, which is exactly what Copilot Studio in GCC does.
What this is actually worth
The ROI on this build is not abstract. Washington agencies are spending $137 million a year on records request processing. Average response times are climbing. Penalty exposure is real and measured in millions. An automation system that cuts intake-to-acknowledgment from days to minutes, eliminates missed deadlines through calculated escalation, reduces manual search time through Purview-powered collection, and creates a defensible audit trail on every request does not need a complicated business case. It pays for itself the first time it prevents a penalty or frees up a records officer to work the complex requests instead of copy-pasting tracking numbers into a spreadsheet.
The agencies on WashCOG’s “Winners” list are not winning because they have more staff. They are winning because they have systems. The M365 GCC stack gives every Washington agency the raw materials to build those systems without a new procurement, a new vendor, or a new compliance risk.
Who builds this
I am Jacob Taylor, the engineer behind Puget Sound AI. I build AI agents, Copilot Studio solutions, and Power Automate workflows for government teams operating in Microsoft 365 GCC. Veteran-owned small business (VOSB). No account managers, no layers. You work directly with the person writing the code and configuring the tenant.
If your agency is buried in records requests and duct-taping the process together with spreadsheets and email, I would like to hear about it. Let’s talk.