ISC is over. But now that you’ve had a few days to rest, the conversations in your head are still spinning. Need an outlet? Come along to HPC Club in a week. 8 July to be precise.

When we first announced this edition of HPC Club with Lawrence Livermore National Lab presenting I think it was pitched as the owners of the world’s largest supercomputer, El-Capitan. Unfortunately, as of last week they have lost that title, being pushed down to number 2 by LineShine. It makes neither Vanessa nor Dan any less capable, but it takes the marketing sheen off things a little. Not that any true HPC NErD would care right?

Apart from being home to the number two supercomputer in the world, LLNL is also the birthplace of Slurm, one of (if not the most) widely used schedulers. It is also birthplace of Flux, the new scheduler that is run not only by El-Capitan but several other DoE supercomputers and is seeing increasing adoption now that it has been donated to the High Performance Software Foundation (a part of the Linux Foundation). Want to speak to the people who created it? Not only about Flux but also its integration and how they’re using AI workflows?

As if that wasn’t enough, we’ll also have Man Group presenting on the challenges they have faced in AI adoption. In case you haven’t heard of them, Man Group is a hedge fund and places like that don’t run on hope and hype so if you want to see what real usage looks like, come along and find out.

As of this morning there were only 10 places left, so don’t hang about. Please do sign up even if the event becomes wait listed, if there’s enough demand, we’ll see what we can do about extending the capacity.

Lessons from LLNL in Supercomputing & AI - July 2026 - HPC CLUB

HPC Club event on CPUs, GPUs and silicon diversity. Join us for an evening of discussion and networking with industry experts. 26 November 2025 @ 17:00, Canary Wharf, London.

HPC CLUB

HPC Club: Supercomputing & AI with LLNL & Man Group · Luma

With the current hype, it can be confusing about what AI can really do, and potential benefits for science and the financial industry. For this HPC Club, we…

HPC Club

It would be hard to cover what was important in supercomputing and HPC last week without talking about ISC 26. So, this edition of The SC brings blends the news from Europe’s largest supercomputing conference with everything else that happened last week.

The opening keynote talked about something I’ve been harping on about for almost two years at this point. Homogenous supercomputing is dead. Well maybe not quite yet but the future is absolutely heterogenous. Whilst two years ago that meant having to deal with multiple CPU and GPU manufacturers and knowing which one to pick, today that means a range of possible CPU architectures, GPU architectures and other accelerators including quantum and neuromorphic computing. The framing here, of quantum as another accelerator, in itself was quite interesting. And quite correct.

Quantum computing dominated not only the opening keynote but in many regards the conference itself. Where last year storage vendors took the most prominent position on the conference floor and competed for attention, this year (apart from Nvidia of course) that honour went to quantum computing vendors who dominated by number if not by placement.

My conversations (with multiple vendors) were all of course very optimistic and pointed to a bright future for quantum. Unlike AI however, it is far harder to draw the line on where reality ends and the hype starts with quantum computing. My own interests lie with its applicability to financial risk analytics and while many references were made to papers where this has been shown as feasible, I think this is an area that will need some actual work to be done (by us). Watch this space, I guess? If there’s enough interest, I guess we will have some work to do in separating the wheat from the quantum chaff.

Non ISC news about Microsoft’s topological qubits with Marjorana 2 seemed to echo all my conversations at ISC. i.e. they don’t exist. In fairness to Microsoft, I guess those conversation were all with their competitors in this space 😁

The release of the Top500, even with a new machine taking the number one spot this year, hardly featured in my conversations at all. Perhaps this speaks to the decreasing relevance of the Top 500? The Top500 itself is changing too with control passing over to ACM. I wonder if this will improve things.

China’s LineShine took the top spot, displacing El Capitan which had held it since November 2024. The first thing that stuck me about this was that LineShine had even bothered to submit to the Top500. It has been a number of years since China had stopped participating over increasing tensions between it and the USA. The decision to participate now, and with a CPU (ARM with HBM, quite interesting) only system I think speak volumes.

Overall, much like last year, the conference itself didn’t feature any new releases from vendors. It was no longer focused on attempting to be relevant in the wider AI news cycle either and the main floor felt less like a plumbing trade show (though there were still suppliers of liquid cooling solution present) than last year too. AI did still feature heavily but more in its application within HPC communities and the adoption of technology developed for AI into scientific computing. 

Which segues nicely into my next point. The keynotes, presentations and talks all feel very much like a community focused on science and academia. This is quite distinct from the highly commercial nature of the main show floor, and I felt that there’s a trick missing to build a better bridge here. To be clear, I don’t mean letting vendors take over the talks. That would be terrible. I do mean having more commercial users of supercomputing presenting and sharing ideas. I know this is always difficult to achieve but that just makes it all the more valuable. Supercomputing is so much bigger than just science and academia, we need to include more of those people in the conversation.

In other non ISC related news, OpenAI and its partnership with Broadcom has a name for their AI inference accelerator, Jalapeno. There seems to be little detail about it beyond this though.

Lastly, for the finance nerds like me, QuantMinds London is now open for booking with reduced prices till early August.

All the News in Depth

Cloud and vendor releases for Supercomputing & HPC (and AI too if you change the filters)

New Top500 with a new machine at the number 1 spot

and the Top500 itself hands over control to ACM

It seems like everyone is designing their own silicon now and OpenAI doesn’t want to be left behind. An Ed Zitron podcast claimed this was another wafer scale design but I don’t see any other claims of that from OpenAI themselves.

Calling this one out explicitly even though its in the release notes above… making HPC easier for the people that need it is something I think we’ve never been good enough at as a community… if AI really can solve that problem, then great

Does Microsoft’s Topological approach to Quantum actually produce any qubits? No one at ISC seemed to think so either.

EPCC gets a new supercomputer

Quant Minds booking now open

HMx Labs Updates

Last few spots left for HPC Club

HPC Club 08 July – Reservations Open

Want to come along to HPC Club on 8th July? Better book your spot now

Flux by HMx LabsHamza

Still not filled this role

Hiring: HPC Engineer

We’re looking for another HPC software engineer! Know someone that might be interested? Fancy pointing them my way please? This video was brought to you by the letters H, M and X and the number 42. Have a good weekend everyone. 0:00 /0:03 1× Apply on LinkedIn

Flux by HMx LabsHamza

Off Topic

I’ve previously mentioned superconducting chips, how about diamond cooled instead?

Will OpenAI IPO this year after all?

Nightmare Eclipse strikes again

The surveillance state takes another step forward

