What happened when we made everyone an AI builder, not just an AI user

Most AI rollouts start the same way. Leadership picks a platform. IT configures it. Everyone gets access. A few people use it regularly. Most forget about it within a month.

We tried the opposite. Instead of giving the team a tool, we asked each person to build one. We can tell you what the process looked like. We're still figuring out whether the outputs justified it.

The problem we were actually trying to solve

We're a consulting team. Seven people across presales, content, marketing, and solutions. Everyone's job looks different. The daily context is different. The client problems are different.

A single shared AI tool couldn't hold all of that. It would either be too generic to help or too specific to one person's job to serve anyone else. The real gap wasn't access to AI. It was relevance. We needed AI that understood each person's actual work, or at least we believed we did.

What we did

Our team lead ran a workshop on building custom GPTs using OpenAI's ChatGPT platform. The assignment: each person would create a personalized "AI Partner" configured with their role-specific knowledge, client context, and daily workflows. Then share the link in Slack.

The workshop happened. Then reality set in.

When the team lead checked in on October 23rd, responses ranged from "almost done" to "haven't started." People were on client calls. On leave. Buried in opportunity evaluations. One team member had missed the workshop entirely because of a client engagement and needed to pair with a colleague to catch up.

This is the part most AI adoption stories skip. The initiative wasn't competing with laziness. It was competing with billable work. A hard deadline was set: share your GPT link by Friday. Over the next ten days, all seven links came in.

Two approaches worth examining

The dossier on this initiative is thin on technical specifics. We don't have system prompts, instruction architectures, or configuration details to share. What we do have are two distinct approaches that illustrate different ways people thought about the assignment.

Shivani's approach: meeting notes as knowledge source. Shivani used Granola, an AI meeting note-taking tool, as her primary source material. She uploaded notes from client calls and internal project alignment meetings. Her GPT ingested client problem statements and discussion context. She described her goal as building a "360-degree role view." We don't know how far she got toward that goal. We don't know what her instruction set looked like or how she structured the knowledge files. What's clear is the source material decision: she reached for artifacts she was already generating rather than writing new documentation for the GPT.

Deepshikha's approach: a narrow agent concept. Rather than building a broad role assistant, Deepshikha used the custom GPT's sandbox feature to prototype a specific idea: an agent that could surface customer marketing signals from company-wide Slack channels. She treated the sandbox as a design space for a focused detection problem. We don't have details on the agent's logic, what constituted a "signal," how Slack data would flow into it, or whether the concept moved beyond prototyping. The approach itself is the interesting part: she used the assignment to explore a single high-value use case rather than attempting comprehensive role coverage.

These two directions captured something useful. One person encoded broad context from existing work artifacts. The other designed a narrow tool for a specific problem. Both started from the same assignment. Neither approach has documented outcomes we can point to.

What the process showed us

We should be honest about what we know and don't know here.

What we can say: All seven people completed the assignment. The individualized approach forced real engagement in a way that a shared tool rollout would not. You can ignore a shared tool. You can't ignore an assignment to build something yourself. Every team member had to decide what knowledge to include, what workflows to prioritize, and what their assistant should actually do. That decision-making process was itself a form of learning.

What we can also say: Source material mattered more than platform features. Shivani's GPT was only as useful as the Granola notes she fed it. Deepshikha's agent concept was only as sharp as her understanding of the signal detection problem. The custom GPT builder is not complicated. Identifying what knowledge is worth encoding is.

What we can also say: Lightweight accountability worked for completion. The team lead ran this through Slack. No project management tool. No formal tracking. Direct messages, public check-ins, and a clear deadline. Everyone delivered.

What we cannot say: Whether these GPTs are still in use. Whether any of them meaningfully changed how someone works. Whether the quality of anyone's output improved. Whether the "AI Partner" framing held up past the initial build. We don't have usage data, iteration history, or productivity metrics. Completion is not the same as adoption. We know the build happened. We don't yet know if it mattered.

What you can take from this

If you're leading a team and want to move past generic AI adoption, the "build your own" model has one clear advantage: it forces people to articulate what they actually do and what knowledge matters in their role. That exercise has value regardless of whether the resulting tool gets used daily.

Start with whatever knowledge artifacts people already produce. Meeting notes. Client briefs. Evaluation frameworks. Those are your inputs. The platform is secondary to the specificity of what you feed it.

Keep the accountability human-scale. A Slack message asking "where's your link?" worked for driving completion across a seven-person team in ten days.

But don't mistake completion for transformation. We made that mistake in how we initially talked about this internally. Building a thing and using a thing are different. If you run a similar program, plan the follow-up before you plan the workshop. The build is the easy part.

We're figuring out AI fluency inside our consulting teams — not perfectly, but in the open. If you're navigating similar questions, let's compare notes.