CopaMigo

AI Strategy · Student Success Tools · Case study

A student-facing AI triage tool that reads a community college student’s problem in their own words, in the language they think in, and routes it to the right human service with a warm handoff card.

1. Summary

CopaMigo reads a stuck community college student’s problem in plain language, in the language they think in, and routes it to the right human service with a warm handoff card. It is in pilot in the Digital Media Arts program’s Discord, where students are testing it, and nothing is in production. The one-college pilot in section 7 is planned and has not started.

2. Goal

Get a stuck student to the right person quickly, without asking them to name the office or already know the institutional vocabulary. This is a student-success problem before it is a technology one. The students most likely to fall through the cracks are the ones who do not yet know that what they are feeling has an office attached to it: a student with undiagnosed ADHD will never search for “disability resources,” and a student one missed payment from dropping will not describe it as a financial aid appeal. Meeting them in plain language and doing the translation for them removes a barrier that sits in front of every service, and it does so at the moment a student is willing to reach out rather than days later.

The questions students actually ask are mostly not on the website: what happens to my aid if I drop this class, who do I talk to if I cannot pay this week, is there food, can I bring my kid, am I going to get in trouble for asking. Those answers live in the heads of the staff who do the work, not on a page a crawler can index.

A second goal shapes every technical decision that follows: prove a college can run a useful student-facing AI tool that collects no student data. The district declined a vendor AI add-on to its student CRM because it would have put student data within reach of a third-party model. CopaMigo is the argument that the data-sovereign path is available, not only the data-harvesting one.

Landscape scan

Student-success platforms cover a good deal of this territory, EAB Navigate360 most directly, alongside case-management and campus-chatbot products from Ivy by Gravyty, Civitas Learning, and others. They are strong at case management, early alerts, scheduling, campaign outreach, and in several cases routing. The piece I could not find was a curated answer bank written for the way students actually ask, with the office that owns each service owning the wording of its own answers. CopaMigo is the front door and the content layer, not the case-management system behind it, and it is designed to hand its content to whatever platform a college ends up running.

3. Users and context

Community college students at GCC, a Hispanic-Serving Institution, and the staff who serve them. It is built for the student who describes a problem in everyday words rather than the correct term, the prospective or returning student for whom a phone call already feels like a commitment, the student avoiding a label (an IEP history, anxiety, or ADHD that they do not name as disability), and the multilingual student who wants to be answered in the language they think in rather than through a translate button. CopaMigo answers in the student’s own language, not just English and Spanish: it runs on a model optimized for about a dozen languages that handles many more, so a student can write in Arabic, Vietnamese, Tagalog, or whatever they think in.

On the other side are the advisors, financial aid staff, disability resource staff, veterans coordinator, librarians, counselors, social workers, and tutoring staff who write and own the answers the tool delivers. They are the audience too: the design goal for them is fewer repeat questions, students who arrive with context already attached, and content they can correct within two working days of a change.

4. How it works

A student types or speaks a problem in their own words. CopaMigo reads it for urgency and need, answers directly when the responsible department has already supplied the answer, and otherwise hands off to a person. Unlike a website chat widget that scans pages and returns links, every answer is written for the question, not retrieved from a page. Today the answers are drafted by the product owner in consultation with the service offices. No department has formally verified its answers yet. That verification is the job of the staff knowledge builder, which is built and has not been run with a department. The AI is the delivery layer, not the author.

The handoff card

The card is where the tool does its most careful work, because it is built to remove every remaining unknown between the student and the door. It is specific, not a generic office listing, and every field is there so the student never has to run a second search. The card carries:

• The office name, and one plain-language line on what it actually does.
• The exact location, down to the building and the room number, and it is campus-aware: a student at North Campus gets the North office, a student at Main gets Main, so the directions are never for the wrong place.
• A map that points to that exact building, not a general campus map.
• The office website.
• The hours, so the student knows whether it is open right now.
• The phone number.
• What to say when they arrive or call, the specific opening line, so a nervous student never has to improvise the ask.
• The specific next step to take.

The point is that a student can act on the card immediately, in person or by phone, without a second search and without having to work out what to ask.

The student experience

