[RECORDING] Activator Labs 101: Foundations

Activator Labs 101: Foundations

Event transcript

SLIDE 1 — Activator Labs 101: Foundations

Kenna:

Welcome to Activator Labs 101: Foundations.

[INTRODUCTIONS]

This is an instructive working session for Agent Activators: the AI champions who own or materially shape recurring work operations for teams. Agent Activators coordinate the people, systems, requirements, and controls needed to move a workflow from a useful idea into responsible operation. Some build directly; others configure an approved solution or coordinate with technical partners.

We asked you to bring one recurring, multi-step workflow your team or function already performs to today’s session. Today, you’ll learn a repeatable method for moving that workflow from its current process through a safe, reliable AI workflow build and into responsible operation. You’ll leave with clearer workflow decisions and next steps to validate with the workflow owner, intended users, and the right technical or governance partners.

TRANSITION: Here’s how we’ll use our time today.

SLIDE 2 — Today

Kenna:

We’ll start by validating that you have a valuable, scoped workflow to work with, and then you’ll learn the three Agent Activator capabilities and see how they’re applied in practice with a shared example. You’ll use the same method to decide what to work on next in your own workflow throughout the session. Keep your real workflow in mind throughout the session today.

TRANSITION: First, let’s orient to the role Agent Activators play in the wider AI transformation effort.

SLIDE 3 — Three roles connect AI strategy to team workflows

Kenna:

Champions influence AI transformation in a few different ways.

Exec Sponsors set direction and create the conditions for change. Transformation Leaders deploy by building the plans, systems, and governance needed for adoption at scale. Agent Activators reimagine recurring work for a team or function.

These responsibility may sit under different roles or titles. Think of them as different ways of influencing adoption. Today, we are focusing on the Agent Activator role.

TRANSITION: Let’s make the Agent Activator role more concrete.

SLIDE 4 — What Agent Activators do

Kenna:

Agent Activators are close enough to the work to understand how it actually operates. They see the process, people, systems, exceptions, friction, and outcome that matter, and own or materially shape those operations.

The difference between an Agent Activator and an individual power user is accountability for a team or function. A power user may improve their own work; an Agent Activator helps create workflows other people can use and the organization can sustain. They may build directly, configure an approved solution, or coordinate with technical partners.

That work has three parts.

Activators design AI workflows with defined processes, boundaries, and outcomes. They translate those designs into concrete requirements and develop safe, reliable, connected AI workflows that can be tested and improved. They operationalize AI workflows responsibly across teams and functions by embedding the workflow into existing team operating rhythms and maintaining, improving, repurposing, or retiring workflows over time.

TRANSITION: Here is what you will practice today.

SLIDE 5 — Activator Labs 101: Foundations

Kenna:

I’ll explain the repeatable method for designing, developing, and operationalizing AI workflow solutions. Michael will demonstrate each capability through a shared example. You’ll use the same method to start working through the real workflow you brought.

You are not expected to complete every step today or produce a production-ready AI workflow solution today. The Activator Labs participant workbook is designed to help you start gathering the necessary information, identify the next important decision, and who needs to help validate it.

TRANSITION: This session is one part of OpenAI’s broader Agent Activator learning track.

SLIDE 6 — The Agent Activator learning path

Kenna:

Activator Labs 101 is the foundation: learn the capabilities, start applying them to a real workflow, and walk away with a repeatable method you can use again.

Participating in today’s live session earns you the Activator Labs Foundations badge.

After today’s, keep working your workflow. You can use the assets in the Champion Community on OpenAI Academy to help you through each step.

When you have applied the method, share your work in the Champion Community.

An Activation Challenge submission that demonstrates a real team or functional workflow that you designed, developed, and operationalized, with credible evidence of value earns you the Agent Activator badge.

TRANSITION: We’ll begin by choosing work that is valuable and ready for AI transformation.

SLIDE 7 — Choose a valuable, feasible first workflow

Kenna:

