Rumi v1.0 / agentic LMS POC
Context
The AI ambition existed before the product thesis.
Course content, assignments, LMS information, events, library resources, and campus services were fragmented across university systems. Students had to know where to look and repeatedly navigate between them. Rumi’s thesis was to understand student context and proactively surface what mattered now. The product needed a useful role, grounded information, and clear boundaries for assistance.
My ownership
I helped turn CEO-level vision into a product direction.
I started as an AI UI/UX Designer, with scope expanding into product ownership. I defined the product thesis, prototype, scope, workflows, agent behavior in PRDs, technical requirements, and roadmap. I worked with engineers on metadata, authoritative retrieval sources, APIs, RAG behavior, LLM fallback, contextual personalization, and learning guardrails. My contribution connected the intended student experience to technical requirements. The engineering team owned implementation responsibilities; I do not present the model or retrieval architecture as my independent creation.
Evidence
The product had to understand learning context.
The experience brought together 6+ university information sources. Student-specific facts such as assignments or grades required grounded retrieval. Context also had to change priorities: an approaching deadline should surface an assignment; exam periods should elevate academic tasks and suppress lower-priority recommendations. Pilot/user feedback was the main evaluation approach, including a reported highest-engagement signal among tested features.
Product judgment
Help the student learn. Do not simply do the work.
The central decision was where the agent should assist, retrieve, explain, and offer hints versus refuse to complete a student’s assignment. This was a product boundary, not just a tone-of-voice rule. A capability that gives an answer quickly can still fail the purpose of a learning product. I helped translate that principle into AI behaviors and requirements rather than frame success as adding a chatbot or maximizing the number of completed responses.
| Behavior | Product intent | Boundary |
|---|---|---|
| Retrieve | Use authoritative information | Ground guidance in available sources |
| Explain / hint | Help the learner progress | Support understanding |
| Complete assignments | Do the learner’s work | Outside the intended assistance boundary |
Decision summary reconstructed from Mani’s account. Original artifact not supplied.
PRODUCT BEHAVIOR / GUIDANCE IN CONTEXT
From “what’s due?”
to “what do I need to do?”
The supplied mocks connect a task list to research milestones and citation requirements. They show guidance and instructions; they do not establish that the agent can reliably enforce every learning guardrail.
Supplied mobile mocks · Consistent scale and alignment
Planning can lead to action.
A separate proposed flow shows a weekly schedule, an explicit confirmation, and a calendar result. These are prototype screens: the dummy calendar link does not verify a working Google Calendar integration.
Original screenshots in matching phone frames · Proposed interaction
Trade-off
Immediate completion was not the only definition of value.
The learning principle constrained the help the agent should provide. Guidance and explanation took priority over simply completing the student’s work. This created a deliberate tension between convenience and learner progress. The exact refusal policy, fallback thresholds, and evaluation cases are not yet documented in the portfolio, so I do not claim perfect guardrail reliability or a measured learning improvement.
Influence & execution
Make the vision concrete enough to test.
The work moved from leadership vision into a product thesis, initial workflows, prototype, technical requirements, and roadmap. Collaboration with engineers connected the experience to data and system behavior. Rumi v1.0 / the agentic LMS proof of concept took approximately five weeks. The product also became part of strategic discussions with D2L around a potential partnership and MOU. Those discussions were a validation opportunity, not a completed commercial outcome.
Outcome
A working POC, an engagement signal, and an unfinished partnership.
During pilot testing, Rumi had the highest feature engagement among the tested capabilities, as reported in the project account. The work contributed to D2L MOU discussions, but the MOU ultimately did not proceed. Both facts belong in the story. The POC demonstrated progress from an abstract vision to an evaluable product; it did not establish durable learner outcomes, a signed partnership, or product-market fit.
Learning
AI product strategy starts with the job and its boundaries.
The useful question was not whether the LMS could contain AI. It was what assistance would help a student progress, what evidence the agent could use, and what it should decline to do. The guardrails and retrieval requirements made that question operational. The next evidence needed is whether the experience improved learning, not only whether students engaged with it.
THE REASONING BEHIND THE RESULT
What made the decision difficult?
Inspect ownership, evidence, alternatives, technical constraints, and the limits of the result.
CONTINUE THROUGH THE WORK