From Bookmarks to Agents
A Faculty Practitioner’s Account of Building AI-Powered Learning Tools at a Community College

Abstract

This paper documents a faculty member’s path from saving links to building working AI tools at a community college, told in three arcs. The first is Cultivate, a personal learning environment that turned scattered bookmarks into tended professional-development infrastructure. The second is Render, an AI-supported career-readiness platform that translated that same model for students and has since grown from a seven-phase prototype into a redesigned capstone course whose final output is a portable career agent each student keeps. The third, and where the work is heading now, is agents: autonomous tools that watch, decide, and act, and a plan to teach faculty and student-services staff to build their own. All three are grounded in connectivist learning theory, built with AI as a co-developer, and held to one hard line: collect no student data. The paper traces the origin and design of each, what changed as the tools met real use, and the unresolved questions of sustainability, equity, and institutional adoption that remain.

1. The Problem This Started With

In January 2026, like many faculty members, I found myself trying to learn about artificial intelligence while simultaneously teaching, advising, running a publication, serving on committees, and managing everything else that comes with a full-time faculty position at a community college. The problem was not a lack of resources. It was too many resources in too many places with no coherent way to manage them.

I had bookmarks scattered across three browsers. Coursera courses I had enrolled in and abandoned. YouTube playlists I could not find again. Email newsletters I was not reading. Organization subscriptions through Maricopa, EDUCAUSE, the Online Learning Consortium, and others, that I was not fully using because I did not know where to start. What I needed was not more content. I needed a way to tend what I already had.

Around the same time, I was experiencing something a lot of people experienced: a low-grade anxiety fed by social media and news consumption. The easiest thing to reach for on my phone was a feed of content that left me feeling worse, not better. I recognized I needed to replace that habit with something more intentional. These two problems turned out to have the same solution.

I also had a theoretical framework sitting in the back of my mind from my 2017 MEd research at Northern Arizona University. My graduate work focused on connectivism and personal learning environments, the idea that learning happens through the connections we build and maintain, and that a learner’s environment should be something they construct and tend rather than something delivered to them. I had written about this as an abstract principle. Building Cultivate was the first time I applied it to my own life, and it set the pattern for everything that followed: find a real problem I live inside, build the tool that solves it, and let what I learn carry into the next build.

2. Cultivate: Building the Faculty Tool

Origin and First Version

Cultivate began in January 2026 as a simple HTML page where I collected links. It quickly became something more structured: a place to manage my professional development plan, track conference proposals, organize my planning, and curate the news and resources I actually wanted to read. I built it in HTML, CSS, and vanilla JavaScript because those were the only tools I had access to on my iPad while traveling, and because I wanted something that would work offline.

The offline requirement was not an afterthought. I travel frequently, I work in environments with unreliable connectivity, and I had grown tired of tools that required a constant internet connection to function. Building for offline-first meant accepting certain constraints, no database, no user accounts, data stored in the browser via localStorage, but those constraints shaped the tool in ways that made it more private, more portable, and more honest about what it actually was: a personal tool, not a platform. That constraint, born of an iPad and a plane, became a principle I carried into every tool after it.

The RSS Feed and the Doom-Scrolling Problem

One of the most consequential design decisions was building a live RSS news feed directly into Cultivate. The feed draws from 62 sources across five subject areas: AI in education, EdTech, student success, UX and design, and product management. Sources include EDUCAUSE, the Online Learning Consortium, Stanford HAI, EdSurge, MIT Technology Review, and organizations Maricopa already subscribes to that many faculty never use. A custom keyword classifier sorts incoming articles, and a 3-proxy waterfall with a 24-hour localStorage cache keeps the feed loading even when a primary source is down.

The purpose of the feed was not just professional development. It was to give me something intentional to read instead of social media. When the urge to reach for my phone arrives, I now open Cultivate instead. The feed is curated, relevant to my actual work, and does not have an engagement algorithm designed to keep me scrolling. This behavioral-design insight, that a tool can replace a harmful habit by meeting the same underlying need in a healthier way, became an important part of how I thought about Render later.

Claude was used throughout development as a co-developer: suggesting sources, writing and debugging code, helping think through information architecture, and serving as a sounding board when design decisions were unclear. These tools were not built by a software engineer. They were built by a faculty member with a design background, a theoretical framework, a problem to solve, and access to an AI that could write code. That is the part worth repeating, because it is what makes the story usable by other faculty.

Structure and Current State