You were asked to bring one real, recurring, multi-step workflow your team already performs. Before committing to it, pressure-test it on two dimensions: impact or value, and complexity or effort.

Impact asks whether improving the workflow would create a meaningful result. Consider frequency, repeatability, reach, visibility, and downstream consequences. How often does it need to be completed? How many people complete it? What decisions or work does its output impact downstream?

Complexity asks what it will take to make the workflow reliable. Inconsistent inputs, unclear ownership, many dependencies, sensitive information, high-consequence actions, heavy governance, or numerous exceptions all increase effort and risk.

A good starting point combines meaningful value with manageable effort. It does not have to be trivial. It needs to be worth doing, and realistic enough to test responsibly.

Use the matrix to decide whether to keep the workflow you brought today as scoped, narrow it, or choose a different starting point. A valuable but complex workflow may need a narrower first scope, or more sponsorship, standardization, and coordination. Lower-value improvements can wait, especially when they also require high effort.

TRANSITION: Michael will show how we narrow a broad opportunity into a testable first workflow, and introduce the example we’ll use throughout the session today.

SLIDE 8 — Example: AI-assisted request intake

Kenna:

Our shared example is an AI-assisted request intake. This flow usually looks like: a request arrives, the team reviews the information, categorizes it, and either responds or assigns an owner.

At full breadth, that workflow can span many different request types, channels, systems, rules, owners, exceptions, and approvals. In this case, if our workflow is expansive, it may be valuable, but it is too broad and complex for a responsible first build.

So it can be helpful to narrow it by looking at three things.

First, where does most of the variation come from? If you hold one request type, user group, or input channel constant, that can make the workflow easier to define and test.

Second, look at where the consequences of error are highest. Cases with sensitive, customer-facing, urgent, high-importance, or difficult-to-reverse decisions usually need a pared-down first scope, stronger human review, or both.

Third, try to think about which dependencies can be avoided. Having one approved channel, one criteria set, one existing system, and one accountable owner reduces things like integration effort and ambiguity.

So, for this example, let’s assume we’re going to work with routine internal requests from one pilot team submitted through its existing structured intake process. The intake form requires the minimum routing information and creates a traceable record in a shared request queue. The scoped process also requires an intake lead to review and approve a request before it can be assigned to an owner.

That first scope help us holds the main sources of variation and integration effort constant.

You can also feel good about the scope of your workflow when you can clearly identify the inputs and outputs, manageable exceptions and dependencies, an accountable owner, realistic approvals, and that it has enough scope to produce a useful result.

For your workflow, ask: What creates the most variation? What would matter most if it went wrong? Which cases need tighter review? Which dependencies can you hold constant? Name what is inside the first scope and what remains outside it.

TRANSITION: With a workable first scope, Kenna will introduce the repeatable method.

SLIDE 9 — The method is repeatable

Kenna:

The repeatable method breaks down each of the three capabilities into three steps. Each stage resolves different questions and produces the inputs for the next decision.

In Design, we map the current process, define the intended outcome and scope, and decide what AI may support versus what people retain responsibility for. Its output is an agreed workflow design that defines what the workflow must accomplish and the boundaries within which an AI workflow solution can be developed, not an early tool or technical design.

In Develop, you’ll translate that design into requirements for approved tools, data, connections, permissions, sources, AI behavior, and human review. You’ll then build or coordinate and test the solution across representative real-work cases. The output is a proven AI workflow solution that is safe, reliable, connected, and ready to be operationalized.

In Operationalize, you’ll embed the workflow into existing work, prepare and support its intended users, measure its impact, and define ownership for maintaining the workflow over time. The output is a workflow the intended team can use and sustain, with clear ownership and evidence of value.

In every stage of this process, Agent Activators coordinate this work and make recommendations. Workflow owners; relevant business, technical, and governance stakeholders; and Transformation Leaders retain authority over material changes.

The method is repeatable, but the resources are adaptable. We’ve shared the Activator Labs Participant Workbook, and other resources which all live in the Champion Community to support you, but the decisions we make today may live in your organization’s approved brief, ticket, checklist, SOP documentation, or other format. Use whatever artifact works best for your team.

