Becoming a Frame Evangelist

How do we teach an AI to stop being a stranger to your world and start acting like a member of your team? How do we move beyond generic prompting and start building Frames to capture our institutional knowledge?

								Various forms of questions like this have evolved and followed me during my internship at OpenTeams. As interns we were tasked to be Frame evangelists. We had the opportunity to meet with business units to learn their workflow and how Frames could benefit them in their daily work.								




							
								If you’ve used an AI assistant for real work, you know the failure mode: it’s confident, fluent, and subtly wrong about your world. It doesn’t know that “escalate” means something specific on your team, or that “DRAFT” carries weight, or which of two people is the point of contact. Depending on the model and harness, it can do a pretty good job, but it can also fill in the gaps with generic reasoning, which isn’t always wrong, just many times not what you need.
								A Frame acts as an architectural layer composed of three core components:

By treating context as an architectural layer rather than just “more prompting,” we solve three fundamental problems with AI:

								The important design choice is that Frames are human-readable and portable on purpose. They’re not buried in code. A person can open one, read it, disagree with it, and improve it. They’re created and improved from human expertise. That human expertise can then be shared and used across teams and projects in a Frame artifact.
							


								I began to understand Frames and their value as I worked with business units across OpenTeams to incorporate them into existing workflows. One of the most insightful parts of that process was seeing just how differently each team used AI. Some had automated nearly every part of their workflow, while others had barely used AI at all. Seeing Frames from their perspective changed how I approached adoption. Asking people to change a workflow that already works can be frustrating, especially when adopting something new requires time and effort before they’ve had a chance to see its value. My goal shifted from simply evangelizing Frames to first understanding how each team actually worked. I wanted to learn their workflows well enough to create Frames that solved real problems for them. Rather than asking teams to adapt their work to Frames, I began thinking about how Frames could adapt to the way they work.
							


								Everyone I worked with was kind and generous with their time, which is something I don’t take for granted, especially as an intern asking busy people to explain how they work. But what I noticed was trust didn’t come from having the right answer walking in the door. It came from being willing to try, being willing to engage in their work flow, and coming back for feedback.
							


								I created my first Frames working with the Project Success Team. While working with Project Success, I learned the process of iteration and discovered Frames earn their keep on judgement calls. AI models combined with Frames can produce more accurate results. Their value comes from the human expertise they’re created with.
							


								To understand Frames from the inside, I worked closely with my mentor on the Project Success Team to build a full pipeline of my own Frame, Cog, and Ops, a “project snapshot” that pulls a status picture together from a SOW and timesheet data. It didn’t work on the first try, but the ways it failed were the most instructive part.
							


								My first attempt failed because I overloaded the AI with too much information; it couldn’t distinguish between my example template and the task at hand. I learned that scoping matters. Although I thought there was good information in the Frame, being overloaded with context, the model didn’t produce reliable results.
							


								More iterations led me to rebuild the pipeline with a singular, driving mantra: eliminate duplication between the Frame, Cog, and Ops. I separated the concerns of each layer, treating the Frame as the dictionary and the cog as the writer, while pushing deterministic tasks like arithmetic and data parsing strictly into code. I focused on creating a system that was portable and ready for any project given the SOW and timesheet data. The workflow seemed to be producing accurate results for a project snapshot…now, were the Frames working?
							


								It was time to verify and test the Frames I created. With a working pipeline as my baseline, I ran multiple tests.
							




							
								From these tests, the snapshot’s numbers barely moved. The Frames were not influencing the result as I expected them to. For a while that felt like a failed experiment. Then it clicked: I’d moved the snapshot output to be almost entirely deterministic Python, CSV parsing, cells, the chart. Of course Frames didn’t change the numbers. Frames were never supposed to touch that part. The experiment didn’t disprove Frames; it located exactly where they don’t apply. If a formula can decide it (health < 90 or > 120 → flag), you don’t need a Frame. You need the formula. As much as my software engineering brain was telling me I could make a rule for every case, that wasn’t the answer. It clicked that Frames were needed to orient AI to make judgement calls the way I wanted it to. This realization shifted the Frames I was making.
								So I went looking for the judgement calls, and that is where Frames earned their place.
							


								I tested a health-review Frame and a monthly-report Frame on genuinely ambiguous questions, the kind with no formula. Ask “Delivery has been slipping for five weeks, the client hasn’t complained, should I escalate?” and the difference was stark: It wasn’t that without a Frame the answer was always wrong, it was that many times it was just generic. And generic isn’t useful when you need a judgement call.
							




							
								With the health-review Frame:
								I saw the same thing with SOW role Frames: seven role-specific Frames plus one full-role Frame caught more specific, OpenTeams-relevant risks than the no-Frame runs, which caught real risks too but in a blander, less situated way.
							


								Once I realized that Frames excelled at resolving ambiguity, I sought out other tasks where judgment was the primary driver. Contract-discrepancy reviews were a perfect case for this; the work is complex and lives almost entirely in an experienced person’s head. A Frame turned out to be a way to capture that human expertise to orient AI to conduct contract reviews the same way. A Frame would allow this information to be reused and shared. I could have used AI to generate a Frame for contract reviews, but it wouldn’t contain the value that a Frame has when driven by human expertise (I tried this and a Frame was created but of no value because it didn’t have the context that came from someone who actually does that job). A Frame isn’t AI configuration, it’s institutional knowledge, written down in a form both people and machines can use. It allows us to move beyond simple AI configuration and instead deploy codified organizational doctrine, capturing not just what an expert thinks, but the regulatory and operational guidelines they follow. This makes that intelligence durable, versioned, and usable across the entire organization.
							


								An honest lesson from this evangelizing was that the hard part isn’t writing the Frame, the hard part is capturing the expertise and adoption. A Frame only helps if the team whose knowledge it captures actually trusts it, uses it, and keeps it current.
							


								The lesson that stuck with me was about people. I saw how a Frame can capture how a real person on a real team already thinks, in a form their teammates could pick up and trust. The technology was the easy part. Getting a team to write its judgement down, and then actually rely on it, is the real work of an evangelist: supporting bridging the gap between expert intuition and AI execution. By making judgment consistent, portable, and accountable, Frames turn isolated “gut feelings” into shared institutional knowledge. That bridge between expert intuition and AI execution is where the real value lives, and that is what being an evangelist taught me.
							


								I am grateful to everyone I worked with during my internship. Special thanks to Mia Thurdekoos for her invaluable mentorship, and the many new tools and analogies that she shared with me. I also want to thank all those I collaborated with to build Frames. Finally, I’m appreciative of the entire Product Team, my intern cohort, and Inessa Pawson for fostering such a supportive and rewarding environment, which allowed me to grow in both skill and perspective.