Know someone else who might like to read this newsletter? Forward this on to them or even better, ask them to sign up here: https://cloudhpc.news

ISC26 kicks off in Hamburg today! The AI news has even been kind enough to have a small break in its insane pace so that everyone can talk about supercomputing instead 🎉 My worries about the lack of interest are also completely unfounded it seems with early numbers showing that the conference already has more registered participants than last year. HPC Wire has a few themes to look out for, the last of which is quantum computing…

In what felt like a scripted TikTok meme, but I can assure you wasn’t, as I sat in the barber’s chair yesterday, his opening conversation was about how much money he’s made on D-Wave and IonQ stock. I kid you not. Knowing what my day job is, he then proceeded to ask for advice on which quantum computing company to invest in next and which company would win. Have we hit peak hype for quantum already? Or is it genuinely poised to be the next useful thing? I don’t know but I think a lot of the plumbing that quantum computing uses may end up being more valuable (short term) than the quantum computing itself if the plans to use superconducting conventional computing play out.

In less funny but more important news, LLNL & co have selected Intel’s spin off Cornelis Networks for the Lynx supercomputer over the more traditional Infiniband in an announcement no doubt perfectly timed to allow Cornelis to talk about this at ISC. Nicely played. I guess this shouldn’t be too surprising in many regards as they were already using AMD APUs for El-Capitan and don’t seem averse to bucking the AI trend. Good on them!

Fancy over 80,000 CPU cores in a rack? Liquid cooled of course. Now you can with HPE Cray’s new offerings based on AMD’s Venice CPUs. With SSDs on coolers too it looks like a genuinely interesting design. I guess you better start planning for higher power consumption compute dense racks regardless of if you’re adopting GPUs or not. Even with Turin our testing showed 2KW per 1U sled theoretically giving you100KW fully loaded racks. Without a GPU in sight! eeeek.

The FP64 vs FP8 debate is getting lively post the “FP8 is All You Need” paper (see, we can’t even name research papers without a nod to the one that kicked off the current AI boom!) and its subsequent presentation at TPC26. My gut feel here is that FP64 will remain in demand and relevant though I’ll admit I have little to back that up beyond the overall tone of the conversations I’ve had in this space.

There’s another important conversation I think we should be having (maybe at ISC too?) which is around the future of open source software. I think this is even more important for the HPC and supercomputing community than for software in general and I suspect most of us are burying our heads in the sand around it.

See you in Hamburg! 

All the News in Depth

Cloud and vendor releases for Supercomputing & HPC (and AI too if you change the filters)

ISC is go with more attendees than last year already signed up.

HPCWire has a few topics to watch for

LLNL Picks Cornelis Networks for its Lynx supercomputer.

80k + cores in a rack with AMD Venice

FP8 or FP64? Which side of the argument do you fall on?

Shrinking Data Centres and using quantum computing plumbing for conventional compute

HMx Labs Updates

I think open source software is more important now than it has ever been

FOSS in the Age of AI

How do we solve for open source software in an age of AI. I don’t know but I thought I’d share some half baked ideas anyway.

Flux by HMx LabsHamza

A little out of date now and is it turn out, rather unfounded!

ISC? Where’s the Chatter?

This time last year, social media feeds and even industry headlines were filled with what’s to come at ISC. This year you’d barely even know it’s happening.

Flux by HMx LabsHamza

Off Topic

Modern day Luddites. This one is worth a watch, and I do mean watch as opposed to just listen as I first did via Apple Podcasts.

Linus Torvalds compares compilers to AI generation

Will vibe coding be the worst mistake we ever make as an industry?

Ed Zitron said something really interesting in this one. Like Ed, the praise heaped upon me by code generating genies rather rolls off my back. I don’t place any weight on it. I’d go so far as to say I tend to completely ignore it. I assumed everyone did this. Apparently not? Et tu brut? Also, the overall point by Cal Newport around both doom trolling and the backlash to it is very on point.

Know someone else who might like to read this newsletter? Forward this on to them or even better, ask them to sign up here: https://cloudhpc.news

I don’t talk about politics. I don’t post random, meandering, half baked thoughts. But its Friday and I’m going to do both today. Specifically, about Fable 5, open source software and AI more generally.

A common reaction I’ve seen to the US government’s restrictions placed on Fable 5 is an increased call for sovereign AI. While, especially outside the USA, that might pass the sniff test, it does feel a little like swapping Coca Cola for Pepsi. I’m sure the purveyors of anything sovereign AI/ hardware/ compute related will push this answer but its incomplete at best and deliberately misleading at worst.

Firstly, this assumes that USA based entities are perfectly happy with suddenly losing access to technology. I suspect that’s not the case. And this is your first clue that the answer doesn’t lie in further entrenching notions of an AI race with control granted to nation states and their proxies.

I’m not going to even pretend I know where the answer does lie. I do not. I will refer you back to my opening line.

However, for a long time, a sensible yin to the yang of proprietary software has been FOSS, free and open source software. The Linux to your Windows. The HT Condor to your IBM Symphony. Whilst it was nice that its free as in free beer, what has always been more important was that it was free as in available to inspect and change and use without restriction.

It’s that last part that is a clue to the right solution.

Unfortunately, FOSS has been having a rough time of late. Even before AI snuck into the party.

Whilst the XKCD meme of the internet being held together by one unpaid programmer in Nebraska is undoubtedly true, it is also true that that huge proportion of open source software today is paid for by commercial entities. As a result, we’ve seen several examples of “rug pull” license changes undermining confidence in open source software. Recent developments such as Malus for AI washing open source complicate things even further.

It would appear that without a solid commercial incentive, there is little reason to pursue anything open source, let alone anything as challenging as an alternative to Fable 5. P.S. open weights != open source. Though it’s a start, I guess. 

So how do we fix this? I still don’t know, but I do know that it has to come down to you and I. Big tech won’t fix it for us. An AI “race” and counting on other nation states with their own agendas won’t fix it either (though it might provide some short-term alternatives).

Even the “worst” companies have “good” people working in them. It’s down to us, you and I, to think of and provide use cases and justifications that can align with the corporate vision but produce ancillary benefits. We managed with projects such as Kubernetes.

FOSS becomes both harder and more important in an age of AI. I don’t know how we do it. I just know that we have to.

Feel free to tell me I’m wrong? Or grab me for a coffee to talk about it at ISC.

It’s ISC in Hamburg next week. Not that you’d know it from your industry press headlines or your social media feed. This time last year people were busy announcing that they’ll be attending, asking who else is going and arranging meetings. Many of the bigger companies were circulating invitations to parties and private meetings.

