GIA — Study Abroad Copilot

Capability accumulated the way it does in any maturing platform — dashboards, filters, discovery flows, scholarships, applications, visa and application information, and more besides. Each addition was reasonable on its own. Together they meant a counsellor had to hold a map of the product in their head before they could act on it.

The problem wasn’t lack of information.

Users had to understand how the system was organised before they could find what they needed.

Rather than adding another screen to learn, GIA sits over the platform the counsellor already has. It reads the request, works out what is missing, calls the same services the portal calls, and answers in the shape the question was asked in.

A single exchange shows the whole behaviour. The question arrives the way a person would say it — imprecise, abbreviated, and with one detail that changes the answer left unstated.

The last frame is the one worth reading twice. GIA returns the courses it found and states plainly that none of them publishes the requirement that was asked for — then offers the two next moves that would actually help.

I worked closely with the Product Manager and owned the engineering lifecycle end-to-end — talking to customers, understanding their workflows, working with design on the interaction model, building the portal experience, creating the copilot backend and MCP tools, writing prompts, evaluating behaviour, monitoring usage and iterating from feedback.

User problem→Research→Product flow→Design→Frontend→Copilot backend→MCP tools→Prompts→Evaluation→Release→User feedback

Counsellors disagreed — reasonably — about what GIA should infer on its own, when it should stop and ask, how much clarification was welcome rather than annoying, and what shape an answer should arrive in. There was no specification that settled it. The interaction model had to be found by watching people use it.

Talk to users→Observe expectations→Identify patterns→Change the interaction→Test again

The hardest part wasn’t making it answer.

It was figuring out how people expected it to behave.

GIA does not hold its own copy of the domain. It decides what is being asked, chooses a tool, and calls the same product services the portal calls — so an answer in the chat and an answer in the CRM come from the same place.

Counsellor→GIA UI→Copilot service→LLM / prompt layer→Tool decision→MCP tools→Product APIs / data→Structured response

“Users asked us to bring GIA to WhatsApp.”

Counsellors began using GIA in their day-to-day workflow for faster access to information and answers. As usage grew, some users wanted to interact with the same copilot through WhatsApp rather than only through the portal.

The copilot was becoming less like another feature in the CRM and more like an interface users wanted available wherever they worked.

Building GIA changed how I think about AI products. The model is only one part of the system. Understanding when to ask, when to retrieve, what to trust and how users expect the product to behave often matters more.