← Selected work

Case Study — 01 / Learning Systems

Automations in Scout

A Scout skill that catches the right moment to teach — so learning happens inside the work, not after it.

Role

Product Lead

Year

2026

Tools

Copilot CLI

Prototype

Try it yourself ↗

01 — Context

The gap

Most learning happens outside of work, not inside it.

Courses and reminders assume you'll circle back later. But the best time to learn something is right when it's in your way, not next Monday. So I asked a simple question: what if learning could just show up, exactly when the work calls for it?

 
Learning today
Learning Autopilot
Timing
Scheduled — a course, a reminder, a calendar block
Tied to a real signal — a question, a meeting, a project closing
Volume
A whole course to work through
One short resource, chosen for the exact gap
Control
Set it and forget it
Open it, save it, or dismiss it — every time
Access
Asks you to trust it
Read-only, and visible what it's looking at

So what

The gap isn't more content. It's timing, and permission to ignore it.

02 — Framework

Four rules

Four rules keep a nudge from turning into noise.

Timing has to be earned by a real signal. The resource has to be one thing, never a list. The person stays in control the whole time. And what it's allowed to read stays visible and limited. Each rule stops one specific way this goes wrong.

01
Signal-led timing
It only shows up after something real happens — a question, a meeting, a project wrapping.
Not a streak, not a calendar reminder, not a quiz.
02
One resource
Always exactly one short resource, chosen for the exact gap.
Never a course. Never a list to work through.
03
User control
Open it, save it for later, or dismiss it — every single time.
A saved item gets one gentle nudge later, not a campaign.
04
Transparent access
What it reads — calendar, transcripts, mailbox — stays visible and limited.
Read-only. Nothing is shared with anyone else.

So what

Signal-led timing is what makes the other three rules feel earned instead of annoying.

03 — Proof

Scenario 1 of 3

A good question in a meeting shouldn't just disappear.

Someone asks how to set up a conditional approval step, the meeting moves on, and normally that's the end of it. Scout notices the question in the transcript, waits until the meeting is over, and comes back with exactly one short resource for that exact gap.

Open this scenario full screen ↗

So what

The moment was already there. It just needed someone to catch it.

03 — Proof

Scenario 2 of 3

Prep should show up before the meeting, not after.

A kickoff lands on the calendar, and the agenda hints at unfamiliar ground. Scout picks up on that timing and queues one short primer early enough to actually read it, not the morning it's due.

Open this scenario full screen ↗

So what

Earned timing is the whole difference between a helpful nudge and a notification you swipe away.

03 — Proof

Scenario 3 of 3

Finishing a project deserves five seconds of thought, not a survey.

A six-week project wraps, and Scout opens a quiet, private session with one question: what was hardest to navigate. No form, no scoring, just a moment to notice what you actually learned.

Open this scenario full screen ↗
What the three scenarios covered
 
Signal timing
One resource
User control
Transparency
A question in a meeting
Prep before a meeting
A project wraps
Fully exercised Partly exercised

So what

Three different signals, one shape: earn the timing, then get out of the way.

04 — Risk

Guardrails

Get the boundaries wrong, and this turns into surveillance.

Every rule from the framework exists because skipping it breaks something specific. Read access without limits turns into monitoring. Timing without user control turns into nagging. These aren't nice-to-haves — they're what keeps this from becoming the workplace tool everyone already resents.

Timing without control
Nagging, not helping
Access without limits
Monitoring, not signal
A resource without a stopping point
A course in disguise
Any of it without transparency
Something to hide

So what

Boundaries aren't a limit on the idea. They're the reason anyone trusts it enough to use it.

05 — Craft

How it was made

I built the whole thing with the Copilot CLI, start to finish.

Same approach every time: write the argument in plain prose first, then let it become a prototype. If an idea couldn't survive being written down clearly, it wasn't going to survive as a screen.

STEP 01
A written brief
The argument first, in plain prose. Same test as always: if it didn't hold up as writing, it wasn't going to hold up as a screen.
STEP 02
Scenarios, not slides
Eight real work moments, sketched as plain conversations before any UI existed.
STEP 03
Copilot CLI, wired to the brief
An agent turned the written scenarios directly into a working interface, moment by moment.
STEP 04
A working prototype
Clickable, end to end — the same one embedded on this page.

So what

Writing it first meant the prototype was never left guessing what the idea actually meant.

06 — Reflection

What I learned

The hard part was never detecting a signal.

It was deciding when to stay quiet. Every scenario started out as “we could nudge here too,” and the real work was cutting that list down to the few moments that actually earned it. Restraint turned out to be the whole feature.