So far, this year, you’d barely even know ISC is happening in a week!

I know there’s a lot going on in the world of AI but even so I’m a little surprised it has taken over the conversation to this extent. We don’t even have HPC trying to muscle in on the AI conversation and position itself as relevant anymore. There seems to be more of a resignation and acceptance that HPC is now a user of AI like everyone else.

So, who’s going? I somehow doubt I will turn up to find an empty conference floor. Though it does perhaps feel a little more academia focused this year than it did last (looking at the presentations at least).

And if you can’t make it, come and catch up on all the gossip at HPC Club a week or so later instead 😉

Welcome to your rebranded and updated weekly roundup of news on all things supercomputing with a side of my own opinions. The old name bore little resemblance to what I actually talked about so it’s time for an update!

As a quick reminder, I tend to cover the bits of supercomputing and HPC that are important to people working in the field. The focus is generally more on the tech rather than what it can do. Less drug research and weather simulation and more CPU architectures and schedulers if you see what I mean. Though there might sometimes be a twist of finance thrown in. Sorry, can’t help myself! 

Strictly no AI hype! Frankly AI news is so well covered everywhere else, I often gloss over even the supercomputing relevant bits on the assumption you’ll have seen that elsewhere.

First up, its ISC next week though you’d never know it! AI has so completely taken over any form of news cycle, social media feed and even in person conversation that it barely registers. Is anyone even going? 😁 I note the hyperscalers are all notably absent from the sponsor list again.

Last week’s news was quite ARM flavoured. ARM has teamed up with Supermicro as resellers/ system builders of their first CPU. If you’re confused, see my previous take on ARM creating their own CPU [2]. Short version, though, I think it puts them in a much more complicated position. That doesn’t seem to have bothered AWS, who released version 5 of Graviton [3], their ARM based CPUs last week, currently only available in the M flavour (memory optimised) VMs but I’m sure we’ll see the C and R versions pop up shortly.

AMD isn’t taking this lying down though, with claims that its latest “Venice” generation of CPUs outperforms Nvidia Vera ARM based CPUs at rack scale [4]. I am so looking forward to getting my hands and on and benchmarking some of these myself.

Weka (a storage vendor) says they have a way to boost inference performance without buying more GPUs [5]. Not a great surprise really, I can’t remember the last time I had a supercomputing problem that was actually compute and not IO bound!

We still have a few places left for HPC Club so if you’ve not booked your place yet, I wouldn’t hang about [6] or  go here for the booking link[7] for those of you behind corporate firewalls that hate anything that doesn’t look like a boring vendor site (and some that do).

All the News in Depth

Cloud and vendor releases for Supercomputing & HPC (and AI too if you change the filters).

[1] ARM teams up with Supermicro for its new CPUs

[2] and my own previous thoughts on ARM making its own CPU

[3] AWS gives us new Graviton 5 ARM CPUs

[4] AMD pushes back on the performance claims of Nvidia’s ARM based Vera CPUs

[5] Weka boosts inference performance

HMx Labs Updates

[6] Details and tickets for HPC Club are now available

[7] Direct link to book if your corporate firewall hates fun

HPC Club 08 July – Reservations Open

Want to come along to HPC Club on 8th July? Better book your spot now

Flux by HMx LabsHamza

We’re expanding FLOPx to be more useful for more of you, but to do that we need to know which benchmarks you care about

What Benchmarks Do You Care About?

We’re integrating new benchmarks into FLOPx. What data would you like to see?

Flux by HMx LabsHamza

Still hiring for a HPC Engineer (but we’ve filled the marketing / bus dev role)

Hiring: HPC Engineer

We’re looking for another HPC software engineer! Know someone that might be interested? Fancy pointing them my way please? This video was brought to you by the letters H, M and X and the number 42. Have a good weekend everyone. 0:00 /0:03 1× Apply on LinkedIn

Flux by HMx LabsHamza

Off Topic

This bit is new. Not supercomputing related but probably adjacent in some form or another, just things I’ve come across that I think are worth your time.

Has AI solved software? Not so much. I certainly still can’t get it to solve the more complex HPC adjacent problems I throw at it (at the systems as opposed to node level stuff).

Creator of OpenCode on Vibe Coding. He has some really interesting take and I found myself agreeing with a lot more than I expected for someone working inside the AI machine.

Creator of Zig. I’ve never used Zig, I don’t currently have a use for Zig. I still found this very interesting and was surprised how much I had in common with him in terms of his philosophy.

Know someone else who might like to read this newsletter? Forward this on to them or even better, ask them to sign up here: https://cloudhpc.news

In my last article, I introduced seven AI analyst personas that run against our Waltz enterprise architecture repository.

Each has a distinct lens: a CTO persona watching for infrastructure obsolescence, a Migration Architect hunting dependency cycles and shared-database cohorts, a TOGAF analyst spotting capability redundancy and standards drift, an Auditor reviewing the other six for agreement and contradiction. Each runs on a schedule, producing structured findings and recommending actions an architecture team can take.

A question I received afterwards stuck with me:  How do you stop this becoming another report nobody reads?

The honest answer is that the first version came surprisingly close to doing exactly that.

The findings were often accurate. But accuracy alone did not make them useful. The system still produced too much repetition, inconsistent prioritisation and occasional moments that made users question whether they could trust it.

Here are six lessons from improving it. Although the examples come from an enterprise architecture repository, most apply to any system in which AI continuously watches data and asks people to act on what it finds.

1. Let the model rediscover problems. Let the application remember them.

My first instinct was to tell each agent: “Do not report anything you already reported last week.”

Sounds reasonable, but it makes the model responsible for lifecycle state that the surrounding application should own.  An anti-pattern.

A better approach is to let the agent report what it sees on every run.  Assign each finding a fingerprint based on its structural identity:

·      which persona reported it

·      the finding category

·      the exact repository entities involved

When the same problem is observed again, it produces the same fingerprint. The system increments an observation count and can refresh the explanation, rather than creating another finding.

The wording can change without changing the identity of the problem.

This is also what makes dismissal meaningful. A user dismisses the underlying finding, not one particular version of the prose. When the agent notices the same issue again, it remains dismissed.

The practical lesson: models should detect; applications should remember.

2. Calibrate severity with contrasts, not adjectives.

Initially, the agents were asked to classify findings as low, medium, high or critical.

Nearly everything became critical.

The model treated any breached threshold as critical by default. It was not consistently considering who needed to act, how quickly they needed to act or whether an immediate response was practical.

Longer definitions did not solve this. Contrasting examples did.

For example:

