From racks
to agents.

My first technology world was the family Apple IIe. The rest of the family stayed in the Apple world. I went sideways.

Word processing on that Apple IIe felt closer to marking up a page than typing into a modern editor. The family journey continued through the Apple IIgs and the Mac Classic. Mine changed direction because my uncle introduced me to another world: the Commodore 64, the Amiga 500 and eventually x86 PCs.

I remember an XT with a monochrome screen, DOS 5 and XTree Gold. On later x86 builds, jumpers and dip switches controlled settings that firmware handles today. Get a clock or voltage setting wrong and you could cook the CPU. It was not an abstract hobby. Curiosity had consequences, sometimes immediately.

I did not know it at the time, but that became the pattern for everything that followed: get close to the technology, make it do something useful, work out what broke and carry the lesson into the next thing.

The computer became a connected system

Bulletin boards, dial-up internet and early home networking changed the scale of the question. The interesting thing was no longer only the machine. It was what happened when machines, protocols and people had to work together.

That interest took me into internet and core carriage support, then into infrastructure: racks, compute, storage and virtualisation, all within managed services. The equipment changed, but so did the weight of the work. These were systems other people depended on.

A rack is honest. A cable goes somewhere. Storage has a limit. A failed component is not a debating point. Managed services added the part that still shapes how I think: a technically elegant design is not enough when somebody else has to own, support and recover it.

Virtualisation made the relationship between workload and hardware more flexible. I loved what that made possible. It also taught me a lesson I have carried through every technology wave since: abstraction rarely removes complexity. It changes where the complexity lives and who has to deal with it.

Then the work became a product question

Moving into product architecture, product engineering, innovation and product development widened the frame. I was still interested in how the technology worked, but the harder question became whether it could become something coherent, useful and operable.

This is where several threads that can look unrelated on a CV made sense to me as one body of work. AR, VR, MR and spatial computing pushed me to think about how people meet technology. SD-WAN, SASE and private 5G pushed me to think about how a capability becomes part of a wider service rather than another isolated product.

I got heavily into immersive and spatial technology because it made the future tangible. You could put on a headset, change the interface and immediately see new possibilities. But the same instinct from the PC bench and the rack kept returning: what has to be true beyond the demonstration? Who is it for? How is it supported? Where does it fit? What survives when the novelty wears off?

That is the point where strategy and hands-on work stop being opposites. I need both. Playing with the technology tells me what is possible. Product and operating-model thinking tells me what it would take to make the possibility dependable.

AI is where the threads meet

AI brings all of those questions together. It has infrastructure underneath it, interfaces around it, product decisions inside it and an operating model that is still being worked out. Agents add another wrinkle: software can be given an objective, tools and room to act without a person describing every step.

Bob is my partner in crime in this part of the journey: a supervised personal AI collaborator and a practical place to explore the questions. Building and working with Bob makes the conversation less theoretical. It forces me to think about identity, access, memory, evidence, boundaries and what should happen when the system is uncertain.

Bob is not evidence that the enterprise problem is solved. He is part of how I get close enough to the technology to discover better questions. The useful work begins after the first impressive result, when you have to decide what the system may do, who remains accountable and how anybody else can inspect what happened.

The workbench and the operating model

Looking back, I do not see a collection of disconnected technologies. I see a widening workbench. The early PC taught me to touch the thing I wanted to understand. Networking taught me that components become systems. Managed infrastructure taught me that systems carry consequences. Product work taught me to connect capability with ownership and operation. Spatial computing kept me looking for better ways for people and technology to meet.

AI and Bob are the next chapter, not a break from that history. The tools are different, and some of the questions are sharper, but my way of working has not changed very much. Play with it. Build enough to expose the difficult parts. Then follow those parts into architecture, product and the operating model.

I am a strategic technologist, but I never want strategy to become a safe distance from the technology. I like getting my hands dirty because that is where assumptions fail early enough to be useful. I like the strategic work because a successful experiment still has to become something people can responsibly depend on.

What this essay can—and cannot—say

The early-computing sequence here is my recollection, not a verified hardware timeline. The professional journey is also deliberately high-level. I have not named employers, customers, incidents or commercial outcomes, and I have not turned private work into public proof.

The lessons are my interpretation of the path I have taken. Bob is described only as a supervised personal collaborator; this essay does not claim a measured result, an autonomous production system or an enterprise deployment. Those stronger claims would need public-safe evidence that is not part of this essay.

What I can say is simpler. I still love what I have done, what I am doing and what may come next. I still start by getting close enough to understand. And I still believe the interesting part begins when an idea has to leave the workbench and survive in the real world.