TRANSITION: Design begins with the work as it happens today.

SLIDE 10 — Design AI workflows

Kenna:

Strong Agent Activators begin with the work, not the tool.

Keep your real workflow in view. Ask what happens today, and what better outcome the AI workflow solution can produce, before selecting specific capabilities.

If you’re comfortable sharing in chat, I’d love to know what teams and recurring workflows you own or support, and the kinds of results you’re hoping to improve!

TRANSITION: Start by connecting the current workflow to a measurable better state.

SLIDE 11 — Map the workflow, then define the outcome

Kenna:

To map the current work, capture the triggers, inputs, steps, decisions, handoffs, outputs, and places where work waits, loops back, or requires judgment. Document how the team completes the work today; do not choose tools, integrations, or permissions for a better solution just yet.

Mapping often reveals ambiguity that people have been silently managing through experience., and that’s not failure: it’s useful evidence. If the ambiguity is bounded—a missing input, known exception, avoidable loop, or unclear handoff—name it. The team may simply need a standard for complete work or a defined exception path. If the inputs, criteria, and ownership are broadly inconsistent, narrow or standardize the scope of the workflow before continuing.

Then define the desired outcome: the better result the workflow should create for the team or its users. State it in plain language without prescribing an AI feature. Describe faster routing with less rework, for example, rather than “build an automated routing agent.”

The workflow map gives us the current operating reality. The outcome gives us a stable standard for judging whether the future workflow is actually better.

TRANSITION: Next, make the AI and human boundaries explicit.

SLIDE 12 — A recommendation is not the same as decision authority

Kenna:

To decide where AI and human boundaries belong, work through the workflow map step by step.

AI may complete a step when the work is repeatable and bounded, inputs and acceptable outputs are clear, and the result is easy to check or reverse.

AI may prepare or recommend when a person should review the result, retain decision authority, or approve an external action.

People must own ambiguous, sensitive, high-impact, policy-required, or difficult-to-reverse decisions.

For each AI-supported step, define the operating boundaries. What approved information may it use? What output or action may it produce? Who may access or review the result? Where must a person approve before it continues? When must it stop, ask, or escalate, and who owns the handoff?

Even when AI completes a step, a person remains accountable for the workflow. Human review is especially important when a decision changes priority, access, rights, commitments, or scope, or when the workflow acts externally.

The goal is to make the AI role, the human role, and the fallback path explicit before building. That gives the team a design it can translate into requirements and test cases without allowing the AI role to expand during implementation.

TRANSITION: Michael will apply the Design decisions to our shared workflow.

SLIDE 13 — Design in Practice

Michael:

In the Design step, we decide how the workflow should operate—not necessarily which product feature to turn on first.

I’ll also just call out here that ChatGPT Work could be a likely implementation path for this audience because it can take on recurring, multi-step work, and approved apps and plugins may provide context or support actions. But those are implementation hypotheses. Design first establishes the process, outcome, scope, and boundaries that tell us whether and how those any of those features should be used.

Let’s revisit the scope we talked about in the first example: routine internal requests from one pilot team submitted through the approved form and recorded in the shared request queue.

If we’re thinking about the first step, the trigger for the workflow would be the form submission. The team reviews the information, categorizes the request using its existing criteria, and then reviews the category and assigns an owner or queue. The current categories and routing criteria aren’t changing; you don’t want to be redesigning the operating model and testing AI at the same time.

If a request cannot be routed with the available information, the team clarifies it or handles it during a standing exception review meeting.

The form fields, routing criteria, owner directory, urgency definitions, and escalation policies are the current inputs and sources of truth. And in the first version, we’d want to avoid having our tool search through email, chat, CRM, or other repositories for additional context if that’s not already part of the existing process.

The points of friction will also probably be visible here: missing or conflicting inputs, sensitive or customer-facing requests, urgent or high-consequence requests, and requests outside the routine scope.