Everything on the student’s side is designed to lower the cost of asking. The student writes or speaks in everyday words, is met with a human acknowledgment before any label or form, and receives a card they can act on in the moment. Voice in and voice out let a student speak instead of type and hear the answer read back in their own language (for example, speak Spanish and be answered in Spanish), and the whole thing runs on a phone. The standalone page asks for no login, no name and no account. The current pilot runs inside Discord, under the account a student already has there, and CopaMigo stores none of it.

Every incoming message sorts into one of three routing tiers. The tier is decided by the nature of the question, not its topic.

A few rules hold across all three tiers, and each exists for a reason grounded in how students actually ask for help.

• Empathy first, label second. The first response acknowledges what the student said in human language. The office is named only after the student has been received, because a student who leads with shame will not stay for a form.
• One situation can route to several offices at once. “I am failing and my aid is on hold” reaches advising and financial aid, each with context, so the student does not have to tell the story twice.
• The bot names no courses. Training data on course codes is unreliable across semesters, and a hallucinated course name sends a student to register for the wrong class. The tool links the verified published program checksheet (a plain JavaScript lookup table of program to URL, no AI-constructed links) and routes first-semester students to an advisor before they register.
• Crisis and Title IX routing is hard-coded and runs ahead of everything else, including when the topic is raised indirectly.
• Voice in, voice out through the browser-native Web Speech API. No translation service and no per-message cost.

The pilot covers more than two dozen service areas, from advising and financial aid to disability resources, counseling, tutoring, library, basic needs, veterans, records, and crisis and Title IX routing, with more than 100 verified service links behind the cards, each checked to open the right page. The full list of what it recognizes and where each path routes is in Appendix A.

Requirements and acceptance criteria

Each requirement is one behavior. The checks beside it are what a builder or tester confirms before that requirement is called done. Status reflects what this document records as built.

5. Data, privacy, and governance

The only data leaving the browser is the student’s question and the response, and no identity is attached because none is collected, so there is nothing to mask or redact. This is the data-sovereign line the whole tool is built to prove: no student conversation data is retained to train an underlying model, under any hosting arrangement. In production the AI call moves to one stateless server-side function that holds the credential in a secrets manager, adds the system prompt, and returns the response, so the browser never holds a key and never sees the prompt. Nothing is logged today: the current build has no counter and no rating control. In the pilot build, anonymous routing counts (which cards showed, detected language, success or error) will be the only thing logged, by the server-side function; question text, response text, and any free-text field will not be. The one place a student may choose to share contact information is the handoff itself, with the receiving staff member only. FERPA review rests on that anonymous-first design, and a production release targets WCAG 2.1 Level AA.

6. Build and portability

The build

• A single HTML file, vanilla JavaScript, no framework, no backend, hosted on GitHub Pages, mobile-first. It ships two ways from one codebase: a standalone page a college can link from a homepage, a Canvas tab, or a QR code, and an embeddable widget that drops into an existing student services page. Same prompt, same cards, one deployment to maintain.
• Voice input and speech output run in the browser through the Web Speech API. No audio is sent anywhere.
• Routing logic, tier behavior, service cards, and every department-written answer live in one system prompt. The checksheet lookup is a plain JavaScript table, and the staff intake forms are ordinary web forms with no AI in them.
• The AI layer is the Claude API. In the pilot the call is made with a tester-supplied credential; the production architecture moves that call to a stateless server-side proxy, so the credential is handled off the browser entirely. Standing up that proxy is the first of three gates before the one-college pilot, and it is also where the anonymous counter and the thumbs rating get built. The other two gates are the accessibility audit (section 11) and department verification of the answers.

Model portability, Claude to Gemini

CopaMigo is built on the Anthropic Claude API, and the Maricopa district is standardizing on Google Gemini. That is a solvable mismatch by design, not a rebuild. Every AI call runs through a single request function, so moving the tool to Gemini means changing three things in one place: the endpoint, the authorization header, and the shape the response is parsed from. The system prompt, service cards, and department-written content are provider-agnostic text, and the routing, multilingual behavior, verified links, checksheet lookup, and intake forms are untouched by the swap. What changes is a re-run of the test set to re-tune wording, which is tuning, not re-architecting.