Cultivate currently consists of six interconnected HTML pages: an AI Resources Hub, a Professional Development Plan, a Mesa Summit conference proposal page, a PD Log, a UX Toolkit, and a CV page. A full Product Requirements Document defines user stories, data model, success metrics, and adaptation pathways for other institutions. It is hosted at singletrackmom.github.io, used daily, and serves two roles beyond my own learning: it is the architectural model that Render was built from, and it is the content backbone for faculty-facing AI work at GCC. Cultivate is the proof of the thesis in the title: bookmarks became infrastructure.

3. Render: Translating the Model for Students

The Insight That Started It

The connection between Cultivate and Render came from noticing that everything students do in AVC 248, the Design Self Promotion capstone course I teach, maps to the same kind of infrastructure. Students in that course spend a semester on career readiness work: writing resumes, researching jobs, practicing interviews, identifying skills gaps, building a networking plan. When the semester ends and their Canvas access expires, that work disappears. They leave with finished assignments. They do not leave with a system they can keep using.

That gap between what students build inside a course and what they carry with them after graduation is the problem Render was designed to solve.

Design Decisions and Trade-offs

Render is built as a single HTML file with vanilla JavaScript and no framework dependencies. A single file that can be saved to a computer and used without an internet connection is more equitable than a web application that requires a subscription, an account, and a reliable connection. For community college students, many of whom at GCC have self-identified as food insecure, at a Hispanic-Serving Institution, that matters.

Authentication in the current prototype uses a first-name-only login. This was chosen to protect student privacy: no student ID, no email address, no institutional credentials stored anywhere. Data lives in the browser’s localStorage. This approach is intentional but is one of the most significant unresolved questions in the project. localStorage is device-specific and not durable, which is why durable storage sits near the top of the post-pilot list.

From Tool to Course: What Render Is Now

Render began as a seven-phase career launchpad. Over the cycle it grew into the engine of a fully redesigned course, and this is the part the original draft of this paper did not yet capture, because at the time it was still mostly an idea. Today the AVC 248 capstone is an AI-powered course built around Render: it opens with an AI-literacy unit, runs on weekly slide decks, includes a guided goals builder where each student anchors the semester to one real reach job they choose on day one, and finishes with a Module 9 “Build Your Career Agent” capstone. Students do not face a blank prompt; they work inside a structured environment, and they walk out with a fully populated launchpad (goals, job-search strings, resume drafts, cover letters, a networking tracker, interview practice, a weekly schedule, and a 90-day plan) exported as a standalone file they own.

The newest and, to me, most important addition is that Render does not get replaced by an agent, Render builds the agent. The capstone output is a portable career agent and personal learning plan, a Markdown file derived from a gap analysis between the student’s current skills and their reach job, that the student takes with them and runs in any AI tool to keep closing gaps and searching after graduation. The piece that makes that concrete is a gap-to-training agent: it takes the requirements from the real job postings a student has collected all semester, compares them to what the student already has, names the gaps, and builds a sequenced training plan to close them. A working prototype of that step is online (see the training-plan agent). This is the point where Render stops being a dashboard and starts being agentic, which is also the bridge to the next arc of this paper.

The Career Services Connection

When a student saves a job listing in the Job and Client Log, an anonymized summary, job title, company name, and a brief AI-generated description, is shared with GCC Career Services. The student’s name and personal details are never included. Career Services cannot build employer relationships they do not know students want; by surfacing employer interest in an anonymized, aggregated form, Render gives the institution data it currently does not have. This connects directly to research on student persistence: students who feel connected to campus support services succeed at higher rates.

The AI Layer

Render uses Claude (Anthropic) as the AI engine across 15 distinct functions: skills-gap analysis from job descriptions, tailored cover-letter generation, LinkedIn outreach drafting, role-specific interview questions with coaching feedback, and a personalized 90-day plan with a weekly schedule, among others. Each function is structured so the AI responds to what the student has already built, not to a blank prompt. The interface does the prompt engineering. The student does the thinking. Underneath, every Render module maps to a formal career-launch skills taxonomy I authored, so the tool doubles as an assessment backbone: progress in Render is progress against defined career-readiness competencies.

How It Landed

I presented Render at the Mesa Community College AI Summit in May 2026, its first public showing to a faculty audience, and the session was very well received. What surprised me was the cross-disciplinary pull: faculty outside Digital Media Arts wanted versions of it for their own students, including an Economics professor at CGCC and a Fitness and Wellness instructor at Mesa, and several reached out afterward about collaborating. That reaction reframed Render for me. It is not only a Digital Media Arts tool; the architecture is portable to any program with a career-readiness capstone, and faculty want help building their own. A full-class pilot in AVC 248 is planned for Fall 2026, and I am looking for a larger conference at which to present it with real pilot results.