Again, our desired outcome is: requests reach the right owner faster, with enough context to act and less avoidable rework. That describes a better result without prescribing a feature and remains the standard for later decisions and evidence.

TRANSITION: Now let’s overlay the AI and human boundaries on the same workflow.

SLIDE 14 — Design in Practice (continued)

Michael:

Here we want to determine what AI can do, what people must own, and where the workflow ultimately stops.

If we think first about a routine request in our workflow, with complete and consistent information, we’ll allow AI to apply the current routing criteria and prepare a category, proposed owner, and rationale.

The Intake Lead sees the original submission and reviews that recommendation. They may approve it, edit and approve it, reject it, or escalate it. Only explicit approval permits the workflow to assign the approved owner or queue. People retain responsibility for changing urgency or communicating with the requester.

Anything like missing or conflicting information pauses the workflow and we should be explicit that we don’t want AI to infer a required value. Sensitive, customer-facing, urgent, high-consequence, or out-of-scope requests stop and move to the human-owned exception path.

The AI in this workflow must not change approved criteria, assign before approval, change priority, or communicate externally.

These decisions later determine how ChatGPT Work and any approved apps or connections are configured: which information they may use, which output or action they may prepare, where the workflow must wait for a person, and which conditions prohibit further action. We want our AI to implement our boundary but not define the boundary for us.

The Design result is concise: AI prepares a route recommendation; the Intake Lead approves; the workflow assigns only after approval.

TRANSITION: Now we can move to the Develop step where we’ll turn our decisions here into a working contract and tested first version. (back to Kenna)

SLIDE 15 — Develop safe, reliable, connected AI workflows

Kenna:

Develop begins with the agreed workflow design and turns it into a working, tested solution.

Define requirements and controls so the design is concrete in the team’s real environment. Build or coordinate the solution using approved tools, data, connections, and permissions. Then, test representative real-work cases, likely failures, and required human review.

The output is not a requirements document or a one-time demonstration. It is a working, tested AI workflow solution that meets the agreed requirements, performs safely and reliably across representative cases, and is ready to be operationalized.

If you can share in chat, we’d love to hear some of the real cases or conditions the workflows you’re building must be able to handle correctly before they can earn your team’s trust.

TRANSITION: This stage starts with defining the working contract.

SLIDE 16 — Specify requirements for the AI workflow

Kenna:

Specifying requirements turns the validated Design into a working contract: what the first useful version must do, what it may use, where it must stop, and what people need to build, test, approve, operate, and support it.

The starting inputs are the workflow map, desired outcome, first scope, and AI and human boundaries from the workflow design. Requirements make those decisions concrete enough to implement in the team’s real tools, systems, policies, and operating conditions.

This should be collaborative work. The workflow owner, intended users, information and system owners, technical partners, and leadership must validate the parts of the workflow within their expertise and authority. Involve Security, Privacy, Legal, IT, or Governance when the proposed data, systems, integrations, or actions require them. Agent Activators coordinate these decisions; they do not need to make them alone or outside their authority.

Start in the center of the visual with required and prohibited AI behavior. State what the workflow must do within scope, and what it must not do.

That behavior allows you to define the boundaries.

Start with the information boundary. Specify only the inputs, rules, and context necessary to produce the approved behavior. What minimum information is required to complete each step? Name why that information is needed, the approved source, the access required, the owner responsible for keeping it current, and any information or sources the workflow must not use. The question is not what you could connect; it is what this workflow actually needs.

Then define the technical boundary: the minimum capabilities, systems, integrations, records, and permissions required. Every additional integration, permission, or action adds effort and increases the consequences of error. Be specific about whether the workflow may read information, write a draft, update a record, execute an action, or communicate. Name the tool when the organization’s environment or the requirement depends on it.

Then, make the human boundary operational. Specify the conditions that pause the workflow, who must review and approve, how they record their decision, and how each decision affects what the workflow may do next. Also name who owns, maintains, and supports the workflow after the build.

