How we shipped AI workflow automation inside a Canadian municipality's tenant

The situation

A mid-size Canadian municipality — population in the low six figures — ran multiple subscription workflow tools across departments. Each tool did one job adequately and charged per execution. As the municipality automated more routine work — permit triage, internal service requests, councillor reporting, citizen FAQ routing — the per-execution licensing line grew faster than the productivity gain it produced. The IT director’s projections said the licensing cost would exceed a senior engineer’s salary within eighteen months.

Compounding the cost problem: the municipality’s privacy framework, aligned with ITSG-33 controls and the provincial privacy commissioner’s directives, required that personal information processed by any new system stay inside Canadian sovereign infrastructure. The vendor SaaS tools were US-headquartered, with data residency promises that were technically defensible but operationally fragile. Council had questions. The IT team did not have the headcount to build a custom replacement themselves.

FIG. 02 / SOVEREIGN MUNICIPAL AUTOMATION — intent in plain English compiles to an executable flow that runs against in-tenant systems. The only thing that leaves the perimeter is the model prompt itself, going to a Canadian-region inference endpoint. ITSG-33 alignment from identity, audit, and least-privilege properties of the deployment.

What we built

We deployed Kacha inside the municipality’s existing sovereign cloud tenant. Kacha is our AI-powered no-code automation platform: an operator describes a workflow in plain English, an AI consultant interviews them about the specifics, and the system compiles the result into an executable flow that runs against the operator’s data sources.

Deployment was straightforward because Kacha is a small set of containers that runs on any container host. We deployed on Odysseus inside the municipal tenant. The AI consultation routes to a Canadian-region frontier model; no prompt or response leaves the tenant. The flows themselves run against the municipality’s existing systems of record — the case-management system, the records system, the staff productivity suite for calendars and email, the geospatial system for spatial data.

The first workflow was a permit triage flow. A new permit application arrives; the flow extracts the permit type, the parcel, the requested timeline; checks against zoning and historical records; and routes the application to the right planner with a one-page summary. What previously took a clerk forty-five minutes per application now takes the system about ten seconds, with the clerk reviewing the routing decision before it commits.

How the deployment stayed sovereign

The architectural rule was simple: nothing crosses the tenant perimeter except outbound model inference, and that goes to a Canadian-region endpoint. The flows themselves run against systems already inside the perimeter. The audit log lives in the municipality’s relational store inside the tenant. Backups go to the municipality’s existing tenant storage. No vendor SaaS, no foreign cloud, no copy-out for analytics.

For the AI consultation specifically, we used Canadian-region frontier inference. The system routes the prompt directly from the consultant service to the Canadian endpoint; the response comes back the same way. We do not see the prompts; the municipality’s privacy officer has the audit trail to verify the route.

ITSG-33 alignment came from three properties of the deployment: identity (single-sign-on integration with the municipal directory), audit (per-flow execution log with replayable inputs and outputs), and least privilege (each flow runs as a service principal with the minimum permissions required for its connectors). The privacy commissioner’s review took six weeks; the system passed.

What it produced

The first workflow paid for the entire engagement within four months — the saved clerk time on permit triage alone exceeded the full year-one cost of the deployment. Subsequent workflows were faster and cheaper to build because the consultant could reuse connector configurations across flows. By month nine the municipality had ten workflows in production and was retiring the most expensive of the old subscription tools.

The IT team did not have to grow to take this on. The consultant model lets a department subject-matter expert describe what they need; the IT team’s role is to authorize the connectors and review the audit trail. Kacha absorbed the workflow-authoring work that previously needed either a dedicated automation team or a vendor SaaS.

What this pattern is good for

This pattern fits when three things are true: the customer is a Canadian public-sector entity with real sovereignty constraints, they already run a sovereign cloud tenant we can deploy inside, and they have specific repeatable workflows worth automating — not just one off-shoot of internal IT.

If the customer’s workflows are all unique one-shots, the per-flow build cost dominates and a custom integration is cheaper. If the customer cannot host containers in their own tenant, the sovereign claim cannot be made. Otherwise: 8–12 weeks to first production workflow, with each subsequent flow costing less than the licensing it replaces.