No. 08 · Technical

The AI Factory: Design and Ideation (Pronghorn)

Project Pronghorn is the first of the factory's three stages. AI tools translate Ministry requirements into prototypes, artifacts, visual canvases, and project artifacts before the build process begins.

By late 2025, Technology and Innovation's AI Maximalist team had "vibe-coded" several hundred prototype applications on platforms like Lovable. As models became more capable and staff became more experienced, application development and prototyping accelerated. However, AI agents typically focused on user experience and made undocumented architectural decisions which negatively impacted security, deployment, and suitability for government workloads. These platforms also forced specific technology choices (such as using Supabase and other software-as-a-service platforms) which were not part of our standard and when implemented incorrectly could easily introduce new security risks. 

To be clear, these deficiencies have nothing to do with the capabilities of the models themselves, but in how they are used. Staff do not seem to implement robust security controls from the beginning, and backend solution delivery was unplanned, inconsistent, and ad-hoc in their implementation. It was clear that Alberta needed tools that were easy for anyone to use and powerful enough to create an integrated picture of what was being built **before** development began. New processes are needed to formalize these steps to ensure they are not missed. In November of 2025, the AI Maximalist team began to build a solution to address these challenges which became Project Pronghorn.


## §01 Enter the pronghorn

Pronghorn was the right mascot for this initiative. The pronghorn is the second-fastest land animal in the world and the fastest in North America, native to Alberta, with a wide field of view and the endurance to run for hours. We wanted a tool with the same qualities: fast, far-seeing, and able to maintain a high velocity over a long distance. Our initial ambition was for Pronghorn to become a single, comprehensive solution which solved the whole build end-to-end, from requirements and prototyping through architecture, database, and deployment. The initial release did this moderately effectively, allowing our first end-to-end build within a common platform. However, as technology evolved and agentic coding platforms like Claude Code, GitHub Copilot, and Perplexity Computer evolved, we narrowed Pronghorn's scope to focus more specifically on transforming ideas and requirements into prototypes, architectures, and artifacts needed to initiate a project. This was, and remains, an underserved and overlooked step in the development process. So, we pivoted and stayed nimble (like a pronghorn), the platform became more focused on the first of the three stages of what we call an AI factory.


## §02 The AI factory in three stages

The concept of the AI factory is to maximally leverage agentic AI to lead application development from ideation through delivery. Alberta's objective is to maximally leverage AI to increase quality and speed while reducing cost. To do this effectively, we imagined the process being split into three distinct stages. 


The first stage gathers the raw material such as requirements, dependencies, transcripts, and current processes and workflows. AI supports this stage by transforming these artifacts into clear prototypes, designs, requirements, specifications, and project artifacts such as business cases, charters, and clear and well-documented architectural designs. The second builds. The third measures. 


Pronghorn serves this first stage, where the common parts, the components, the specifications, and the architecture are settled, and where you decide what you are actually trying to build.


## §03 The automobile factory as a useful analogy

An automobile factory is a useful analogy to understand the application design process in the AI era. 


Many car designs begin a block of clay, shaped by an artist who has a sense of style and a set of hard constraints: the shape has to be aerodynamic, attractive, road-safe, and within the limits for clearance, height, windows, and doors. The clay is only the look, and that is enough to start from. Once sculpted, it is scanned, digitized into a 3D model, and refined in software into something stronger. Then come the specifications. In Canada, Transport Canada sets out what a car must meet to be legal on the road, an exhaustive set of safety standards. And then the skills: a design is converted into tens of thousands of distinct parts, each pre-manufactured and catalogued with its own design, materials, and data sheet, all assembled first inside a computer. Validation software ensures that nothing collides and that every part can be installed and removed in sequence with ordinary tools. 


Traditional (pre-AI) software follows similar development processes to the automobile design. Visual prototypes and wireframes are created to validate the core assumptions. Branding and styles over integrated.  Architectural decisions are made, and enterprise standards are layered over into the plans. Functional requirements (what the user sees and does) and non-functional requirements (how the application works and is protected) and defined and approved for sign-off by a range of stakeholders. Costing is broken down by distinct components and features, and a timeline and cost are set and approved. 