The risk lens applies across every layer, and great Activators embed risk mitigation controls into the build itself. Higher sensitivity, the severity of consequences of error, and lack of reversibility may require narrower information access, fewer permissions, an earlier human checkpoint, or a smaller scope.

Your working contract is concrete enough when your or the builder can implement it without inventing operating decisions, and stakeholders understand how it will be operated, supported, and changed.

A requirements document is one possible container to record these decisions. The essential output is the coherent set of decisions that becomes the build checklist, test standard, and decision record.

TRANSITION: Those requirements define what working means. Testing determines whether the build behaves as intended.

SLIDE 17 — Test representative real-work cases

Kenna:

Testing determines whether the workflow behaves as required under the conditions that matter.

Begin with the expected behavior, acceptance criteria, and appropriate reviewers. Intended users can judge whether the output is useful in practice; workflow, technical, data, or governance owners can review behavior within their expertise and authority.

Build a deliberate case set using frequency and risk. Include the routine, high-frequency path; meaningful variation within the approved scope; missing or ambiguous information; and high-consequence or out-of-scope conditions. The goal is to test both normal performance and safe behavior at the workflow’s boundaries, not to create a bunch of copies of the happy path.

Use the same Review → Compare → Decide cycle for every test case.

Document the input and the actual output or action.

Compare the actual behavior against the requirement and acceptance criteria. Did the workflow use approved information, stay within permissions, and respect the human gate?

Decide if the test passes, requires changes, or you need to stop and escalate.

When a case misses, isolate the cause. Change one requirement or build choice at a time, then rerun the failed case and nearby variations so you know what fixed the issue and whether the change created a regression.

Testing produces a documented evidence set: what passed, what changed, known limitations, and whether the workflow is ready for rollout within the approved scope. It supports a readiness recommendation; it does not prove perfection.

TRANSITION: Michael will apply the complete Develop sequence to our shared workflow.

SLIDE 18 — Develop in Practice

Michael:

OK, let’s carry forward the scoped workflow, desired outcome, and AI and human boundaries from our Design step. Now we’re going to make the requirements decisions that turn that design into a working contract.

Our working product hypothesis is to use ChatGPT Work, supported where appropriate by approved OpenAI features, apps, or connections. One key callout I’ll make here is that the contract determines which actual features belong in the solution; but feature availability should not expand the approved scope.

It can be helpful to start with required and prohibited behavior. For an eligible request, for example, the workflow must validate the required fields, apply approved routing criteria, and draft a category, proposed owner, and rationale. It then pauses. If the Intake Lead approves—or edits and approves—the workflow assigns the approved owner. Rejection or escalation produces no assignment.

Prohibited behavior would be something like inventing missing details, changing routing criteria, assigning an owner before approval, changing urgency, or contacting the requester.

That behavior defines the information boundary. The workflow needs the required request fields, current routing criteria, and indicators that identify sensitive, urgent, customer-facing, high-consequence, or out-of-scope requests. It needs enough information to recognize its boundary, not the information required to perform work outside its scope. For example, it does not search email, CRM, or other repositories when approved information is missing or conflicting.

Next, translate the boundary into minimum technical access. In ChatGPT Work, that could mean approved instructions and structured outputs, read access through an approved app or connection to eligible request records and routing criteria, and permission to write a draft into designated review fields. The product should receive only the access required for this workflow.

The workflow must capture the Intake Lead’s explicit decision and only approval permits the final assignment. It does not need permission to edit original request details, change criteria or urgency, delete records, or communicate externally.

Then make the human boundary operational. The Intake Lead sees the original submission beside the draft outputs and may approve, edit and approve, reject, or escalate. Rejection or escalation produces no automated assignment and sends the request to the existing human-owned path.

The risk lens shapes the contract. A routine internal misroute is usually correctable, so AI may prepare a recommendation while approval remains human. A sensitive customer-facing request carries more serious consequences, so the responsible requirement is to recognize it, stop, and escalate—not to grant broader access.

