The OOO Connect Summit is a two-day experience this year it was hosted in New York City built around four pillars: Culture, Community, Career, and Commerce.
The morning keynote came from Ty Heath, Global Director of Thought Leadership GTM at LinkedIn. The afternoon included a keynote-style conversation with Richelieu Dennis of Sundial Media and two technical workshops led by X.Eyee, a former Microsoft and Google engineer who now works on AI policy and legislation.
A single thread ran through my favorite sessions: who controls the systems that describe, amplify, and ultimately shape outcomes for people and organizations. It showed up in a conversation about media ownership, a conversation about philanthropic capital, and two deep technical sessions on AI architecture.
Before I share a few highlights from my notes from the OOO Connect Summit, I’d be remiss if I didn’t praise the organizing team and founder Chanise Robinson for a job well done.
I’ll start with the end, the closing fireside chat with Richleau Dennis of Sundial Brands
“Stay in the pocket, run the play."
Richelieu Dennis made an argument that most leadership conversations avoid because it requires naming something uncomfortable about how organizations respond to public pressure. When your strategy reforms itself in response to every criticism, you end up serving the critics, not the community the organization was built for. That distinction sounds simple. It is not.
He used his own company as the example, a company that competes against a near-monopoly for the same talent and audience. The pressure to respond, to pivot, to prove you heard the room, can feel like leadership. He called it what it is: distraction. His phrase was "stay in the pocket, run the play." The play you drew up when you had clarity, not the one the loudest voices in the room are demanding.
The question worth sitting with is whether the feedback you're receiving is coming from the people you built for, or from a room that was never your audience.
Consumer or Supporter: The gap is not a different standard. It is a different starting line.
Richelieu made a more precise diagnosis than the one that usually surfaces in this conversation. He was responding to a direct question about Essence Festival relative to other major music festivals and whether Black-owned businesses are held to a higher operational standard.He was responding to a direct question about whether Black-owned businesses are held to a higher operational standard.He said the problem is that the infrastructure required to meet the standard was never equally distributed. Capital scarcity, expertise gaps, and generational disadvantage warp the measurement before the assessment even begins.
First-generation-led organizations get evaluated against institutions with decades of unrestricted capital, inherited networks, and accumulated operational knowledge behind them. He said plainly: if that is what you are doing as a consumer or supporter, you are a customer with expectations, not a partner with accountability. Those are different relationships, and they require different behavior and should be included in the higher standard debate.
For anyone working in philanthropy or directing institutional investment, this reframe changes what accountability conversations should actually measure. Applying the same performance benchmarks to a first-generation-led nonprofit as to a forty-year institution with seven-figure operational reserves is not rigorous evaluation.
It is a failure of contextual analysis, and it produces grant-making and partnership decisions that undermine the very capacity we claim to be building.
Shifting Gears, I was so inspired by the morning keynote that I built an AI Agent to integrate the CAR framework into my professional toolbox.
AI is already forming an opinion about you. The CAR framework is how you shape it.
Ty Heath opened the morning with a number that should recalibrate how every professional in that room thinks about their visibility strategy: 94% of buyers, hiring managers, and institutional partners consult a large language model before initiating direct contact. That statistic reframes the function of a professional reputation. Reputation is what a model retrieves about you when someone who has not yet met you asks.
Her framework for influencing that retrieval is CAR: Clarity, Authority, and Recency.
Clarity is how precisely and consistently your expertise is named across the indexed web. Authority is the depth and breadth of corroborating evidence that confirms the expertise claim. Recency is how current the signal is, because large language models weight the previous twelve months heavily when constructing a response about any individual or organization.
I was in the room taking notes when she introduced the framework and wrote down my own name next to those three words as a diagnostic. When I ran the audit, the result was specific: my negotiation background surfaces consistently across Claude, ChatGPT, and Perplexity. My philanthropic partnership work, the global dinner cultivation campaign across twenty cities, eight countries, and four continents, the 130% increase in donation rates, my leadership development practice across four continents, none of it appeared in the first-pass response any model generated about me.
That is a recency and anchor content problem and Ty handed me the fix.
Publish writing that names the expertise precisely
Build earned citations that confirm it
Do that work consistently enough that the indexed record reflects the full scope rather than the earliest chapter.
Among the owned channels available to most professionals, LinkedIn carries the strongest indexing weight with large language models because of its volume of structured professional data and its direct integration with Microsoft's AI infrastructure.
I spent 15 minutes using Whisperflow and my fave ai tool to crete an agent that adjusts my content strategy. One of the pillars of Ty’s CAR framework that we should all pay attention to is that publishing on LinkedIn is now an LLM positioning strategy, and requires different content decisions.
Ok, let's shift gears. X.Eyee's sessions were the most technically dense of the day and the immediately applicable.
You're still prompting. The people who will win this moment are building environments.
X.Eyee separated two terms the field is currently conflating and laid out the distinction in a way that both technical and non-technical professionals could apply immediately.
Prompt engineering is the practice of optimizing the instructions you give an AI model.
Context engineering is the practice of building the environment in which the model operates, pre-loading it with the right data sources, tools, output constraints, and quality checks before any individual instruction is issued.
The workflow difference is significant.
In a prompt engineering workflow, a professional downloads meeting notes, attaches them to a new conversation, and asks the model to produce a stakeholder update.
In a context engineering workflow, the model is connected directly to the relevant Google Drive folder, the project management system, and the established output template. The professional states the success criteria. The model retrieves the current data across those sources, formats it according to the template, and produces the output without the human performing any of the retrieval steps. The professional's judgment enters at the point of review, not at the point of assembly.
If your current workflow requires you to locate the file, download it, attach it, and re-explain the context every time you need an output, you have built a system where you are doing the retrieval and the model is doing the writing. The larger opportunity is building a system where the model does the retrieval and you direct the work.
Skills are the workflow architecture. Plugins are the data infrastructure that makes them run.
The technical architecture underneath context engineering has two components, and understanding both changes how you configure your tools.
Plugins are the authenticated connectors that give the AI model real-time access to external data sources: your document management system, email platform, payment processor, calendar, donor CRM, or any other service the model needs to pull from without manual file transfer.
Skills are the reusable workflow specifications that define how the model executes a particular task, every time it is triggered, without requiring a new prompt to re-establish the method.
The practical application for anyone in organizational leadership is this: any task you perform on a recurring basis, a weekly program briefing, a donor stewardship update, a pre-meeting research document, a grant progress summary, is a candidate for a skill.
The model writes the skill; you do not. What you contribute is a clear description of the workflow as you currently execute it, the inputs required, the output format expected, and the quality checks you would apply before distributing the result. Once the skill is built and the plugins are connected, triggering it requires a single command and produces a formatted output drawn from live data.
What requires your professional judgment, reading a donor relationship, designing a leadership intervention, building a case for philanthropic investment, should not be competing for calendar time with the assembly and formatting work a well-configured AI workflow can execute independently. That is the resource allocation argument X.Eyee was making, and it holds regardless of whether your work is in technology, philanthropy, or leadership development.
Vibe coding produces a prototype. The software development lifecycle produces a product. These are not the same thing.
The argument X.Eyee made in both the keynote and the breakout is not about technical skill level. It is about the gap between building something and deploying something that performs under real operational conditions with real users. AI handles the build phase of the software development lifecycle. It does not execute the planning phase, the design phase, the testing phase, or the maintenance infrastructure that keeps a deployed product functional and secure over time. When those phases are skipped or collapsed, the result is a product that performs correctly in a controlled demonstration and fails during deployment, often in ways that are expensive to diagnose because the planning and testing documentation was never created.
The three questions X.Eyee gave the room as the foundation of the planning phase were:
Who is this for
What should it do
Where do we start.
❝That third question is the one most builders skip, because the instinct is to build the full scope rather than the minimum viable scope that can validate whether the product solves the problem it claims to solve. The Scale AI example was instructive.
A company now valued in the billions began as a Google form and an SMS alert. No application, no registration system, no AI. The founders were testing whether people wanted what they were offering before investing in the infrastructure to deliver it at scale. The minimum viable version of a product is not the underdeveloped version. It is the version that generates the feedback required to justify the next investment.
If you have deployed something and never conducted a security review, that is the first task on your list.
Environment variables, the authentication credentials that authorize your application to communicate with Stripe, Supabase, OpenAI, or any external API, are being exposed in frontend code by builders who do not yet know that the client-side layer is publicly readable. Anyone with standard developer tools can retrieve them. X.Eyee was not speaking in hypothetical terms.
The diagnostic framework they provided maps to four architectural components. The database is where the application stores information over time.
(Let’s get AI Techy)
The backend is the coordination layer that manages authentication, authorization, and the logic governing how data moves between components.
The services layer contains the external APIs and third-party integrations the application depends on.
The frontend is the client-side interface that users interact with directly.
Security vulnerabilities most commonly appear in the authentication boundaries between these components, particularly where backend credentials are referenced in frontend code or where access controls are not enforced at the API layer. Running a structured security review against your codebase surfaces these exposures before a user or an external actor finds them.
Building in sequential stages rather than generating a full application in a single AI session reduces this risk significantly, because each component can be reviewed and tested before the next layer is added.
Shipping a product is the beginning of the operational responsibility, not the conclusion of the build process.
Error logging, usage analytics, and user feedback mechanisms need to be part of the initial deployment architecture, not additions scheduled for a future sprint.
What I kept hearing underneath the Culture, Community, Career, and Commerce framework at OOO Connect was a single question with different surface presentations: who gets to build, and who gets to own what they build? Richelieu Dennis asked it as a question about media infrastructure and philanthropic capital. Ty Heath asked it as a question about whose professional narrative gets surfaced when an AI model is consulted. X.Eyee asked it as a question about whether the tools people are building belong to them in any meaningful sense once they are deployed on platforms they do not control.
The organizations and professionals building owned infrastructure now, AI systems trained on their own workflows, content architectures designed for LLM indexing, platforms they control rather than rent, are accumulating a form of institutional capital that compounds. The ones still dependent on platforms they do not own are accumulating a form of exposure. The organizations that will have the most difficulty answering the ownership question in 18 months are the ones treating AI adoption as a tool selection decision rather than a strategic positioning decision.
I'm still actively applying what I took from OOO Connect, and I'll be writing more about that as it develops. The organizing team of OOO is a group to watch.
~ Jacqueline