Move CopaMigo onto college-owned hosting with credentials managed server-side, and settle whether it runs on Claude or Gemini, without rebuilding the tool.
The CTLE, GCC OIT, and the district AI CIO: the people who would own the infrastructure, the AI account, and the data-governance sign-off.
A staged path from the current prototype, to a lightweight hosted service, to the full district build. The AI provider is a swappable layer at every stage.
01. Current architecture and the path to production
Like most working prototypes, CopaMigo is built as a static web application that calls the AI service directly so it could be developed and iterated quickly. That is the right shape for a prototype and a demo. It is not the shape a student pilot should run on, for one main reason: production needs the AI credentials managed on a server, never handled in the browser.
The first production step is to place a lightweight server between the student and the AI. The browser talks to that server; the server holds the credentials and calls Claude or Gemini. This is a standard prototype-to-production move, and it is what makes secure credential handling, rate limiting, and anonymous request logging possible.
Nothing about CopaMigo’s design, content, or student experience changes. Only where the AI call is made changes.
02. The three questions this answers
- Where does it live? On hosting the college controls, with AI credentials held server-side.
- Who pays for the AI, and how? Not a per-student subscription. One institutional AI account billed by usage, or the district’s existing cloud AI access.
- Claude or Gemini? Either works. The provider is one small, swappable piece. This doc shows what actually changes if you switch.
03. Hosting: a staged path
You do not have to jump straight to a full district build. There is a sensible ladder, and each rung is a real, usable state.
Keep the prototype available for demonstrations and department review. Treat it as “safe to show,” not “ready to launch,” while the hosted version is stood up.
Put a thin server between the student and the AI so credentials live server-side and never touch the browser. This is a small amount of code (a single serverless function) and can run on a free or near-free tier (Cloudflare Workers, Vercel, or Google Cloud Functions). It also unlocks rate limiting and anonymous logging, which the PRD already calls for. This is the smallest step that is genuinely ready to pilot with students, and it can live on college-owned cloud.
The full build documented in the Deployment Guide: hosted in a Maricopa-owned cloud account, credentials in a secrets manager, WCAG audit, FERPA and CIO sign-off, monitoring, and a staffed handoff. If the district runs Google Cloud, the same architecture uses Gemini via Vertex AI instead of Claude via Bedrock. Same shape, different provider.
04. Claude or Gemini: does it “translate”?
Short answer: yes, and less changes than you would think. CopaMigo is built so the AI is a layer, not the foundation. Here is what carries over versus what changes.
What carries over unchanged (almost everything)
- The system prompt, all the routing tiers, service cards, GCC-specific answers, and department content. This is the real work and it is provider-agnostic text.
- The whole interface, the empathy-first design, the voice input and speech output, the multilingual behavior. Gemini handles multiple languages just as Claude does.
- The intake forms. The staff question-intake form and the advisor form are Google Forms and plain web pages. They have nothing to do with which AI runs the bot. Switching providers does not touch them at all.
- The verified links and program checksheet lookup. Pure data, no AI involved.
What actually changes (a small, contained piece)
- The few lines that call the AI. The endpoint and the shape of the request and response differ between Claude and Gemini. This is roughly a dozen lines, not a rebuild.
- Answer quality has to be re-checked. The same prompt produces slightly different responses on a different model, so you re-run the test set and tune wording. This is real work, but it is tuning, not starting over.
“The campus Gemini” usually means the Gemini chat assistant turned on for Maricopa Google accounts (Gemini for Education / Workspace). That is a product people log into and chat with. It is not the same as having a Gemini API that a custom tool like CopaMigo can call in the background.
To run CopaMigo on Gemini, the district would enable the Gemini API through Google Cloud (Vertex AI), which is a developer service OIT provisions, separate from the student chat app. The question to ask: “Do we have Gemini API / Vertex AI access, or only the Gemini assistant in our Google accounts?” The answer decides whether the Gemini path is a quick swap or a new procurement.
One institutional account, not per-student
The sustainable model is one institutional API account (Anthropic directly, or Claude through AWS Bedrock), billed by usage, not per student, serving the whole tool for everyone. That is far cheaper and simpler than buying every student an individual AI subscription. Gemini via Google Cloud works the same way: one district account, usage-based.
05. Rough cost comparison (verify current pricing)
Figures below are order-of-magnitude for a single-college pilot with short, routing-style conversations. Confirm live pricing with each provider before quoting anyone; treat this as shape, not a bid.
| Approach | Who owns it | Rough cost | Pilot-ready? |
|---|---|---|---|
| Prototype, client-side calls (today) | Project prototype | Minimal | No. Fine to demo, not to pilot. |
| Per-student individual AI subscriptions | Whoever pays the subscriptions | ~$20 per student per month | No. Scales badly for a routing tool. |
| One institutional API account + Stage 1 service | The college | Likely tens of dollars a month at pilot scale, usage-based | Yes. The recommended near-term path. |
| District cloud (Bedrock/Claude or Vertex/Gemini) | Maricopa OIT | Usage-based, plus staff time to run it | Yes. The long-term home (Deployment Guide). |
06. Recommendation and sequence
- Now: keep the prototype as a controlled demo for department review.
- Before any student pilot: stand up the Stage 1 hosted service so credentials are held server-side. Decide at that point whether it calls Claude or Gemini, based on what OIT can provision.
- Ask OIT the deciding question: do we have Gemini API / Vertex AI access, or only the Gemini assistant? And is there an institutional Claude or AWS Bedrock path? The answer picks the provider.
- Keep building content regardless. The system prompt, the department answers, and the intake forms are provider-neutral, so none of that work is at risk no matter which way the AI decision goes.
- Long term: the district-hosted build in the Deployment Guide, with the staffed human handoff.
The thing that would be painful to redo, the GCC-specific knowledge, the routing logic, the empathy-first design, the forms, is exactly the part that does not care whether it runs on Claude or Gemini, or where it is hosted. The decisions ahead are infrastructure and account decisions, not “rebuild the tool” decisions.
07. What to get from the meeting
- Who at GCC OIT owns hosting decisions for a student-facing tool, and can sponsor a Stage 1 environment.
- Whether the district has Gemini API / Vertex AI access, or an institutional Claude / Bedrock path (this picks the provider).
- Who signs off on data governance for a no-PII tool (the anonymous-first design is the asset here).
- Whether the CTLE will help recruit the department staff who populate answers and, later, staff the human handoff.