The BYU AI Foundry

Tier 3 · Real Build 7 min read

The BYU AI Foundry is a student-run organization at Brigham Young University that builds AI products for real clients. JD runs it. The agent system supports it: application intake, the website, a Supabase backend, and an automated build pipeline that lets a non-technical student (Corbin) ship website changes without breaking production.

What it is

The Foundry metaphor comes from the rebrand work (CHANGELOG 2026-06-06): models are molten material, the Foundry crew shapes them into products. The process: Melt → Pour → Cast → Temper → Ship. The site at byu-aifoundry.com reflects this — a Molten Intelligence aesthetic with an ember canvas, cast-iron palette, and a process section showing where students fit in.

The student org takes on AI projects for local businesses and nonprofits, builds real products (not demos), and ships them. Students gain portfolio work and real client experience. Clients get working software.

The technical infrastructure

The website lives at github.com/JDDavenport under the ai-foundry-site repo. It is deployed via Vercel with an automatic build+deploy pipeline triggered on every main-branch push.

The Cloudflare tunnel (bridge.byu-aifoundry.com) provides a named, stable hostname for the agent system bridge. The tunnel is permanent — no more rotating ngrok URLs. The Nerve Center cockpit points to bridge.byu-aifoundry.com as its bridge URL.

The application backend routes to Supabase: the /api/apply endpoint writes to the foundry_applications table. A verification pass (CHANGELOG 2026-06-09) confirmed the table exists, the form submits correctly, and rows persist.

Branch protection on main — CI build+lint gates block any direct push to main. Non-admins (including Corbin) must open a PR, wait for the green CI check, and then self-merge. Admins can still push directly for urgent fixes.

The Corbin workflow

One concrete thing worth documenting: JD shipped a no-code contributor workflow for Corbin, a student team member who needs to update the website but is not a developer (CHANGELOG 2026-06-08 19:26).

The setup:

Branch protection on main with CI gate (no direct push)
Vercel auto-deploy wired to GitHub (every PR gets a preview URL; every main merge deploys to production)
CORBIN-SHIP-GUIDE.md in the repo — step-by-step instructions for making a change, opening a PR, waiting for CI green, and merging
Email sent to corbincs@student.byu.edu with the guide

The principle: the deployment infrastructure should be safe enough that someone who does not know what a CI check is can be trusted with it. The gate prevents a broken commit from reaching production; the guide explains the process in non-technical language.

The AI scout method

The Foundry needs to recruit students. The agent system has a scoping document for this (CHANGELOG 2026-06-08): the BYU cohort AI-scout method.

Key findings from the research:

BYU’s full-time MBA cohort is approximately 242 students — the only set where LinkedIn monitoring is feasible at safe scrape rates
The full alumni base (~9,000) exceeds safe monitoring capacity (~60–80 profile loads per day); mass monitoring would likely trigger a ban
The recommended build: fork the LinkedIn comment-engine targeter → cohort scout → Supabase → weekly AI-ranked digest of students with strong AI signals

The scout approach is keyword-prefilter first, then an LLM 0–5 relevance score on the shortlisted profiles. The weekly digest shows the ranked results; JD or a team member decides who to reach out to.

As of the last CHANGELOG entry, the cohort scout was proposed and scoped; the actual build was awaiting JD’s go-ahead.

What the agent system does for the Foundry

The AI Foundry is a domain with its own heartbeat agent. From ~/clawd/domains/ai-foundry/:

state/report.md — updated hourly by the heartbeat agent with current domain status
state/foundry.yaml — source of truth for milestones, stakeholders, and courses (7 milestones, 2 stakeholders, 3 courses as of the last Supabase sync)
Three Supabase tables: ai_foundry_milestones, ai_foundry_stakeholders, ai_foundry_courses

The domain agent (heartbeat at :52 past each hour) keeps the report.md current so the morning briefing can surface Foundry status without JD manually checking.

The Molten rebrand

The Molten Intelligence rebrand was built and deployed to a preview branch (CHANGELOG 2026-06-06 14:34). The design rationale: the Foundry metaphor needed a visual identity that matched — glowing seam dividers, cast-iron palette, live ember canvas, molten-flow headline typography. The preview URL ai-foundry-site-n9jqvopn7 was confirmed healthy.

The rebrand was not pushed to production immediately — JD had to approve the visual direction before the live site was updated. This is the right model for any branding change: build to preview, present to the stakeholder, ship only on approval. The agent built it; the decision to go live stayed with JD.

What to replicate from the Foundry build

Safe contributor workflows

If non-technical people will contribute to a codebase, build the safety gates before you give them access — not after they break something. Branch protection + CI + a plain-English guide takes an hour to set up.

Stable hostnames before launch

The rotating ngrok tunnel was a persistent pain point. Cloudflare named tunnels are permanent, free for basic use, and take 30 minutes to set up. Do it before the product is live.

Application backends in Supabase

A /api/apply → Supabase insert is the simplest possible application backend. Verifiable (query the table after a test submit), maintainable (schema migrations via the Management API), and free at hobby scale.

Domain heartbeats as status pages

The heartbeat agent writes a report.md every hour. That file is the status page. Any downstream consumer (briefing, cockpit, human) reads from the same source. No manual status updates needed.

Next: The final article in the series. Building in Public: The Honest-Marketing Rule covers the over-claim traps JD learned to avoid and what the public-build playbook actually looks like in practice.