A colleague on a board I sit on recently made a useful suggestion in a meeting. She recommended playing beta wave audio tracks as background music or through earphones when working on tasks that need a high degree of concentration. After a few days, I decided to try, having been doubtful at first. Background sound had never done much for me before and I have a tendency to just block it out while concentrating.

The change was surprisingly immediate. I started a 14 Hz beta track on Apple Music and went back to the design I had been struggling with. Ideas that felt stuck suddenly started connecting. Sentences came more easily. The mental block I had been fighting for hours through procrastination simply lifted. Work started moving much faster, then flowing like a stream. This experience made me wonder what exactly happens in the brain with beta waves?

Organisations today face strong pressure to adopt AI tools to stay competitive, the new refrain being ‘AI first’, the mantra that if AI is not fully embraced that the company will be left behind in favour of those who go all-in. Solutions like Claude from Anthropic stand out for their ability to process complex information, support better decision making, and drive operational efficiency. Many companies choose the Model Context Protocol, known as MCP, to connect these AI models to their internal data and systems. MCP uses a client-server architecture that enables rich, dynamic interactions between the AI and enterprise tools. Although this design works efficiently for rapid development and testing, it creates several serious challenges when introduced into secure production environments.

When organisations shift a system to a SaaS provider or hand hosting over to a public cloud, something subtle but dangerous often happens. We offload more than just the infrastructure. We offload our thinking. The comfort of a service-level agreement (SLA) and the promise of “high availability” can create a false sense of security. Many teams admit, in private at least, that they have never fully read the SLA, let alone stress-tested its real-world implications.

Availability receives significant focus, yet there remains a widespread assumption that simply spreading workloads across multiple availability zones or data centres is sufficient protection. Recent cloud outages have shown how dangerous this assumption can be.

We have all sat in meetings where a difficult issue is unpacked and eventually resolved. Someone stands at the whiteboard and starts drawing. Boxes appear, arrows connect them, dotted lines show dependencies, and labels get scribbled in. As the diagram grows, elements are erased with the side of a hand and redrawn. The room gradually reaches agreement. By the end people feel aligned. Phones come out, photos are taken for the record, and everyone leaves satisfied. Those images rarely get opened again. The whiteboard is wiped clean for the next group. Yet the work of the diagram is already complete.

The perennial question in technology circles is where best to host our workloads: on-prem or in the cloud. The two camps seem increasingly divided. Reports of companies swinging back towards on-prem infrastructure to escape rising cloud costs appear regularly. At the same time, many organisations proudly declare themselves cloud-first, while others settle somewhere in the middle by claiming to have a cloud-native approach.

The real question should no longer be where a workload is hosted. It should be how we can securely parcel it up so that the location becomes almost irrelevant. Achieving this would liberate our compute resources to go wherever the future demands.