When behavior, information, technical access, human decisions, and risk responses fit together, a builder should be able to implement the sequence without inventing operating decisions.

Testing follows from the same contract - to test your progress, use approved old or closed requests, anonymized examples, or synthetic examples built from approved patterns.

Routine cases verify the normal path. Meaningful variations change in-scope details. Missing or ambiguous cases verify the ask-don’t-infer rule. High-consequence and out-of-scope cases verify stop and escalation. Test approval, edit and approval, rejection, and escalation so assignment occurs only in approved states.

Run every case through a three step check: Review → Compare → Decide.

“Review” records the workflow version, input, actual result, and reviewer—including whether ChatGPT Work stopped, waited, escalated, or acted.

“Compare” checks the result against the historical norms: approved information, minimum permissions, human gate, and expected behavior.

“Decide” records whether the AI in each case gets a pass, if a change is needed, or we need to stop and escalate. When a case misses, identify whether the requirement or implementation failed, change the relevant decision, and rerun that case and nearby variations. If the result exposes unacceptable risk or a flaw in the approved scope, stop and involve the accountable stakeholders.

The Develop output is a working, tested AI workflow solution that meets the agreed requirements, performs safely and reliably across representative cases, and is ready to be operationalized.

TRANSITION: We’ll assume the evidence supports a bounded introduction. Kenna will show how Operationalize prepares the tested version for use without expanding its approved scope.

SLIDE 19 — Operationalize AI workflows responsibly

Kenna:

Operationalize makes a tested workflow usable and sustainable for its intended team.

This does not make the Agent Activator solely responsible for organization-wide adoption. They coordinate the work, support users, synthesize evidence, and recommend next steps.

CHAT CHECK-IN: If you’d like to share in chat, we’d love to hear about where the workflows you’re reimaging fit into your team’s work!

TRANSITION: Let’s unpack the approach.

SLIDE 20 — Embed, support, measure, and improve

Kenna:

Repeatable means an intended user can perform the workflow consistently, and the organization can own, support, change, and (if appropriate) retire it responsibly.

The AI workflow package serves both purposes.

For intended users, name who should use the workflow and within what scope. Provide the repeatable steps, reusable resources, limitations, exception paths, and human review gates. A user should be able to recognize when to use the workflow, complete the normal path, and know when to stop or seek help.

For the organization, name the authoritative sources and current versions the workflow depends on, the accountable workflow owner (even if that’s you), and the support and feedback channels. These are not administrative extras. A source or routing rule may change, questions may expose a recurring gap, and someone needs to keep the workflow fit for use.

Add governance and lifecycle guidance: what triggers review, who evaluates and approves changes, and how changes are recorded and communicated. Common triggers might include a policy or source change, repeated boundary failures, a tool migration, unsustainable support needs, or evidence that the workflow no longer creates enough value.

The package is ready when a new intended user can perform the workflow safely without relying on its creator, and a new owner can maintain it without relying on its creator.

Then, introduce the workflow in real work. Place it in the tool, request, meeting, or cadence where intended users already perform the task. Show a routine case and an exception so users see both the normal path and the boundary. Then support a guided first use with real work to make the value visible. Reinforce where human judgment remains required and provide a route for questions and feedback.

Finally, measure evidence against the agreed outcome and scope. Usage alone is not impact.

Outcome or value asks whether the meaningful team result is moving. Quality asks whether the workflow is accurate and useful. Safe operation asks whether approvals, boundaries, and exception paths hold. Use and friction show whether intended users can repeat it and whether the organization can support it reasonably.

Use that evidence to answer four questions: Is there value? Is the result reliable across meaningful variation? Are the controls holding? Are users and the organization ready for the next context?

Those answers support a Stop, Revise, or Expand recommendation. Stop when value does not justify continued use or risk is unacceptable. Revise when value is promising but gaps remain. Expand only when value, reliability, control, and readiness all hold. Activators can make this recommendation both after introducing the workflow to a pilot group AND when a change triggers review.