“A single end-of-life production database supporting six named applications may require urgent intervention.”

Compared with:

“Two hundred applications missing an annual attestation represent a substantial programme of work, but not necessarily 200 separate emergencies.”

The important distinction is not simply the number of affected entities. It is the combination of impact, urgency, concentration of risk and the type of response available.

Once the personas were given contrasting cases, their severity ratings became much more useful.

The practical lesson: calibration examples often communicate judgement better than abstract definitions.

3. Never use generated prose as your navigation model.

The agents include entity references in their explanations. An early version of the interface turned references such as id=875 into application links.

Unfortunately, 875 was not always an application. It might have been a database, a capability or another type of repository entity.

The result was links to the wrong page, or to pages that did not exist.

That is worse than showing no link at all. A missing link is inconvenient. A confidently wrong link makes the entire finding feel unreliable.

Navigation is now driven exclusively by the structured entity references attached to the finding. The entity type and identifier are explicit, and the display name is resolved against the live repository when the finding is viewed.

References that appear only in generated prose are treated as text, not as ground truth.

The practical lesson: use language for explanation, use structured data for identity and navigation.

4. Reject malformed output without abandoning the run.

AI-generated structured output will occasionally be wrong.

A persona may return an unsupported category, omit a required field or provide an entity reference in the wrong format.

The first implementation treated this as a failed run. 

The better approach was to make validation part of the conversation with the model.

When a finding fails schema validation, the validation error is returned to the persona as feedback. The persona can then correct the finding and submit it again during the same run.

For example, a persona might return a severity of urgent when the schema only permits low, medium, high or critical. Rather than failing the run, we hand the error back — “urgent is not a valid severity; choose one of low, medium, high, critical” — and the persona resubmits with a severity of high.

This gives us both sides of the contract:

·      strict validation at the system boundary

·      a forgiving correction loop inside the run

We do not silently accept malformed data, but we also do not throw away an otherwise useful analysis because of one repairable mistake.

The practical lesson: be strict about what enters the system and helpful about how the model can correct it.

5. Measure consistency before tuning prompts.

Prompt tuning is very easy to do by instinct.

A wording change appears to produce a better result, so it is declared an improvement. But the same change may also make the agent less predictable or cause previously reliable findings to disappear.

Before further prompt tuning, I introduced a simple consistency test.

Each persona runs twice, back-to-back, against unchanged repository data. The two runs are then compared using the fingerprints of the findings they produced.

They do not need to use identical prose. They do need to identify essentially the same underlying issues.

Our current regression set is at 100% fingerprint consistency across the agent fleet.

In practice it catches the failures that matter: a persona that finds eight issues on one run and five on the next, or one that silently drops a category after a prompt edit. A wording change that quietly destabilises the fleet shows up immediately as a consistency drop.

That does not prove that every finding is correct. It does give us a stable baseline, a degree of determinism. When a prompt, model or tool changes, we can see whether it has quietly made the system less deterministic.

It is the closest equivalent I have found to a regression test for this kind of analyst.

The practical lesson: for non-deterministic agents, you need a stability signal, not just an accuracy one before you start tuning prompts.

6. AI reviewing AI is useful—but not always useful to the operator.

One of the seven personas is an Auditor.

It reviews findings from the other six analyst agents and looks for gaps, agreement and disagreement. For example, it might identify that two personas assessed the same shared service differently, or that a significant repository area was overlooked entirely.

This is genuinely useful to me as the platform owner.

It is much less useful to someone who has opened an application page to decide what action to take. From their perspective, a discussion about disagreement between two AI personas is mostly system-level noise.

We therefore treat these findings differently in the interface. They appear in a demoted tier and are folded away by default.

Readers of the first article will recognise this as the third reverse-lookup bucket — the inter-persona quality-assurance tier that sits alongside findings which directly affect an application and those that mention it as part of a wider pattern. It earns its place for me as the platform owner, but it should not be the first thing an operator sees when they open an application page to decide what to do.

The information remains available, but it does not compete with findings that directly affect the application or decision in front of the user.

The practical lesson: AI-about-AI output is often platform telemetry, not primary user content.

The model was not the difficult part

The common thread through all six lessons is that none of them required a more capable model.

The difficult work was in the layer between a capable model and the person expected to act on its output:

·      identity and lifecycle management;

·      severity calibration;

·      structured grounding;

·      correction loops;

·      regression testing;

·      information hierarchy.

Model capability can produce a compelling finding.

The surrounding system determines whether anyone trusts it, understands it and does something about it.

What broke first in your AI-output-to-human-action pipeline?

#AIEnablement #EnterpriseArchitecture #EnterpriseAI #AIEngineering #AgenticAI #AIGovernance #DataQuality #ArchitectureManagement #Waltz

What’s your favourite benchmark? The one you instinctively turn to when you want to get a feeling for the performance of a system.

Thera are, of course, no right or wrong answers here (except LINPACK 😀, kidding!) just whichever one most closely resembles your real workload.

I don’t think it’s much of a secret that we work primarily in financial services and the benchmark data we have chosen to include in FLOPx (our cloud and metal performance comparison tool) is quite FSI biased. We’re looking to expand it. Both with additional benchmarks within the finance world but also more broadly with other HPC/ supercomputing relevant workloads.

The obvious missing data point is the QuantLib benchmark (regardless of my own feelings about it) but what else would you like to see?

Would having the results from the SPEC benchmark suite be useful or is that data widely and easily available such that there’s no additional value?

Anything from the Phoronic HPC test suite? OpenFOAM perhaps?

I’m sure you’d love to have them all, but we have to pay to run these ourselves and I haven’t stuck a “dot AI” at the end of our name yet so I’m not made of money 🤣

Answers on a postcard to HMx Towers please.

The silicon theme continues this week, but we do have some other non-hardware related supercomputing news too for once! Also HPC Club reservations are now open so if you haven’t booked yet I’d get on that pretty quickly 😉

CIQ, makers of Rocky Linux, have released an update to Fuzzball to become a fully fledged multi cloud workload management and HPC scheduling solution, putting it directly in competition with products such as YellowDog. It may also be a contender in some regards to using your own scheduler with Parallel Work’s ACTIVATE or FINOS’ new Open Resource Broker. The HPC scheduling space can sometimes feel like it consists of little more than Slurm but lift the covers a little and there are quite a few options! We’ll need to get our scheduler selection tool updated with Fuzzball and its new capabilities.

Staying on the software side of the news, AWS has also done something rather rare by giving us observability out of the box for PCS (Parallel Compute Service)! Anyone that’s been in HPC for more than a day will realise how useful and rare this sort of thing is. It takes the form of managed Grafana so should feel fairly familiar to most people. 

