Office Hours with Chanel presents

Decision Lab

AI strategy is a series of technical decisions disguised as business questions.

The interesting question usually isn't:

“What can AI do?”

It's:

What deserves to be built?
What should we buy instead?
How much authority should an agent have?
What happens when something changes three months after launch?

Decision Lab is a collection of interactive experiments showing how I think through those questions — what deserves to be funded, what should be built or bought, how much authority an agent should have, and what happens when the system eventually fails.

This is the strategy companion to my Build Showcase. That one shows what I can build. This one shows how I decide what deserves to be built — and how it should work.

Explore the experiments ↓See what I build →

Ex-Meta Software Engineer • Brown Computer Science • CS + Cybersecurity + AI Educator

AI strategy is not a straight line from idea to build

The decisions

Four questions I keep coming back to.

Each experiment starts with a real AI decision and turns it into something you can play with.

01Prioritization

The AI Draft

You have a limited AI budget. What actually deserves to get funded?

Eight departments want AI funding.

You have $250K.

Every proposal sounds useful.

Draft the company's AI portfolio, uncover hidden dependencies, consolidate overlapping tools, and decide what to fund, pilot, bend, fix first, wait on, or avoid.

Capital allocation
Prioritization
Organizational readiness
Technical capacity
Opportunity cost

Enter The AI Draft →Substack essay — Coming Soon

FUND

Support triage

PILOT

Sales research

BEND

Doc search

FIX FIRST

Data cleanup

WAIT

HR chatbot

AVOID

$250K allocated · 8 proposals · 3 shared dependencies

02Architecture

Build / Buy / Bend

You need the capability. You don't necessarily need to build the software.

A venture firm wants searchable institutional memory across founder meetings, CRM data, diligence documents, and investment history.

Should they build a custom platform?

Buy an enterprise product?

Or bend the tools they already own?

Change the business constraints and watch the answer change.

Build vs. buy
Differentiation
Ownership
Speed to value
Optionality

Make the Call →Substack essay — Coming Soon

BUILD

Own the capability

BUY

Use something mature

BEND

Extend what exists

Differentiation

Time to value

Team capacity

Recommendation: BUILD

03Autonomy

Blast Radius

How much power should you actually give your AI agent?

Build an AI Executive Assistant.

Give it access to email.

Then the calendar.

Then company files.

Then the CRM.

Then money.

Watch what happens to the consequences of one mistake as the agent gains more authority.

Permissions
Autonomy
Human approval
Reversibility
AI safety

Configure the Agent →Substack essay — Coming Soon

Blast radius: LOW

04Reliability

One Bad Tuesday

Your AI system worked perfectly for three months. Then Tuesday happened.

An AI diligence system looks healthy.

Then Drive permissions change.

A source URL breaks.

The model updates.

Someone edits the prompt.

The CRM stops syncing.

And the AI still produces a beautiful answer.

Follow the incident minute-by-minute and redesign the system so failure becomes visible, bounded, and recoverable.

Reliability
Observability
Model drift
Evaluations
Ownership

Start Tuesday →Substack essay — Coming Soon

System statusHEALTHY

9:17 AMDrive permissions change
9:41 AMSource URL returns 404
10:17 AMModel version updated
10:52 AMPrompt edited in place
11:26 AMCRM sync stops
12:47 PMBeautiful answer. Wrong.

How I think

My senior-engineer loop

The tools change quickly. The questions underneath them don't. Every Office Hours engagement and every project in this lab comes back to the same five steps.

01Frame

What job are we actually trying to do?

I don't start with: “What agent should we build?”

I start with: “What outcome are we trying to change?”

Reduce research time
Improve decision memory
Find trusted information
Remove repetitive work
Make a workflow more reliable

02Context

What does the system need to know?

Good AI outputs depend on good context. That includes more than prompts.

Data
People
Tools
History
Workflow
Constraints
Institutional knowledge

Missing context often becomes bad architecture later.

03Spec

What should this system actually be allowed to do?

The interesting design question isn't just functionality. It's authority.

READ
↓ RECOMMEND
↓ DRAFT
↓ ACT WITH APPROVAL
↓ ACT AUTONOMOUSLY

04Build or decide

What is the smallest sensible intervention?

BUILD
Own the capability.
BUY
Use something mature.
BEND
Extend what already exists.
PILOT
Learn before committing.
FIX FIRST
Solve the underlying dependency.
AVOID
Decide not to automate.

Not every AI opportunity deserves software.

05Trust

What happens when it's wrong?

The goal isn't to eliminate failure. The goal is to make failure visible, bounded, and recoverable.

Can we detect it?
Can we contain it?
Can we reverse it?
Who owns it?
When does a human get involved?

Patterns in my work

A few opinions you'll notice around here.

I don't start with the agent. I start with the job.

“Build an agent” is an implementation idea, not a problem statement.

I don't assume more autonomy is better.

The most useful system is often somewhere between “AI suggests” and “AI runs the company.”

I prefer bounded autonomy.

I don't default to custom software.

Sometimes the sophisticated technical decision is realizing that 80% of what you need already exists.

Build where you differentiate. Rent the commodity layer. Bend the stack while you're still learning.

I don't consider the demo done.

A prototype tells you what happens when everything works.

Engineering tells you what happens when the API changes, the data goes stale, someone edits the prompt, or Tuesday happens.

I don't think AI strategy is about maximizing AI.

The goal isn't more AI. The goal is better systems.

Sometimes that means building. Sometimes buying. Sometimes automating. And sometimes deciding: this does not need AI.

Writing

The thinking behind the experiments

I also write about the decisions underneath AI adoption — what deserves to be automated, what should stay human, where technical judgment matters, and what we're learning as these systems move from demos into real work.

How Much Power Should You Give an AI Agent?

Blast RadiusCOMING SOON

The Demo Is Not the System

One Bad TuesdayCOMING SOON

Build vs. Buy Is Missing a Third Option

Build / Buy / BendCOMING SOON

A List of AI Use Cases Is Not an AI Strategy

The AI DraftCOMING SOON

Substack

New essays will be added here as they're published.

Thinking and building belong together.

Strategy without execution stays hypothetical. Building without judgment creates expensive toys. I care about both.

You're here

Decision Lab

How I think

Interactive experiments about:

prioritization
architecture
autonomy
reliability
AI strategy

Explore Decision Lab

Build portfolio

Build Showcase

How I build

A collection of AI prototypes designed around real problems for:

investors
executives
operators
teams

Browse Build Showcase →

Office Hours with Chanel

Bring me the messy version.

“We should use AI.”
“Our team wants to build an agent.”
“This vendor says they can automate this.”
“My engineers built something and I don't know whether it's actually good.”
“We have ten AI ideas and no idea where to start.”

That's where Office Hours begins.

AI Strategy Office Hours

For executives, investors, and senior operators who need a technical thinking partner.

We start with a focused strategy sprint to:

—evaluate AI opportunities
—pressure-test vendor or internal proposals
—collaborate more effectively with engineers
—decide what to build, buy, automate, bend, pilot, or avoid
—identify technical and organizational risks before they become expensive

Clients can continue after the sprint with monthly advisory: two sessions per month + async review.

Book a free 30-minute discovery call →See what we can build →