No student PII is ever sent to any model, so the privacy posture does not change with the provider. The order of preference is a campus or district Claude for Education account first, because the prompt was tuned against Claude and it keeps the key off student devices behind a server-side proxy. If that account does not come through, the fallback is the district Google tenant: point the request function at Gemini and run the key through the same server-side proxy on Maricopa infrastructure. Either way the credential lives server-side, never in the browser, which is the one hardening task independent of which model wins.

District infrastructure, the path forward (in progress)

The provider question above is being resolved at the district level. A pilot protocol has been requested through the AI Resource Center to reside at the district, and the district plans to stand up a small sanctioned model instance (Claude, and possibly a second such as OpenAI) that approved pilots can call. Because CopaMigo already runs every AI call through a single relay and sends no student data, pointing it at a district-hosted Claude instance is a configuration change, not a rebuild, and it removes any need for a personally-held credential. A district GitHub account has also been applied for, which would host the tool under district control in place of a personal account. Until those are live this is a roadblock and the build stays a pilot in one program. Once they land, this is where CopaMigo runs.

Dependencies

What has to be in place, and who provides it.

7. Pilot and testing

Testing so far. No counts were kept in the Design Studio test sessions or the Discord pilot, so no outcome numbers are claimed. The one-college pilot below is the first test with measures attached, and it has not started.

A pilot is not “launch it and watch.” It is a bounded test with the questions and the yardstick set before any student uses it, so the result can be trusted. This is the sequence, and it is the same shape every tool in this portfolio uses.

1. Frame the question first. The pilot has to answer two things: does plain-language triage route students to the right human more reliably than the status quo of a college website, and does the anonymous, no-data architecture hold under real traffic. Everything measured traces back to one of those.
2. Set a baseline. Decide what “better” is measured against before launch: today a stuck student either guesses at the right office from a website menu or gives up. Department-reported repeat-question load and a short pre-launch read on how students currently find services give a point to compare against.
3. Scope it to one college and get the content owned. One college, GCC Main and North, one semester. The term is not set: it follows department verification and the server-side step in section 6. Every participating office completes the staff knowledge builder: per question, the answer, where the student goes next, the official source page and whether it needs a person; per department, the role that keeps the answers current and how often they are checked, because a tool that routes to stale hours or a dead number fails the student it was built for. Students are told at the point of the handoff what, if anything, they are choosing to share, which is the consent step.
4. Instrument only what is anonymous. Because the tool stores no identity by design, evidence comes from anonymous routing outcomes, an optional thumbs up or down after a handoff card, a scripted crisis test set run by the counseling team, and department surveys on repeat-question load. Measure the routing behavior, not satisfaction.
5. Run one semester without moving the target. Fix only what is broken during the run and save redesign ideas for after, so it stays possible to tell what produced the result.
6. Analyze against the baseline, then decide keep, iterate, or sunset. A pilot that produces a clear negative is a successful pilot. If routing is unreliable, or staff cannot sustain the handoffs, that is a finding that changes the next build rather than a failure to hide.

8. Definition of success

Version 1.0 means the pilot passed and the tool is cleared for rollout. Clear thresholds, not aspirations.

• At least 80 percent of students who rate a handoff say it was the right office, on an optional thumbs up or down with no identifying data attached. No more than 15 percent of questions end with no service match. Both are counted over the full pilot semester. The thumbs control and the counter are designed and not built, so neither number can be collected yet. They are built with the server-side function, before the pilot starts.
• Crisis routing appears within one exchange, every time, confirmed by the counseling team running a scripted set of crisis test messages. No student conversation is stored, so there is nothing else to audit.
• Every first-semester course question ends in an advisor prompt, with zero self-advising outcomes and zero fabricated course names.
• Every participating office has signed off on its card content and named an owner, and changes to hours and deadlines appear within two working days.
• Departments report less repeat-question load, and staff assess the handoff volume as sustainable rather than a new burden.
• Zero incidents of student-identifying data collected, transmitted, or logged. This one is pass or fail, not a percentage.
• The WCAG 2.1 Level AA audit is complete and blocking issues are resolved.

Anything short of that keeps it a pilot in one program.

9. Rollout

The pilot is scoped to one college, GCC Main and North, for one semester, reaching students through the Canvas Student Resources button, with each participating office owning its own card content. If it passes the thresholds above, the same one-codebase deployment extends outward the low-cost way: the standalone page or the embeddable widget goes to additional offices, then to other Maricopa colleges, each bringing its own staff-authored content and named owners. Growth is by adding staff-owned content and offices, not by loosening the no-data design.