Diving back into the silicon news, we have Intel firmly back from the dead and now taking aim at the AI space with not only new CPUs but accelerators and partnerships too. Talking of Intel, we’ve just spent the past week benchmarking their CPUs for financial services workloads. The data will naturally be available via FLOPx but I’m wondering if a (short) white paper comparing the various models to highlight what (clock speed/ L3 cache) impacts performance in this space would be of interest? Let me know.

Lastly, Microsoft has decided its foray into ARM CPUs is worth continuing with and will be releasing new Cobalt 200 based VMs. The future is definitely looking much more heterogenous.

In the News

Updates from the big three clouds on all things HPC, change the filters to see AI updates too

Intel takes aim at AI

Fuzzball takes on YellowDog, Parallel Works, Slurm & Co

AI price hikes start hitting other tech

From HMx Labs

HPC Club is go!

HPC Club 08 July – Reservations Open

Want to come along to HPC Club on 8th July? Better book your spot now

Flux by HMx LabsHamza

Chocolate & Peanut Butter @ HPC Club

A little bit more detail on what’s coming up in the next HPC Club

Flux by HMx LabsHamza

Still hiring!

Hiring: HPC Engineer

We’re looking for another HPC software engineer! Know someone that might be interested? Fancy pointing them my way please? This video was brought to you by the letters H, M and X and the number 42. Have a good weekend everyone. 0:00 /0:03 1× Apply on LinkedIn

Flux by HMx LabsHamza

Hiring: Marketing & Business Development

We’re looking for someone awesome to come help us shape the future of HMx Labs

Flux by HMx LabsHamza

Know someone else who might like to read this newsletter? Forward this on to them or even better, ask them to sign up here: https://cloudhpc.news

I've been building something in Waltz that I think changes how enterprise architecture teams interact with AI: instead of chatting with a model and getting a one-off answer, we gave seven AI analyst personas persistent access to the EA repository and let them work on a schedule.

Each persona has a distinct lens. A CTO persona focuses on infrastructure obsolescence. A Migration Architect looks for dependency cycles and shared-database cohorts. A TOGAF Enterprise Architect spots capability redundancy and standards drift. An Auditor reads what the other six produce and looks for agreement, gaps, and contradictions.

One persona spotted that a single end-of-life database is still serving six production apps. Another flagged three applications all providing the same capability to different business units, unaware of the others. The Auditor noted that two personas disagreed on the risk level of a shared integration layer and surfaced that as its own finding.

What makes this different from "AI generates a report":

These observations are structured, deduplicated, and lifecycled, not free-text that disappears after a conversation. If you dismiss a finding, it stays dismissed across future runs. If the same problem reappears, the system bumps the observation count and refreshes the wording rather than creating a duplicate.

Every finding is grounded in the EA repository. Every cited application, database, or capability is a real entity you can click through to. And every finding carries 1–3 recommended next steps phrased in actions you can actually take inside Waltz: open a Change Initiative, create an application group, request a data assessment.

The part I'm most pleased with: reverse lookup. From any application page in Waltz, you can see every persona finding that mentions it, bucketed by whether it directly affects that app, mentions it as part of a wider pattern, or is inter-persona quality assurance. The AI's work feeds into the operator's normal navigation, not a separate inbox.

This is a research snapshot, not a finished product.
Structured findings that persist, prescribe, and participate in the tool alongside the operator.

Curious what EA practitioners think. What would you want your AI analysts to notice first?

#EnterpriseArchitecture #AI #Waltz #TOGAF #DigitalTransformation #ITStrategy #ApplicationPortfolio #TechLeadership

HPC Club. 8 July. Reservations open now.

Want to speak to people who run the world’s largest super computers? Want to know how that knowledge translate to your own supercomputing or where AI works and where it doesn’t? In complex environments like hedge funds?

Lawrence Livermore National Laboratory x Man Group x HPC Club

Interested? Well book your spot now then!

Want a bit more detail? Should have read my post from earlier this week then 😁

Still here? Spaces are already half gone you know…

Lessons from LLNL in Supercomputing & AI - July 2026 - HPC CLUB

HPC Club event on CPUs, GPUs and silicon diversity. Join us for an evening of discussion and networking with industry experts. 26 November 2025 @ 17:00, Canary Wharf, London.

HPC CLUB

Chocolate and peanut butter. That’s how a friend likes to describe the worlds of HPC in academia and finance. Domains that feel completely distinct and that you perhaps wouldn’t think to combine, but actually, go together quite well!

Despite the very different technical starting points (classical MPI based supercomputing vs HTC on highly commoditised hardware) I see an increasing convergence of requirements and solutions. Since I’m already freely borrowing from the works of friends, I think what we’re seeing here is the convergent evolution of supercomputing across rather different domains.

I think, in large part, that is being driven by AI (and probably not for the reasons you think) but really, that process started before ChatGPT. More like 2008 or so with an increasing requirement around counterparty risk and other forms of portfolio risk calculation. This moved the game on from embarrassingly parallel compute to varying levels of additional complexity (depending on the bank) but essentially an acyclic graph of some form.

Increased AI adoption has significantly accelerated this convergence. Partly because running an LLM looks the same regardless of what your prompt contains. Partly because whilst banks used to enjoy a preferential status with technology suppliers due to their spend, these days unless you’re a hyperscaler or neocloud no one else comes close so academia and finance are more similar than different as far as big tech is concerned! And partly because, quite frankly, they always had more in common than first met the eye.

Both run shared supercomputers having to provide access to competing users. Both have surprisingly similar organisational and power structures. Both have compute that bottlenecks on IO before CPU even if they don’t like saying that out loud (and let’s be honest that’s been true for most supercomputing in the real world for a long time).

I’ve been trying to keep a foot in both worlds for a little while and I think it’s time that we put you all in a room together. The next HPC Club not only will we have Lawrence Livermore National Lab sharing their experiences but also a large hedge fund. Chocolate and peanut butter.

I’ll let you decide which is which.

Nothing for decades and suddenly tens of them come along at once. I think this must be the third week in a row that the interesting HPC/ supercomputing news is dominated by developments in silicon.

AWS has had Graviton for about 8 years, Microsoft Azure and Google Cloud both also decided to offer their own ARM based CPUs and even Meta has developed its own designs. Now ByteDance becomes the latest big tech company to plan to tape out its own custom chips. Though they are currently hedging their bets between it being an ARM or RISC-V architecture.

