Tonight is where it gets personal
Everything so far was about agents in general. This session is about your processes, your vendors, your team. We apply three tools in order: the when-to-build criteria as an org-scanning lens, a build-buy-wait decision table, and a use-case scan workshop you can run with your leadership team next week. Session 6 closes the track with the roadmap.
The three criteria, applied 15 min live
OpenAI's guide gives three signals that a process is worth an agent: complex decision-making, difficult-to-maintain rules, and heavy unstructured data. In session 1 those were a warning about when not to build. Tonight they become a lens: walk your org chart, hold each process up to the three filters, and see what survives. Most processes will not - and that is the point.
LiveThe criteria on real departments6 min▶
The three criteria stop being abstract the moment you attach a department to each. These are the guide's own flavor of examples, translated to a walk down your hallway:
- Complex decision-making → support refunds. "Approve this refund?" depends on customer history, tone, order context, goodwill. A rulebook that captures all of it does not exist; a person with judgment does - and so can an agent with the right tools and guardrails.
- Difficult-to-maintain rules → vendor security reviews. The checklist grew for years; every exception spawned three more rules. Each policy change is now a risky edit to a forest nobody fully understands. Agents shine exactly where rulebooks rot.
- Heavy unstructured data → claims processing. The task swims in PDFs, photos, emails, and phone notes. Structured systems only see the 20% that fits their fields; an agent can actually read the rest.
Run the lens honestly and most of your org falls out of the funnel. That is a success, not a failure - it protects your one pilot from competing with forty half-ideas.
Self-studyThree scan anti-patterns to avoid3 min read▶
The scan fails in predictable ways when it runs backwards. Watch for these in your own workshop:
- Solution-first scanning. "We have budget for an agent - find it a job." The criteria exist to disqualify, not to justify. If every task somehow passes, the room is scoring the budget, not the work.
- Scanning for headcount instead of judgment. The criteria point at judgment-heavy, rule-rotted, document-soaked work - not at whoever's team looks most expensive. Tasks picked by cost alone tend to fail the filters quietly later, in production.
- Treating the shortlist as a commitment. Surviving the funnel earns a task a four-lever spec, nothing more. The build-buy-wait call and the failure-cost weighing still stand between shortlist and pilot.
Anthropic's guidance is the antidote to all three: start simple, and add autonomy only where it demonstrably wins. "We could use an agent" is not a reason to.
Build vs buy vs wait 12 min live
Every survivor of the scan faces the same three-way call. The good news: after session 4 you already own the hardest question in the room - "show me your guardrails" - and it works on your own builders and on vendors alike.
| Path | When it is the right call | What to demand before committing |
|---|---|---|
| Build | The workflow differentiates you - it IS your edge - and you have engineering capacity to hold it: builders, an eval habit, tracing. | A four-lever spec and a golden set of real tasks written down before any code. No spec, no build. |
| Buy | The domain is commodity - generic support triage, meeting notes, standard document handling. Someone else's agent, your data. | Guardrail evidence: which of the seven guardrail types run, how tools are risk-rated, what triggers a human, and eval results on tasks like yours - not a demo. |
| Wait | Rules capture the task today. Deterministic code is cheaper, testable, and boring - and boring is a feature. | A revisit trigger: the day the rulebook becomes hard to maintain, the task re-enters the scan. |
LiveThe framework landscape in one breath4 min▶
If your team builds, they will pick from a small set of serious options. You do not need depth here - builder session 9 has the depth - you need the names and one honest line each, so vendor and team conversations do not fly over your head:
- Claude Agent SDK (Anthropic) - Python and TypeScript; ships with built-in tools, subagents, permission modes, and sessions, so guardrails are a setting, not an afterthought.
- OpenAI Agents SDK - five primitives: agents, handoffs, guardrails, sessions, tracing. The guide you have been reading all track is its design manual.
- LangGraph (LangChain) - agents as explicit graphs with checkpointing and human-in-the-loop interrupts; favored where teams want every step visible and resumable.
- crewAI / AutoGen - multi-agent team frameworks, each with its own DeepLearning.AI short course; strongest when the design is several cooperating agents.
The strategic point, ahead of session 6: teams that anchor on their own eval set can move between these; teams that anchor on a framework cannot.
Self-studyTeam readiness: what your builders need3 min read▶
"Build" is only real if the capacity behind it is real. Three honest checks before you fund a build:
- Python fluency. Every serious agent stack - Claude Agent SDK, OpenAI Agents SDK, LangGraph - meets your team in Python. If the team lives elsewhere, budget the ramp.
- An eval habit. Does the team already test with golden sets and track pass rates, or do they ship on vibes? An agent build without an eval habit produces demos, not systems.
- Tracing. When the agent misbehaves, can the team replay every step it took - each tool call, each result? If "we would check the logs" is the answer, the answer is no, not yet.
Missing one? That is a fundable gap, not a disqualifier. Missing all three? Buy or wait, and grow the muscle on the vendor's agent first.
The use-case scan + ROI framing 12 min live
Here is the whole session compressed into one workshop you can run next week with your leadership team. Ninety minutes, five steps, one output: a single pilot recommendation with its gate attached.
List candidate tasks. Thirty minutes, every department lead in the room, no filtering yet. "What eats your team's judgment time?" beats "where could we use AI?" - it surfaces real work instead of wishes.
Score against the three criteria. Each task gets a 0-3: one point per filter it genuinely hits. Zero-score tasks leave the room with a compliment and a recommendation for deterministic automation.
Write a four-lever spec for each survivor. One page: which tools it needs, what it must remember, whether it needs a plan, and what it must never do without approval. If the room cannot fill in the levers, the task is not understood well enough to pilot.
Weigh cost of failure against value of autonomy. A task that only drafts (low failure cost) can run more autonomously than one that moves money or emails customers. Plot the survivors; the honest picture usually surprises the room.
Pick ONE pilot and define its eval gate. One task, one owner, and a golden set of real cases the agent must pass before anyone widens its permissions. On budget: pilot with the most capable model to set the quality bar first, then right-size for cost once the gate passes - that is OpenAI's own model-selection recipe.
The pilot that got funded. Two teams pitched agent pilots to the same board. One showed a slick demo answering cherry-picked questions. The other framed theirs as "a 12-task golden set drawn from real support cases must pass before rollout" - and showed the current score climbing as levers came on. The board funded the second one, precisely because it came with a built-in reason to say no. A gate is not bureaucracy; it is what makes "yes" safe to say.
Try it yourself - this week ◐ 45-60 min total
- Run the scan on your own org - solo is fine for a first pass. List ten candidate tasks, score each against the three criteria, and keep the top two or three.
- For each survivor, make the build-buy-wait call using Part 2's table - and write down what evidence you would demand on that path.
- Produce a one-pilot recommendation: the task, its four-lever spec (tools, memory, plan, approvals), and a golden-set sketch - eight to twelve real cases the agent must pass before rollout.
- Bring it to session 6: the roadmap will tell you what to fund around your pilot, and what to deliberately ignore.
Official sources covered
This track teaches the decision-maker's core of the canonical agent-building sources in business language. Certificates, videos, and graded assessments stay on the official sites (linked each session). This page covers:
Three questions before you go 🎯 ◐ 90 seconds
1 · Which three signals say a process might be worth an agent?
OpenAI's when-to-build criteria. Option B is the exact opposite - high volume with stable simple rules is the textbook case for deterministic code, which is cheaper and fully testable.
2 · A vendor demos an impressive support agent. What evidence do you ask for?
Demos show the happy path by design. Guardrail evidence and eval results on your kind of tasks show what happens off it - which is where every real incident lives.
3 · What makes a pilot gate a board can trust?
An eval set drawn from your real cases is the only gate that comes with a built-in reason to say no. Demos and vendor benchmarks measure someone else's happy path.