AI-based application development skips many if not most of these steps by default, springing straight into user interface and workflow. This provides immediate visual gratification but pushes those decisions to later. To extend the analogy, you see the body of the car, but the brakes, engine, axles, and chassis are absent. Visually attractive, but not ready or safe to drive.


## §04 Automation vs. artisan crafted

The factory points at where we want to go on standardization. 

Humans also struggle with consistency across applications. Without a clearly defined standard, two different human developers will make a range of decisions which inform the experience. For a distinct software product, that uniqueness can be an asset. In government it is mostly a liability. Government highly values a positive user experience and creativity that solves a novel problem, and yet repeatability, security, usability, and accessibility matter far more than a distinct, bespoke feel. Across thousands of public-facing services, a departure from the common look is disorienting rather than charming.

Across decades of development and ministries, the user experience has drifted. Individual applications aim for consistency within the code base, but across the technology estate there is significant diversity which becomes a bewildering for users. For someone seeking social services, using a screen reader or another assistive technology, that inconsistency is the difference between getting help and giving up. The standard has to meet the public where they are. 


AI-enabled delivery can compound problem, as every vibe-coded prototype tends to be different unless a clear standard is introduced from the very first step. However, AI can also effectively solve this problem by defining universal standards which each AI agent follows. This requires a central, machine-readable repository of standards, templates, and code samples (such as a library of common, reusable components) which are defined and enforced throughout the build process. The Well Built Harness is an example of how these standards can be enforced.

Alberta is seeking to eliminate this complexity through AI-driven implementation. Using our standards-driven approach, we are rationalizing this complexity into a clear, common set of AI-readable standards. This ensures usability is high, accessibility is assured, and the experience is consistent across every interface a person has to use. In executing The Four Approaches to AI Modernization, we harmonize this experience in the approaches provided therein. These standards and approaches are applied within the first step of the factory through the Pronghorn platform.


## §05 Enter Pronghorn

Alberta built the first version of Pronghorn (known as Pronghorn Red) as an open-source React / Supabase application. It was initially on Lovable and integrated into Render.com and 3rd party Cloud providers for database integration. It supports a range of different Google, Anthropic, and SpaceXAI models, and provides a suite of AI-enabled tools which support the application development lifecycle. 


More recently, Alberta worked with Microsoft Canada to port Pronghorn Blue into a refactored version which is more aligned to enterprise environments. It introduces OpenAI model support, and leverages Azure-native stack components such as databases and containerized deployments. Pronghorn Blue is maintained in partnership between Microsoft and the Government of Alberta  and will be developed and maintained throughout the year ahead to add additional features. Red remains a good reference architecture but is no longer under active development. Both versions are for deployment by any organization into their own private or public cloud environment. Both are released under the open-source MIT License for unfettered use. 


## §06 From an idea to a specification

A project in Pronghorn starts with a little metadata and a choice of models, and moves quickly into a chat with the latest AI. The chat is familiar but introduces a rapid prototyping ability. Described apps show up immediately in the body of the chat, so ideas can be worked out faster. Someone with no technical background, and no place to host an app, can describe what they want and watch a live, functional mock-up appear, ready to share with a client for reactions. You can keep an unlimited number of threaded conversations, clone conversations, and you can download the whole chat. As an aside, we commonly reiterate that any platform that will not let you take your chat content away is inherently flawed. The content is your intellectual property, and you need to be able to keep it, curate it, and pass it to an agent. Pronghorn enables this.

Next is the Artifact space, where Pronghorn has deep functionality, because an agent is only as good as the context it is given. Projects usually are initiated with a range of diverse artifacts, such as slide decks, PDFs, Word documents, and web pages, and the artifact space brings all of that in, indexed and ready for the AI to use. Pronghorn enables you to generate and analyze images, so a user-interface mock-up can be made with an image model and refined in place. You can edit any artifact collaboratively with an AI editor that keeps an immutable history of every change, so a document of any kind can be drafted and iterated quickly, with real version control, image and PDF processing, and clean file management.