Meanwhile Phoronix has managed to get their hands on Nvidia’s Vera CPU. The selection of benchmarks results they’ve chosen is, shall we say, interesting. Not sure we’re likely to get our hands on any Vera kit any time soon to benchmark ourselves but we do currently have our mitts on some Intel CPUs and are considering if we include some of the Phoronix benchmarks in our analysis going forward. Specifically, the HPC related benchmarks and probably quanlib too. Maybe we should include SPEC too? All available for cloud or physical selection decisions via FLOPx.

A new startup, FuriosaAI, seems to have an alternative approach to accelerating inference, choosing to focus on high bandwidth data movement and tensor operations rather than a multitude of small cores. Sounds promising but modern GPUs sound awfully similar to that these days, no?

To address my concern from the previous two weeks about the difficultly in targeting multiple accelerator architectures it seems there are some people out there trying to solve this. I mean I kind hoped and assumed this would be case but hadn’t seen anything till last week in the form of ZML for one. I guess there may also be others, so if you know of any please do point me to them. I sincerely hope someone cracks this, not so much from a technical perspective, but more from a general adoption point of view.

TSMC seems to think efficiency might be the most critical metric its customers are now asking for. I’m actually surprised it took this long, given that the most bottlenecked resource seems to be the energy to power enough of these things. 

Lastly, we’re still hiring. We have open roles for both a HPC software engineer and marketing. Oh, and expect this to be the last issue of this newsletter branded as Quantum. A new look (but with the same content) coming next week!

In The News

Updates from the big three clouds on all things HPC. If you want the latest on AI too, just hit the buttons in the menu

Noteworthy by HMX Labs

 Silicon related shenanigans

https://www.reuters.com/world/china/bytedance-developing-custom-cpu-chips-support-ai-rollout-sources-say-2026-05-28/?utm_source=chatgpt.com

https://www.phoronix.com/review/nvidia-vera-benchmarks

https://www.hpcwire.com/2026/05/28/furiosaai-and-broadcom-team-up-to-build-rack-scale-inference-clusters/

An alternative to CUDA that works everywhere?

I think we broke the CUDA moat for good. Software built with ZML now runs transparently at max speed on: - CPU - NVIDIA GPUs - AMD GPUs - Google TPUs - AWS Trainium - Intel GPUs - Tenstorrent NPUs -… | Steeve Morin | 31 comments

I think we broke the CUDA moat for good. Software built with ZML now runs transparently at max speed on: - CPU - NVIDIA GPUs - AMD GPUs - Google TPUs - AWS Trainium - Intel GPUs - Tenstorrent NPUs - Apple GPUs (very experimental) That’s 8 different architectures. For instance, this screenshot is from 2 Intel GPUs working in Tensor Parallel mode, something Intel themselves only shipped in a very old vLLM fork. | 31 comments on LinkedIn

LinkedInSteeve Morin

ZML - Model to Metal

ZML is a production inference stack, purpose-built to decouple AI workloads from proprietary hardware.

ZML Logo

Is the focus finally going to change to efficiency too?

https://www.datacenterdynamics.com/en/news/energy-efficient-compute-is-most-important-attribute-for-customers-tsmc-claims/?utm_source=chatgpt.com

From HMx Labs

 New logo for this weekly newsletter incoming soon

Same Weekly Newsletter. New Name and Logo

I first started writing a weekly newsletter about HPC back in 2024. I figured it needed a name of some kind, but I didn’t really put much thought into it. I think I just Googled/ asked ChatGPT for some names that sounded cool. Wasn’t a great move as

Flux by HMx LabsHamza

Also we’re hiring not only for our marketing role but also an HPC software engineer now

Hiring: HPC Engineer

We’re looking for another HPC software engineer! Know someone that might be interested? Fancy pointing them my way please? This video was brought to you by the letters H, M and X and the number 42. Have a good weekend everyone. 0:00 /0:03 1× Apply on LinkedIn

Flux by HMx LabsHamza

Hiring: Marketing & Business Development

We’re looking for someone awesome to come help us shape the future of HMx Labs

Flux by HMx LabsHamza

Know someone else who might like to read this newsletter? Forward this on to them or even better, ask them to sign up here: https://cloudhpc.news

We’re looking for another HPC software engineer! Know someone that might be interested? Fancy pointing them my way please?

This video was brought to you by the letters H, M and X and the number 42. Have a good weekend everyone.

Apply on LinkedIn

HMx Labs hiring HPC Software Engineer in London Area, United Kingdom | LinkedIn

Posted 9:23:04 AM. Despite the big talk from the like Messrs Altman and Amodei and product hype from Codex and Cursor…See this and similar jobs on LinkedIn.

LinkedIn

Despite the big talk from the like Messrs Altman and Amodei and product hype from Codex and Cursor the reality is that AI still can’t do the job of a junior engineer. At least not at HMx Labs. So we’re hiring.

You’ll be working directly alongside senior engineers and be exposed not only to clients but also projects in HMx Skunkworks 😉  The role is entirely HPC focused with a particular focus on our financial services clients. The role is hybrid in nature (London based) but does not have set days in the office.

At this point we can all agree that hiring processes are pretty broken, so here’s the deal. We won’t use AI or CV parsing and keyword tools to sift through the applications if applicants only bother to apply if they meet the criteria below and ensure their CV and/or LinkedIn profiles actually showcase their skills in these areas.

Think you can do the job and want to impress or skip a step, just apply directly with a link to a completed HMx Labs tech test in your GitHub

Anyone applying with a recommendation from someone that has worked with HMx Labs goes to the top of the pile too.

What are we looking for?

• You must have the right to live and work in the UK indefinitely
• At least one year of experience working as a software engineer. Paid full time employment.
• Knowledge and commercial experience with at least one of the following languages: Java, C#, Python (with OO), C++
• Knowledge and some commercial experience of one non managed memory language
• Ideally some exposure to HPC
• Ideally some experience working in financial services technology
• You must have at least one of the two (HPC or financial services)

Let’s see how this goes. Applications on the LinkedIn job posting or by email to jobs@hmxlabs.io

If we get inundated with applicants that clearly don’t match any of the criteria above I reserve the right to break out the AI (or maybmaybe just bash and grep) 😁

Up to £60k/year for the right candidate.

Post 5 in a series on architecture-led cloud migration with Waltz. Earlier posts covered the case study, the argument for enterprise architecture before infrastructure, assessing cloud readiness across an application portfolio, and where AI and machine learning fit in Waltz-based migration planning. This post goes deeper into the dimension that most often determines whether a migration wave succeeds or unravels: dependencies.  And how AI agents working over the Waltz model make a dependency-aware wave plan continuously defensible rather than a quarterly artefact.

