Why I'm documenting the journey

Every solution has a first draft. Every idea evolves. This Staffroom exists to record that evolution.

When I first started exploring Microsoft's AI ecosystem, I assumed the hardest part would be learning the technology. Copilot Studio, Power Automate, Power Apps and the wider Power Platform felt like an entirely new world, and I expected the challenge to be understanding how each service worked.

What I've discovered is that learning the tools is only one part of the process.

The greater challenge is learning how to apply them thoughtfully within real organisations, where every technical decision has implications for people, processes, governance and trust. Building an AI solution is rarely about writing the perfect prompt or creating the cleverest automation. More often, it involves asking better questions, understanding how work is currently done and deciding where technology genuinely adds value.

That is why I decided to document the journey.

This Staffroom isn't intended to be a collection of polished success stories. Instead, it's a working journal that captures the process of learning, experimenting and refining ideas as they develop. Some articles will describe prototypes that worked exactly as intended in a development environment. Others will explore decisions that didn't deliver the expected outcome, assumptions that proved incorrect or design choices that changed after testing.

I think there is value in recording both.

Documenting the mistakes

It is easy to showcase a finished solution once it is working. What is much harder—and often much more useful—is understanding the mistakes that happened along the way.

Every build contains small decisions that seem sensible at the time but reveal limitations once the solution is tested in practice.

Sometimes a prompt is too broad.

Sometimes an automation tries to solve too many problems at once.

Sometimes the technology works perfectly, but the process surrounding it does not.

Those moments rarely make it into polished case studies, yet they often provide the greatest learning.

Rather than hiding those experiences, I want to capture them here. If a design decision turns out to be flawed, that is worth documenting. If a governance consideration changes the architecture of a solution, that deserves recording too. Looking back over those decisions should provide a more honest picture of how practical AI adoption develops over time.

Recording the decisions

Every AI solution is shaped by hundreds of small decisions.

Should a response be generated automatically or require human approval?

Where should knowledge come from?

How much freedom should an agent have?

When should a workflow stop and ask a person to intervene?

Many of these choices have no single correct answer. They depend on the context, the organisation and the level of risk involved.

Writing those decisions down forces me to explain the reasoning behind them rather than relying on instinct. It also creates a record that I can revisit months later to understand how my thinking has changed.

I suspect that many of the opinions recorded in these early articles will evolve significantly as I gain more experience. That's exactly what I hope happens.

Showing the evolution

One of the most interesting aspects of building AI solutions is how quickly they improve through iteration.

A simple proof of concept becomes a structured workflow.

A workflow becomes a governed process.

A governed process becomes something that can genuinely save people time without introducing unnecessary risk.

Looking back through earlier versions often reveals how much has changed—not because the original idea was poor, but because each iteration teaches something new.

Rather than presenting only the finished version, I want this journal to preserve that evolution. Future articles will reference earlier designs, explain why they changed and show how small improvements gradually produce better solutions.

Progress is rarely one dramatic breakthrough. More often, it is the accumulation of many small refinements.

Sharing practical examples

There is already plenty of discussion about artificial intelligence.

What I find more valuable are practical examples.

How does a school actually automate enquiry emails?

What happens when a Copilot agent cannot answer a question?

How should approval workflows be designed?

Where should knowledge be stored?

What governance controls make the biggest difference?

Those are the kinds of questions I want this journal to explore.

Whenever possible, articles will include screenshots, architecture diagrams, design decisions and reflections from building realistic proof-of-concept solutions. My hope is that someone working in education can read an article and leave with at least one practical idea they can adapt within their own organisation.

Looking ahead

This journal will inevitably change as my understanding grows.

Some ideas recorded today may feel incomplete six months from now. Others may turn out to have been entirely the wrong approach. That's part of learning.

If these articles demonstrate anything, I hope it is that expertise is built through curiosity, experimentation and reflection rather than certainty.

Every solution begins with a question.

Every improvement begins with a lesson.

This Staffroom is simply where I'm choosing to write those lessons down.