I love learning what people are doing with AI. The harder part is keeping up with all of it—and figuring out which ideas will actually help us do better work.
There is always another tool, another clever prompt, another impressive demonstration. I don’t want our team collecting information just to have more information. I want us to learn something, use good judgment about it, and be able to explain what changed.
That’s why we’re putting together an AI Learning Radar. And rather than keep everything in our own notes, I want to share the useful parts here: where an idea came from, what we took from it, what we left out, and how it worked in our environment.
What we’re building
In plain English: our AI team should learn substantially more than I need to read. The team can work through the technical detail. I need the part that helps me make a decision, improve a business, or teach something useful.
For this series, we’ll take that same approach with you. Start with the practical explanation. Add the technical detail where it helps. Give credit to the people whose work got us thinking.
Technical translation Explore the detail
A learning radar is a review process, not a particular software product. We discover a claim, check its evidence, compare it with our current approach, and decide whether to save a lesson, propose a test, or make no change. Learning something does not automatically authorize an agent to change a system.
The first useful finding: check what’s already there
Our initial review found existing project instructions, compact checkpoints, saved lessons, and rules for checking actual work. We already had parts of the foundation.
So before we build another tool, we need to ask: is something missing, or do we need to use what we have more consistently?
That’s a useful question outside AI, too. A new system isn’t much help if it adds another place to look without solving the original problem.
Technical translation Explore the detail
Working memory is the small amount of current context an agent needs: its goal, constraints, progress, and next action. Project memory holds durable decisions and evidence. Operational learning holds reusable lessons about how to work better. Keeping these distinct can help us retrieve relevant information without copying entire conversations into every task. We have not measured the benefit of this approach in the radar pilot yet.
What we’ll try—and what we might leave alone
We’ll look closely at ideas that could reduce repeated mistakes, help interrupted work resume, or get us to a usable result with less unnecessary testing.
But a technique doesn’t have to be adopted to be worth understanding. Sometimes our conclusion will be, “We already do this.” Sometimes it will be, “Interesting, but it doesn’t fit our setup.” And sometimes we’ll need a small private experiment before we know.
We also won’t assume that advice for one AI tool transfers directly to another. The principle might be useful even when the settings or features are different.
Technical translation Explore the detail
An evaluation checks a technique against explicit criteria. For example: did the agent resume from the correct point, preserve the constraints, and produce the intended deliverable? Passing a technical check is one piece of evidence. It does not, by itself, prove a better customer experience or a business improvement.
Where we are today
We’ve completed an initial review of our internal documentation and prepared the pilot approach. We haven’t completed the two-week pilot or established time savings, lower costs, or better delivery from it.
As we go, we’ll label what’s being explored, what’s been tested privately, what we’ve adopted, and where we have measured results. If something doesn’t work, that belongs in the story too.
A question to take into your own work
Before trying the next AI technique, ask: What problem am I trying to solve, and what would convince me this actually helps?
That’s where I want this series to start. Useful learning, honest results, and credit where it’s due.
Sources and acknowledgments
This introductory article describes our own proposed process. It does not announce a newly verified external technique.
Our initial reading list includes Ruben Hassid, Addy Osmani, IndyDevDan, Simon Willison, Hamel Husain, Ethan Mollick, and Lenny Rachitsky, alongside relevant official engineering documentation. Inclusion is a reading choice, not an endorsement or a claim that we have reviewed all their work.
Ruben Hassid’s How to AI is a discovery source previously reviewed internally. Future entries will credit the exact original work, its publication date, and our interpretation. No external claim was freshly validated for this introduction. Internal project records remain private.
Prepared with AI writing assistance. No client information is included.