Ask any experienced migration lead what derailed their last programme, and you will get the same answer in different words. It was rarely the application they were moving. It was something connected to it that nobody had fully mapped; a regulatory feed, a downstream consumer, a shared identity service, a batch scheduler, a firewall rule protecting an integration nobody had documented.

Hidden dependencies are where cloud migration plans go wrong, and they are precisely what a dependency-aware wave plan exists to manage.

Why wave plans built on preference fail

The default approach to wave planning combines three things: team preference, application priority, and technical readiness. All three are reasonable inputs. None of them, individually or together, is sufficient, because none reflects the structure of the estate.

An application can be a business-priority that is technically ready, and championed by an enthusiastic team, and still be a poor first-wave candidate.  Why? because moving it creates operational risk to five other systems that are not ready, or because it consumes from a source whose migration is six months out. The opposite is also true: applications that look unattractive on every other dimension make ideal early movers if they happen to sit at the edge of the dependency graph, with nothing depending on them and nothing they depend on that is in scope.

A wave plan that ignores the dependency graph is, in effect, a plan built on the assumption that applications are independent. They almost never are.

What "dependency" actually means

The word covers a range of relationships with very different migration implications. A useful classification has three axes.

Direction. Upstream dependencies constrain when an application can move; downstream dependencies constrain how, because anything that breaks affects somebody else.

Type. Synchronous API calls behave differently from asynchronous messaging. Batch feeds behave differently from real-time integrations. Shared data stores behave differently from shared infrastructure. File transfers, shared identity, shared certificate authorities, shared scheduling, shared monitoring.  Each has its own implications for whether and how the relationship can be temporarily bridged during migration.

Strength. A hard dependency means the consumer cannot function without the producer. A soft dependency degrades gracefully. Hard dependencies force tight sequencing or costly bridges; soft dependencies create manageable re-establishment windows. The distinction decides whether two applications must move together, whether one can move ahead of the other, and whether either can move at all without first remediating the relationship.

Modelling and feeding the graph

In Waltz, dependencies are modelled as relationships rather than notes. That distinction matters, because relationships can be queried, traversed, and reasoned about across thousands of applications; notes cannot.

A Waltz deployment built for migration planning captures logical flows (what data moves between which applications), physical flows (how each logical flow is realised: Kafka, SFTP, REST), interfaces with versioning and ownership, shared infrastructure dependencies modelled explicitly, and data classifications including residency and regulatory attributes.

The model is only as good as the evidence behind it, and no single source captures the full picture. CMDBs know what was registered; application teams know what they think they have; batch schedulers know what runs in what order; firewall rules know what was permitted to talk; static analysis knows what is configured; tracing knows what runs under load; network flow telemetry knows what moved across the wire.

In our deployments we wire several of these directly into Waltz, so the graph refreshes as evidence changes rather than as workshops are scheduled. The architecture team becomes the curator of the model, not its author, which is the only sustainable posture for a graph that will need to support wave planning for several years.

The interesting work is the reconciliation. A connection in network flow data with no documented integration is a question. A documented integration never seen in traffic is a different question. A scheduler job nobody recognises is a third. These discrepancies are exactly where hidden dependencies live, and they are the first thing the AI agents we deploy against Waltz are designed to surface.

From graph to wave: three sequencing decisions

Once the graph is in place, wave planning becomes a small number of repeated decisions. The standard heuristics still apply, non-production before production, small early waves, business calendar awareness, simpler workloads first whilst the hyperscaler playbooks cover the operational mechanics in detail. What dependency-aware planning adds is the structural constraint underneath: the order of moves is determined by the shape of the graph, and any heuristic that contradicts it pays for the contradiction at execution time.

Independent movers. 

Applications whose neighbourhood in the graph is stable across the proposed migration window: no hard upstream dependencies mid-migration, no downstream consumers affected beyond what their owners have agreed. They build programme confidence, exercise the landing zones, and validate the operational model. They populate the early waves.

Move-together groups. 

Tightly coupled systems that share state through a database, exchange synchronous traffic at low latency, or participate in the same transaction boundary. A trading-system order manager and its risk engine. A reconciliation engine and its position store. These move together or they create avoidable risk. The graph's job is to make these groups visible during planning, before they assert themselves as emergency coordination problems.

Move-after constraints. 

Applications that can move independently but only after a specific upstream is in place. A reporting platform after its data sources have settled. A downstream consumer after its strategic upstream is generally available in cloud. The cost of ignoring move-after constraints is a fragile cross-environment connection that usually works, until it does not, at which point the incident is somebody's.

A worked example

Consider a Customer Reference Data Service (CRDS) sitting at the centre of a financial services estate. CRDS holds canonical customer master data, consumed by thirty downstream applications across trading, risk, reporting, KYC, and onboarding.

A naive wave plan would assess CRDS on its own merits: well-owned, business-critical, technically supported, an early-wave rehost candidate.

The graph tells a different story. Of the thirty consumers:

·      Twelve use synchronous calls and six of those are themselves planned for early waves. 

·      Eight read CRDS via a nightly batch extract; these tolerate a boundary period. 

·      The remaining ten use a queryable API with tolerance for seconds of latency variation 

o   except one that sits on a regulatory reporting critical path. 

·      The most important point of all: CRDS shares a database with the upstream onboarding workflow, which is itself a migration candidate. 

That is not a dependency; it is a move-together group with a remediation prerequisite (data store separation) before either can move.

The wave decision changes accordingly. CRDS is not an early-wave independent mover. It is the heart of a move-together group whose data store must be untangled first. Six synchronous consumers become move-after candidates. The critical-path regulatory consumer needs a specific bridge, a read replica in the cloud landing zone — or cannot be scheduled until CRDS has moved. The remaining consumers can be scheduled independently provided the batch and tolerant flows are maintained across the boundary.

None of this is visible from the application-level readiness rating. All of it is visible from the dependency graph.

How AI agents work the graph

The previous post in this series covered where AI and machine learning fit in Waltz-based migration planning at a high level. Dependency-aware wave planning is where that capability becomes most concrete, because the graph is a rich, structured artefact that benefits substantially from agentic reasoning. We deploy AI agents that interrogate the Waltz model through precise entity queries, analytical pattern-finding across the portfolio, and semantic similarity for concepts the structured model does not express and through personas do four kinds of work that human teams find expensive at portfolio scale.

Surfacing problems. 