From your chats and the artifacts, Pronghorn builds the business requirements. Point it at the material, and it works through a structured, agile hierarchy: epics at the top, then the features inside them, then the user stories, and the acceptance criteria that say when each story is done. The result is a four-level map you can build out, track, and hand on, grounded in the documents the project actually started from rather than in someone's memory of a meeting.


## §07 The architecture canvas

The feature we are most excited about over the long run is a shared visual canvas, built on React Flow, where you drag and drop the parts of an application's architecture and work on them alongside AI agents that can both read the canvas and draw on it. A modern application has many layers: the cloud it runs in, the firewall, the front-end, the server, the third-party APIs, the databases, and the internal integrations. Drawn out as a functional architecture, that is dozens or hundreds of components linked into one diagram. In Pronghorn you can generate a notional architecture at the start, settle on it, and keep versioned copies that describe the whole application before any code exists.

This matters because it is another way to keep an interface from being vibe-coded into existence. In place of the long, verbose output of a language model, the canvas is a compact, tight description: a clear hierarchy of nodes joined by labelled edges, with metadata on each one saying what it does and how it connects. That is the right starting point for building, and it can be downloaded and handed straight to a coding agent. The shape of an enterprise application is a decision to make deliberately, up front, rather than one to leave to the choices an unpredictable model makes as it goes. The canvas is the functional architecture, which is itself a requirement, a non-functional one. Pair the functional requirements from the requirements section with the architecture from the canvas, and you have a thorough specification that says clearly how the application should work.


## §08 Agents that prepare the project

Pronghorn ships a set of agents that prepare a project for approval and for the build. A business-case writer, a charter and RFP writer, a project planner, and a timeline builder read your chats, your artifacts, and your canvases, and produce a project plan ready to take to a client for buy-in. You can change these agents, build your own, and arrange them into a workflow that expands a thin idea into the full set of artifacts a project needs to begin.

Pronghorn also includes coding agents and a database agent, quick ways to scale an idea out: importing data already in JSON or CSV, connecting to a range of databases, and working against a Postgres database hosted on Azure, Render, AWS, or elsewhere, with handy deployment into Azure and render.com in the Red edition. Those build-and-deploy features now live more fully in the next stage of the factory, Nexus, which adds the security controls and the agent observability that Pronghorn was never meant to carry.


## §09 The first third of the factory

Pronghorn is the first critical phase: research and ideation, architectural development, and requirements mapping. Set alongside the client's own requirements, documents, and meeting transcripts, it grounds an enterprise application in a clear set of artifacts that an agentic coding agent can read natively. Pronghorn exposes those connections both ways. A listener in Claude Code can watch for changes in a Pronghorn project, and an API lets any agentic coding platform write back into it, so an agent can be a first-class contributor, adding to the architecture, the requirements, and the artifacts. From Nexus, the two link in both directions, and the development is driven from there.

A word to our builders. The temptation in agentic development is to start building the application straight away. It is satisfying, it lets you test an idea fast, and it is also how you end up with an architecture badly misaligned with the technology stack you have to live in. Pronghorn is the place for technical and non-technical staff to agree on scope, plans, and requirements before that happens. Nothing in it is locked in; the artifacts come away cleanly and move straight into the build. Skip this step at your peril, or you will ship applications that look right, follow the common standards, and still behave as a jagged, uneven experience underneath, especially at the API layer, where service delivery in the Government 3.0 model described in the four approaches is won or lost. The next paper shows where these specifications come together and are acted on, in the Nexus environment, by the agents that do the building.

DM Janak Alford introduces Pronghorn. Video: https://youtu.be/KGfDzqwuVMk

Tags: ai-factory, pronghorn, design, requirements, canvas, architecture, open-source

Open the interactive version