Development Timeline

4. Agents: The Next Layer

Cultivate and Render are tools a person opens and uses. The next step I am taking is agents: software that runs on its own, watches something, decides, and acts, returning to a person only for the choices that should stay human. The gap-to-training step in Render is the first place my own work crossed that line, and learning to build agents well is the focus of the next phase.

Learning by Building

I am learning agentic AI the same way I learned everything else here: by building real ones and using them daily, not by studying from a distance. To practice, I built and run a suite of roughly ten scheduled agents. I will not catalog the personal ones; the point is the volume and variety, which is what taught me how scheduling, autonomy, and reusable instructions actually behave. They are where I learned that a good agent watches and proposes, and leaves the irreversible decision to a person. Each agent carries its own plain-language Markdown instructions, so I am refining a reusable recipe instead of starting over each time, which is how a pile of experiments became a dependable practice. The lesson that transferred most: a good agent watches and proposes; it leaves the irreversible decision to a person.

Why This Matters Beyond Me

As co-chair of the Student Support and Success domain of the Maricopa district AI committee, I keep seeing the same pattern across all ten colleges: support staff spend hours on routine, repetitive work, the easy factual question, the “we will get back to you in a few days” booking email, that pulls them away from the students who need a human. That routine layer is exactly what agents are good at. The goal is not to replace anyone; it is to take the dull, repeatable work off people’s plates so the human part of their job gets more of their time.

From My Practice to Mentoring Others

This is where the work is heading. Through the Faculty AI Community of Practice I am launching with our Center for Teaching, Learning and Engagement, I will share what I have learned, including how to build agents, beginning this fall. Through the district committee, one planned initiative is training student-services personnel, with at least one session on building agents for their own routine work. The model is short, hands-on sessions where people build one small, no-data agent for a real piece of their own workload, using reusable instructions they can keep and adapt. The same hard line holds here as everywhere else in this paper: these tools collect no student data.

5. Theoretical Grounding

All of this is rooted in connectivism, the learning theory developed by George Siemens and Stephen Downes, which argues that knowledge exists in networks and that learning is the act of forming and maintaining connections within those networks. The practical realization of connectivism is the personal learning environment, the ongoing practice of curating, connecting, and reflecting on resources in service of your own goals.

Cultivate and Render are both PLEs. Cultivate gives faculty a place to tend their professional learning infrastructure. Render gives students a place to tend their career-development infrastructure. Neither delivers content to a passive user; both require the user to put something in to get something out. Agents extend the same idea one step further: the portable career agent a student builds in Render is a piece of their learning network that keeps working for them after the course ends.

The design response to AI’s potential to shortcut that construction is consistent across all three arcs: use AI to respond to what the user has already built, not to replace the building. Render does not write a student’s resume from scratch; it suggests edits to a draft they wrote. An agent does not make the irreversible decision; it surfaces the option and leaves the choice to a person. The distinction is the whole point.

6. Unresolved Questions

7. What This Means for Other Faculty

These tools were not built by a software engineer with dedicated time and institutional support. They were built by a faculty member with a full teaching load, a design background, a graduate theory framework, and access to an AI that could write code. That is worth saying plainly because it changes what the story is about.

This is not a story about what institutions can build when they invest in AI infrastructure. It is a story about what faculty can build when they have a clear problem, a theoretical framework, and a tool that meets them where they are. The barrier to building tools that serve students is lower than it has ever been, and the most useful tools you can build are the ones that solve problems you understand deeply because you live inside them every day. The next barrier to fall is agents, and the point of teaching others to build them is so this stops being one faculty member’s practice and becomes something colleagues can do too.

The implication for institutions is the same as it was: faculty are building these tools whether institutions support them or not. The question is whether those institutions want to be part of what happens next.

8. Next Steps and Future Updates

This document will be updated at the following milestones: the end of the Fall 2026 Render pilot, the first Faculty AI Community of Practice sessions, the first student-services agent-building training, and upon any significant design decision or pivot. Each update will be dated and added to the timeline in Section 3.

A version of this paper is intended for a practitioner conference such as OLC Innovate or EDUCAUSE Annual, and potentially a practitioner journal such as EDUCAUSE Review or Innovative Higher Education, once the pilot is complete and the agent-mentoring work is underway.