Agents continuously compare the graph against the evidence sources feeding it. Where network flow telemetry shows traffic the logical flow model does not, where a scheduler job has no corresponding integration, where two systems share a database that neither application owner has acknowledged, the agent raises it as a question with the supporting evidence attached. 

The volume of such discrepancies in a large estate is what makes manual reconciliation prohibitive; agents make it tractable. They also surface structural risks the graph reveals but humans rarely think to look for: cycles, single points of failure with high downstream fan-out, cross-jurisdictional flows lacking documented controls, dependencies on infrastructure that is itself in scope for migration with no settled date. 

Some of the most useful problem-finding uses semantic similarity rather than structural traversal. Two applications whose metadata suggest they handle the same data, with no documented flow between them, are a hidden dependency the structured graph cannot surface but a semantic query can, these are precisely the cases that turn into late-stage migration surprises.

Providing recommendations. 

Agents do not only respond to questions. Given the graph and a set of stated migration objectives such as: 

1.        Minimise hybrid period 

2.        Prioritise a particular business line 

3.        Complete by a specific date 

4.        Avoid cross-jurisdictional traffic during transition 

They continuously evaluate the current wave plan against those objectives and raise findings when it drifts. Where they are asked for a new plan rather than a check on an existing one, the output is not "here is the answer". It is "here is a plan that satisfies these constraints, here is what it costs, and here is what it depends on", with the working shown. The agent's value is that it explores the option space at a scale and consistency human planners cannot, presents its choices in a form that can be challenged, and does so continuously rather than only when somebody remembers to ask.

Working in role. 

The same graph looks different to different stakeholders. 

·      An architect cares about structural risks  like cycles, fan-out, principle drift. 

·      A CTO cares about transformation status and timeline risk. 

·      A CIO cares about cost and vendor concentration in upcoming waves. 

Agents tuned to a specific role's concerns produce findings shaped for that audience, on a cadence appropriate to it.  For example, daily for operational hygiene, weekly for portfolio-level concentration, monthly for architectural principle drift rather than dumping the same raw analysis on everyone. Findings persist across runs, are deduplicated so the same concern is not raised three times, carry the provenance of every query and entity that produced them, and can be acknowledged, dismissed, or escalated. The result is that the wave plan is under continuous, role-appropriate scrutiny rather than waiting for the next steering group to surface its problems.

Drawing conclusions aligned with migration objectives. 

The harder and more interesting work is reasoning at the level of programme objectives rather than individual moves. An agent with access to the graph, the wave plan, the readiness assessment, and the stated objectives can answer questions that are otherwise hard to evaluate. For example:

·      Given current progress, which objectives are now at risk? 

·      Which sequencing decisions taken in earlier waves are constraining options now? 

·      If we accept a six-month delay on objective A, which dependencies become non-binding? 

·      Where in the plan is the irreversibility, the points beyond which retreat is expensive?

These are the questions migration steering groups try to answer in quarterly reviews. Agents working over the Waltz model make them continuously available, grounded in the architecture rather than in opinion.

The agents do not replace architectural judgement. They make architectural judgement enforceable at portfolio scale, by ensuring every wave decision is checked against the graph and every objective is checked against the wave plan. The architect's role is what it should be: directing reasoning, not performing reconciliation.

Hidden dependencies and foundational services

Even with disciplined modelling, some dependencies are reliably missed. They can hide: 

·      in connection strings and configuration files (often the most authoritative source of integration information, and also often the least documented)

·      in firewall rules that have been in place for years and that nobody can remember why 

·      in batch schedulers that encode the ordering operations actually relies on, in shared infrastructure too universal to feature in application diagrams

·      in implicit assumptions about latency, location, and time that behave like dependencies when they break, 

·      in operational dependencies: shared on-call teams, shared deployment pipelines, shared change windows  

None of the above are in any application model at all. When they fail, they fail in predictable ways: hidden upstream services left behind, identity or certificate mismatches, DNS changes applied out of order, third-party allowlists blocking changed source IPs, data synchronisation delays, broken timing assumptions. None of this is exotic. All of it is preventable, if the graph has been built well enough to see it coming.

Some applications themselves are foundational i.e. a reference data service consumed by half the estate, an enterprise scheduler, a strategic API gateway. The graph reveals them by their downstream fan-out. They sit in wave zero or a dedicated early wave; they are not interchangeable with the rest of the portfolio.

Bridges and the limits of sequencing

Not every dependency can be resolved by sequencing. Some applications have to move ahead of their dependencies for example, a data centre exit deadline, a strategic platform decision, a regulatory window. The dependency model does not block the move; it prices it.

The pricing is the cost of the bridge. Hybrid connectivity, read replicas, dual-write patterns, event mirroring, identity federation, temporary network extensions.  All are valid migration techniques, and all are operational debt for as long as they are in place. The wave plan should be explicit about which bridges are being built, what they cost to run, and when they will be retired. A bridge for six weeks during a planned wave is a reasonable migration cost. A bridge that becomes permanent because the downstream never moved is an architectural problem the migration created. The graph is what lets you tell the difference at planning time, when you can still do something about it.

What this changes

The argument running through this series is that cloud migration is fundamentally an architecture visibility problem. Dependency-aware wave planning is where that argument becomes most concrete, because the dependency graph is the single piece of architecture that most directly determines whether a wave succeeds or fails.

The change a dependency-aware approach enables is not a different list of applications or a different total migration timeline. It is a different basis for sequencing. Applications are scheduled because of where they sit in the graph, not because of who shouted loudest at the planning workshop. Move-together groups are recognised as units. Move-after constraints are respected. Bridges are designed deliberately rather than improvised under pressure. AI agents catch the discrepancies, propose the trade-offs, and check the plan against the objectives continuously, rather than letting all of this accumulate to a quarterly review.

In the case study estate this series builds on, the documented outcomes included faster prioritisation across a large and diverse portfolio, better sequencing of migration waves based on real dependencies, and reduced risk of disruption caused by hidden interconnections. None of those were achieved by adding effort to the programme. They were achieved by directing the same effort against a better-shaped problem.

The migration plan stops being a list of applications and becomes a sequenced traversal of an architecture model, supported by agents that keep the model honest and the plan defensible.

That is the difference between a wave plan that looks reasonable in PowerPoint and a wave plan that survives contact with execution.

HMx Labs helps organisations use Waltz, augmented with AI agents, to map dependencies, design dependency-aware migration waves, and build evidence-based migration programmes that survive scrutiny from architecture, delivery, and governance teams alike. If you are planning a large-scale migration and want to move beyond preference-led wave design, get in touch.