View in web for best experience
Summer is officially here. The solstice rolled through yesterday, June 21, handing the Northern Hemisphere its longest day of the year and the rest of us a little bonus daylight to pretend we'll use productively. (We see you, backyard grill. We respect you.)
But if you were hoping the industrial world would ease into a lemonade-on-the-porch kind of summer β sorry. It's going to be a busy week, and it kicks off today in Chicago, where Automate 2026 throws open its doors for four days of humanoids, autonomous mobile robots, and "physical AI" demos that look like the future showing up on a forklift. Great show. Bring comfortable shoes and a portable charger.
Here's the thing about a show floor, though: the flashiest thing in the booth is rarely the thing that actually changes your plant. While everyone's busy filming the robots, the news that really mattered this week happened down in the plumbing β the unglamorous foundation layer that quietly decides whether all this AI stuff survives contact with a real production line.
Two patterns ran through everything that crossed our desk. First, the industrial software and automation stack is consolidating fast β fewer companies are coming to own the tools you lean on every day. Second, the infrastructure that runs AI (the chips, and the orchestration layer sitting on top of them) is becoming the thing that separates "we ran a cool pilot" from "it's live on Line 3 and nobody's sweating."
So grab something cold and settle in. This week we've got a consulting giant swallowing a Siemens specialist, a storied industrial conglomerate cheerfully taking itself apart, Amazon's newest GPU muscle, and the open-source platform that became the default home for AI workloads while most of us weren't looking. None of it has a touchscreen. All of it matters more than the robot dogs.
Here's what caught our attention:
On June 17, Accenture agreed to acquire Industries eXcellence Group (IndX), one of the top integrators of Siemens industrial software. The deal says a lot about where Accenture is placing its bets β and those bets aren't necessarily aligned with yours.
The details:
- Accenture is buying IndX, a division of Italy's Engineering Group and a long-standing Siemens Digital Industries partner, with more than 650 specialists across Italy, the US, India, Germany, the rest of Europe, and Mexico. Accenture
- What they do: IndX builds digital-thread solutions connecting engineering, manufacturing, and automation across IT and OT β PLM (product lifecycle management), simulation, digital twins, SCADA, and industrial edge and cloud. Accenture
- Where it lands: IndX folds into the Accenture Siemens Business Group, formed last year, plus two new Siemens-focused Centers of Excellence in Italy and India. For scale: Accenture is a ~$70 billion, ~786,000-person consultancy. AccentureAccenture
Why it matters:
Two things are happening at once. First, the integration layer of the industrial stack is consolidating. Vendors make the software, but integrators are who actually make it work β and one of the best Siemens specialists just got absorbed into a global consultancy whose model rewards big, multi-year programs and AI-services upsell.
Second, and more telling: Accenture is doubling down on digital thread specifically. The company pitched the deal on combining IndX's Siemens expertise with its own AI capabilities β a clear signal of the architecture it intends to keep selling. Accenture
Here's the problem with that bet β for you.
Digital thread as a goal (connected data across the lifecycle) is fine. Digital thread as an architecture is the expensive part. The standard build wires every system to every other system, point to point β PLM to MES to ERP to SCADA β and that web of custom integrations sprawls, breaks, and racks up engineering hours every time you add a plant or swap a tool. It's brittle at scale, and it never stops costing money.
Which is precisely why it's such a good business to sell into. The complexity that drains your budget is the same complexity that fills a consultancy's. There's a leaner way to get the same connected data β a Unified Namespace, where systems publish to and subscribe from one central hub instead of all wiring to each other β but that's not the architecture Accenture just spent money getting better at.
If you're a Siemens DI customer, protect yourself:
- Ask whether the proposed design is point-to-point integration or a publish/subscribe model. The answer predicts your five-year cost.
- Pin down team and rate continuity now that IndX is Accenture, and lock scope and exit criteria so a rollout can't balloon.
- Keep architectural decisions in-house. Let the consultant execute β don't let them pick the approach that happens to bill the most.
The bottom line: Accenture optimized this deal for Accenture's revenue. Before you sign, make sure someone in the room is optimizing for yours.
Honeywell Is Breaking Up and Bulking Up. What It Means for Your Control Room.
Honeywell spent its June 11 investor day making two announcements that sound contradictory but aren't: it's selling off big chunks of itself and going shopping for more.
The details:
- Honeywell is targeting acquisitions in the $2β4 billion range, with industrial automation as the key area; its Industrial Automation chief, Peter Lau, pegged the addressable market at roughly $35 billion and called M&A opportunity plentiful β tightening earlier guidance that had run from $1 billion to $7 billion. Yahoo FinanceYahoo Finance
- Meanwhile, it's dismantling the conglomerate: Honeywell spins off its Aerospace business on June 29, spun out its advanced materials division as Solstice Advanced Materials last October, and has agreed to sell its Warehouse and Workflow Solutions and Productivity Solutions and Services units. Yahoo Finance
- The goal is a "pure-play" automation company β focused on one thing instead of a sprawling portfolio. (For scale, Honeywell's market cap sits around $139 billion.) GuruFocus
- Over recent years, roughly $14 billion has gone into about a dozen deals, most landing between $1 billion and $2 billion. The new target doubles the top of that typical range. Yahoo Finance
Why it matters:
This is the classic conglomerate-breakup playbook activist investors have spent the last couple of years pushing on Honeywell β and on paper, focus is good. A dedicated automation company may pour more into the automation roadmap than one also worried about jet engines and specialty chemicals.
But for customers, "portfolio transformation" is a polite term for churn. The Honeywell you signed a contract with is actively reshuffling what it owns. Units are being sold; new companies are being bolted on. The product line you depend on could change hands, change names, or change priority β and bolt-on acquisitions famously take years to actually integrate, no matter what the press release promises.
If you run Honeywell gear, do this:
- Get written roadmap and support commitments for your specific product line β not corporate-level reassurance.
- Track which units get divested. If your product lands in a sold-off business, your support and roadmap owner just changed.
- Treat new acquisitions as "prove it." Don't bet a project on freshly bought tech being integrated until you've seen it actually work.
- Keep your options open. Portfolio churn is exactly when you want negotiating leverage, not lock-in.
The bottom line: Honeywell is reorganizing for Honeywell's shareholders, and that's their right. Just remember: a company in the middle of buying, selling, and rebranding is a company whose roadmap promises deserve extra scrutiny.
AWS's New Cloud GPUs Are Fast. The Plant-Floor Caveat Is Bigger.
On June 18, Amazon switched on EC2 G7 instances, its newest cloud GPUs. The headline numbers are real. Whether they solve your problem is a separate question.
Quick primer: Training a model (teaching it from data) and running it β called inference, feeding it new data to get a prediction β are different jobs with different hardware needs. Most manufacturing AI (vision inspection, predictive-maintenance scoring, anomaly detection) is inference. These instances are tuned for exactly that.
The details:
- G7s are GPU-accelerated cloud servers for AI inference, graphics, and analytics, and AWS says it's the first major cloud to run NVIDIA's RTX PRO 4500 Blackwell Server Edition GPUs, paired with custom Intel Xeon processors. amazon
- Up to 4.6Γ faster AI inference and up to 2.1Γ faster graphics than the previous G6 generation, with 32 GB of memory per GPU. amazon
- Up to 8 GPUs per instance, 700 Gbps networking, and up to 7.6 TB of fast local NVMe storage β enough to keep big models and datasets right next to the compute. amazon
- They run on Kubernetes via Amazon EKS (more on Kubernetes in a minute) and are live now, but only in two regions: US East (Ohio) and US West (Oregon). amazonamazon
Why it matters for manufacturing:
This is real muscle for the heavy-lift side of industrial AI: training and fine-tuning your own models, running large vision or generative models, and GPU-accelerated analytics on big industrial datasets. The graphics gains matter too β AWS pitches these for spatial computing, video analytics, and VDI (virtual desktop infrastructure), which maps to digital twins, simulation, multi-camera inspection, and cloud-hosted CAD workstations for your engineers. amazon
The caveat β and it's a big one.
A faster GPU in Ohio does nothing for a decision that has to happen in five milliseconds on Line 3. The plant floor's hardest AI problems are usually about latency and data, not raw horsepower. If a model has to reject a defective part in real time, you want inference at the edge β on or near the machine β not a round trip to a cloud region two time zones away. Cloud GPUs shine for training, batch analytics, and simulation; they're the wrong tool for a tight control loop. Two more honest notes: 24/7 cloud inference gets expensive fast, and clean, well-structured data beats a bigger GPU every time.
Action items:
- Match each use case to the right place: latency-critical β edge; training, simulation, and big analytics β cloud GPUs.
- Going cloud? Check the region. Two US regions at launch means latency and data-residency considerations.
- Model the run-cost first. Around-the-clock inference is a recurring bill, not a one-time buy.
- Fix your data foundation before you rent horsepower. Faster silicon won't save messy, disconnected data.
The bottom line: Amazon just raised the ceiling on cloud AI compute β great for training, twins, and analytics. Just don't mistake a bigger cloud GPU for the answer to a plant-floor problem that's really about latency, edge, and clean data.
Read the full announcement β
Kubernetes Quietly Became the Home of AI. Does It Belong on Your Plant Floor?
We just mentioned running those new cloud GPUs on Kubernetes. Here's why that platform matters β and where it does (and doesn't) fit in an industrial setup.
What even is Kubernetes? Plain version: it's an open-source system that automatically deploys, scales, and manages software packaged in containers (portable bundles of an app plus everything it needs to run). Think of Kubernetes β often shortened to K8s β as a tireless scheduler for software: it decides what runs where across a fleet of machines, restarts what crashes, and scales up when demand spikes. A bit like how your MES coordinates work across the floor, but for applications.
The details:
- Kubernetes has gone from container orchestrator to the de facto platform for AI workloads. Per the latest CNCF (Cloud Native Computing Foundation) survey, 82% of container users ran Kubernetes in production in 2025, up from 66% in 2023. oreilly
- Around 66% of organizations now run generative-AI workloads on Kubernetes β including OpenAI, Tesla, Adobe, and Google. oreilly
- It's increasingly where agentic AI lives too, with agents moving from one-off demos to coordinated "fleets" managed on Kubernetes via new open-source tools like Kagent and Agent Sandbox. oreilly
Why it matters for manufacturing:
If your organization is deploying AI at any scale, odds are it's already running on Kubernetes somewhere β and that somewhere is increasingly the edge. Lightweight K8s distributions (like K3s) run on industrial PCs and edge gateways, so you can use one consistent system to push AI inference and apps to many machines across many plants, then update and monitor them centrally. For a multi-site operation, that "deploy once, manage everywhere" story is the real draw.
The reality check.
Kubernetes is powerful and genuinely complex β and the article is refreshingly honest about it. It singles out networking as one of the most fundamental and hardest K8s skills, notes that platform engineers and network admins each tend to know only half of what's needed, and points to a new CNCF certification for the Kubernetes network-engineer role to fill the gap. oreilly
Translation: this is a serious operational commitment, not a checkbox. K8s was born in cloud-native IT, and bringing it to the plant adds complexity an OT team may not be staffed for. And to be clear β it's not for real-time deterministic control. Your PLCs and safety systems stay put; Kubernetes is for the AI, analytics, and application layer, not the millisecond control loop. The best line in the piece is about fundamentals: chase the shiny agentic-AI-on-K8s stuff after you've nailed networking, security, and reliability. Same lesson as clean data and the right architecture β foundations first.
Action items:
- Find out where your AI workloads already run. "On Kubernetes" is a common answer, even if nobody's mentioned it.
- Don't adopt K8s for the buzz. Justify it with real scale β many workloads, many sites β or skip it.
- Budget for the skills gap. The networking layer is where these projects quietly stall.
- Keep it off the control loop. Data and AI layer, yes; deterministic real-time control, no.
The bottom line: Kubernetes became the default home for AI while most of the industrial world wasn't watching β and at the edge, it's a powerful way to run AI across every plant you've got. Just go in clear-eyed: it's a real commitment, and the foundations come first.
Learning Lens
This whole issue has been about one thing: AI that's powerful but ungoverned breaks things. So here's the natural question β if you wanted to build your own industrial AI tooling, how would you do it without becoming a cautionary tale? Walker Reynolds is teaching exactly that.
Agentic DevOps for Industry 4.0 β build your own industrial software with AI agents
Here's a number that should sound familiar after the last four articles: once an AI-built project hits critical mass, regression rates can climb past 50% β every new sprint breaking something that worked the day before. The code gets written fast, then collapses under its own weight.
Sound like the governance gap we've been hammering all issue? It's the same problem, scaled down to your own keyboard. And the fix is the same too: discipline, not more AI. Structured documentation as live context, defined agent personas, version control, and peer review β the DevOps scaffolding that's the difference between software that works once and software that holds up sprint after sprint.
What you'll actually do: Over two hands-on days, you'll stand up a complete agentic DevOps pipeline using Claude Desktop, Claude Code, and Cursor β then use it to ship a real Industry 4.0 tool to a private GitHub repo by the end of Day 2. The cohort votes on what gets built, so register early if you want a say in the product.
Who it's for: Engineers, integrators, and OT/IT pros β no software development background required. If you know Industry 4.0 (UNS, MQTT, edge/cloud, basic data flows), you're ready. Python is the default for Day 2, and you'll be guided through it.
The details:
- Dates: July 21β22, 2026, 9:00 AM β 1:00 PM CDT each day (live on Zoom, fully recorded)
- Instructor: Walker Reynolds β two-plus decades across steel, automotive, printing, and mining
- Price: $1,099 early bird (list $1,499) β or free with a Mastermind membership
- You keep: Lifetime access to the recording, plus the private GitHub repo and reference materials
If there's one takeaway from this issue, it's that AI on the plant floor lives or dies on the governance around it. This is your chance to learn that discipline by building with it β not by cleaning up after it.
Reserve your seat β Β· See the full workshop details β
Byte-Sized Brilliance
File this one under "everything old is new again." Long before GPUs, before Kubernetes, before anyone uttered the phrase "AI workload," the first machine ever programmed with punched cards wasn't a computer at all. It was a loom.
In 1801, a silk weaver in Lyon named Joseph-Marie Jacquard demonstrated a loom controlled by a chain of punched cards β hole or no hole, raised thread or not β the very on/off logic every computer still runs on, more than a century before the first electronic one. To show off the technique, weavers later produced a silk portrait of Jacquard himself so fine β a thousand threads to the inch, so subtle it deceived many who saw it into thinking it was engraved rather than woven. Rendering that single image took 24,000 punched cards, each with over 1,000 hole positions. That's on the order of 25 million tiny yes/no decisions to produce one picture β the 1839 equivalent of a JPEG, executed in silk.
The punch card didn't stay on the factory floor. Charles Babbage kept a copy of that woven portrait on his wall and intended to use the punched-card idea to deliver instructions to his Analytical Engine, widely considered the first design for a general-purpose computer. As Ada Lovelace put it, the engine would weave algebraic patterns the way the loom weaves flowers and leaves. Decades later, Herman Hollerith tabulated the 1890 U.S. Census on punched cards and founded the company that would become IBM. Every data center humming away today can trace its family tree back to a textile machine.
So next time someone insists the future of manufacturing is software, you can smile and tell them: it always was. The plant floor invented the program. We're just running it on faster hardware.
Let us know how we're doing! https://forms.gle/zSXrKTK9BNZ3BrpXA
Responses