9.1 Adoption plan

A tool that routes students to offices changes the work of those offices. This is the plan for the people, written before the one-college pilot, not after it.

Out of scope

• Collecting student data or requiring a login, a name, an account, or a student record.
• Answers authored by the model. Every answer is written for the question and is to be confirmed and owned by the responsible office.
• Naming courses or building links with AI; the product links only the published program checksheet from a fixed lookup table.
• A live connection to a person from the handoff card; this is planned for version 2.
• Attempting an answer for crisis, Title IX, or other Tier 3 situations; these go to a person at once.
• Use of a translation service, and sending audio off the device.
• Retaining student conversations to train a model, and logging question text, reply text, or any free-text field.
• Extension to additional offices or other Maricopa colleges before the pilot passes its thresholds, and redesign during the pilot semester.

10. Open questions and risks

• Server-side credential handling. Moving the AI call to a server-side proxy is the first gate before the one-college pilot; until it is in place the tool stays a pilot in one program.
• Which sanctioned model backs it. Campus or district Claude, the district Gemini tenant, or the coming district instance is unresolved. The single-relay design makes the swap a configuration change, but the decision is not ours alone.
• Handoff sustainability. Whether staff can absorb the routed students as routine questions fall is a pilot question, not an assumption.
• Content staleness. Stale hours, deadlines, or a dead number would fail the student the tool exists for. Mitigated by a named owner per office, but it is the standing operational risk.

Questions to settle before the next build

1. Where does the pilot run: inside the program Discord, on the standalone page, or both? If Discord, which of the stated requirements still apply there (no login, voice, campus-aware cards, the embeddable widget)?
2. Who hosts the server-side function and whose AI credential does it use for the pilot, given that the district model instance and district GitHub account are not yet live?
3. How does a submission from the staff knowledge builder or question intake form reach the system prompt: where is it stored, who reviews it, and how soon must it appear in student replies?
4. How does the product learn whether a student attends Main or North: does it ask, or is it inferred from the message?
5. Where will the anonymous routing counts and thumbs results be stored once the server-side function exists?

11. Roadmap

Near term and blocking: stand up the server-side proxy so credentials are handled off the browser entirely. Then point the single relay at the district-sanctioned model instance once it is stood up, with a district GitHub account hosting the code. Complete the WCAG 2.1 Level AA audit before any live release. Longer term, and only if the pilot passes, extend to more offices and colleges on the same no-data design, each with its own staff-owned content. Version 2 adds a live link to a human directly from the handoff card, so a student can reach a person in the moment, a warm connection rather than only directions to go find one later.

Appendix A. Service routing directory

This is the full map of what CopaMigo listens for and where it sends each student, transcribed from the tool itself. It is here so Student Services can see everything programmed into the tool in one place, whatever tool the college ultimately adopts. Every row is a service area the tool recognizes from plain-language input, the kinds of things a student actually types or says, and the office the handoff card points them to. Routing runs on what the student is trying to accomplish, not the keyword they use, and one situation can open more than one card at once.

Beyond routing: the domain knowledge built in

Alongside the routing above, the tool carries the detailed knowledge each handoff depends on, drafted from published sources and not yet signed off by the offices, so a student gets a real first answer and not just a door number. The deepest areas are:

• Veterans and GI Bill. Plain-language triage across GI Bill chapters, the Arizona Purple Heart Waiver eligibility tiers, in-state tuition for recent separations, MyCAA for spouses, benefits paid in arrears, monthly enrollment verification, and every-semester re-certification.
• Disability resources. The step-by-step DRS registration process, why a high-school IEP or 504 does not carry over to college, the documentation typically needed, and the specific accommodations DRS provides.
• Financial aid rules. How dropping or withdrawing affects aid, SAP, book advances, refunds, and how those rules interact with VA benefits.
• The instructor-first rule. A student struggling inside a class is guided to the instructor, then the department chair, then the dean of instruction (Maricopa AR S-6), with tutoring offered as backup.
• Course routing without course names. The tool never names a course from model memory; it links the verified published program checksheet and routes first-semester students to an advisor before they register.

The full source of truth is the tool’s own system prompt, which every answer is drawn from.