The Agent Activator’s role is to bring forward the evidence, their recommendation, material tradeoffs, and required changes. Transformation Leaders and leadership stakeholders approve further investment.

TRANSITION: Michael will show how bounded evidence leads to a recommendation.

SLIDE 21 — Operationalize in Practice

Michael:

In the Operationalize step, I use the work already completed rather than recreating the package from scratch.

The workflow map supplies the sequence for our standard operating procedure. The working contract supplies the approved inputs, behavior, permissions, human gates, limitations, and fallback paths. The test cases become routine and exception examples. Named owners and review triggers become the support and change-control model.

For ChatGPT Work, the package should make the implemented workflow understandable beyond its creator: what the workflow does, who may use it, which approved instructions, sources, apps, or connections it relies on, where human review occurs, and who owns access, support, maintenance, and changes.

The workflow map also shows where to introduce it. In our recurring example, we might use the Tuesday request-review meeting. We show one routine case and one exception, then support each reviewer through an eligible request. The workflow owner reinforces the approval boundary, and the existing help channel captures questions and feedback. ChatGPT Work becomes part of the existing operating rhythm rather than a separate AI activity.

After some reps with bounded use, interpret the output evidence through four questions. Is there value? Is the result reliable across meaningful variation? Are the controls holding? Are users and the organization ready for the next context?

Is there value?: Maybe the time to a review-ready request fell from eighteen minutes to eleven. That could be promising, although the sample size is a bit too small for us to know whether this is a durable effect.

Is the result reliable across meaningful variation?: if twenty-seven of thirty-six recommendations were accepted, but we’re seeing a lot of overrides from the system, that might suggest a systematic gap in a routing rule, source, requirement, or implementation.

Are the controls holding: if we see that no assignments occurred before approval, that would be a good sign that we do. But even in the case that the workflow inferred missing information once, that would violate the contract and would need to be addressed.

Are users and the organization ready for the next context?: If we assume five of six people tried it and four returned, that might be a useful signal within our small sample size

Taken all together in this example, the answers to those questions would support a revision of this workflow —not a move directly to Expand. Value and repeat-use signals are promising, but the reliability pattern and boundary miss remain unresolved.

It would be a good idea to go make some changes, go through another round of tests, and after reviewing the data, the accountable owner can then decide whether the next version should remain bounded, stop, or expand.

That is the Operationalize discipline: make the workflow repeatable, place it in real work, and let those 4 questions around value, reliability, control, and readiness determine what happens next.

TRANSITION: Now choose the next unfinished decision for your own workflow.

SLIDE 22 — Choose one next decision for your workflow

Kenna:

Use the next few minutes to find the next important decision that needs to be made for the real workflow you brought today. Do not try to complete the entire method.

If the workflow, outcome, or AI and human boundaries remain unclear, work in Design.

If the Design is clear but the requirements, first build, or representative tests are incomplete, work in Develop.

If the workflow has been tested but is not yet packaged, introduced, or measured, work in Operationalize.

Our resources can help, but they are not the assignment. Feel free to use your organization’s preferred format if it answers the same questions.

In the next few minutes, capture the next concrete decision or question. Name the person who can validate it.

[FACILITATOR: Allow approximately three minutes. With thirty seconds remaining, prompt attendees to name the next person.]

SLIDE 23 — Keep applying the method

Kenna:

Before we jump into Q&A: Congratulations! Your participation throughout the complete live session today earns you Activator Labs Foundations badge. Attendance is verified after the session, so you’ll receive the badge on your OpenAI Academy profile in the coming days.

Keep working your workflow! Leverage the resources in the Champion Community on OpenAI Academy if they’re helpful.

When you have applied the capabilities in practice, share your work in the Champion Community forums! Of course, you should always follow your organization's information security and privacy policies, but we would love to see what you build, who it supports, and the value or improvement it drove for your team! We’ll also review submissions and grant the Agent Activator badge to complete examples. If it’s okay, you may even be invited into a deeper case-study, but that’s not required for the badge.