❌

Reading view

The Diver Who Held Up a Cathedral With His Bare Hands — for Six Years, in Total Darkness

Winchester Cathedral covers roughly 53,800 square feet (about 5,000 square meters) of floor space, making it one of the largest cathedrals in Northern Europe. At 558 feet (170 meters) long, it’s also the longest medieval cathedral in the world. Neither the congregation nor the more than 365,000 tourists who visit each year to admire its […]

  •  

Prehistoric builders transported Devil's Arrows 11 miles

Stonehenge is the most famous example of megalithic architecture across Britain and Ireland, but there are plenty of others, including Calanais, Newgrange, and Avebury, as well as the Devil's Arrows. The latter is Britain's tallest standing stone alignment, yet little is known about the provenance of its stones. Scientists have confirmed that the stones came from a site 18 kilometers (11 miles) away, transported by humans rather than glacial movement, according to a paper published in the Proceedings of the Royal Society A: Mathematical, Physical and Engineering Sciences.

"Sites in southern England and Scotland receive considerable attention but monuments like the Devil's Arrows have remained comparatively understudied despite their significance," said co-author Jim Leary of the University of York. "We have now proved that Neolithic communities moved several 25-ton stones across Yorkshire, transforming a familiar site into an epic quest to create a sacred landscape."

Stonehenge has been the focus of recent chemical analyses identifying where all the stones that make up the structure came from, revealing that many originated in quarries a significant distance away. For instance, a 2019 study concluded that the 42 bluestones that make up the inner ring came all the way from western Wales. The outer layer of sarsen stones hails from much closer to home: Marlborough Downs, an area of round, grassy hills 25 to 30 km (17 miles) north of Stonehenge, which has the largest concentration of sarsen in the UK.

Read full article

Comments

© University of York

  •  

Hybrid graphene–MXene–WS₂ terahertz metasurface detects chikungunya virus via machine learning

Scientists have unveiled a computational design for a terahertz metasurface biosensor that combines five distinct materials—graphene, MXene, tungsten disulfide, gold, and copper—into a single multilayer architecture capable of detecting refractive-index changes associated with chikungunya virus infection. The study, published in Results in Optics by G. Arunachalam, A.R. Kalaiarasi, Giri.G. Hallur, and V. Parthasarathy, reports a numerically predicted sensitivity of 907 GHz per refractive-index unit, among the highest values reported for hybrid-material terahertz biosensors, and couples the electromagnetic design to an XGBoost machine-learning surrogate model that predicts sensor behavior with accuracies exceeding 99.8 percent.

Chikungunya virus is an enveloped, positive-sense single-stranded RNA alphavirus transmitted primarily by Aedes aegypti and Aedes albopictus mosquitoes. While mortality remains low, generally below 0.1 percent, the broader public health burden arises from severe polyarthralgia that can persist for months or even years in a substantial fraction of patients across tropical and subtropical regions. With no approved antiviral therapy or licensed vaccine currently available, diagnostic accuracy sits at the center of clinical management and transmission control. Yet existing diagnostic tools face significant practical constraints, particularly in point-of-care and field settings.

Serological methods such as enzyme-linked immunosorbent assay suffer from cross-reactivity with related alphaviruses, including Ross River and O’nyong-nyong viruses, reducing diagnostic specificity. Real-time reverse transcription polymerase chain reaction offers high sensitivity during the acute phase but depends on laboratory infrastructure, trained personnel, and controlled sample handling. Virus isolation in cell culture provides confirmatory results but requires biosafety level-3 facilities and extended processing time. These limitations have motivated the search for rapid, label-free sensing approaches capable of operating at clinically relevant concentrations in decentralized environments.

The new work turns to the terahertz band, spanning roughly 0.1 to 10 THz, which lies between microwave and infrared regions of the electromagnetic spectrum. Terahertz radiation is non-ionising, with photon energies in the millielectronvolt range, allowing interaction with biological samples without causing ionising damage. Crucially, terahertz waves couple to low-frequency vibrational and rotational modes of biomolecules such as proteins, nucleic acids, and polysaccharides, producing measurable spectral features that support label-free detection. Because biological media including blood plasma and viral suspensions exhibit refractive-index variations in this domain, differences on the order of 0.01 to 0.02 refractive-index units can shift resonance frequency and field distribution when coupled to resonant sensing structures.

The proposed sensor is built around a periodically repeated square unit cell containing two identical square resonators, 2000 nanometers on a side, coated with tungsten disulfide—a two-dimensional transition metal dichalcogenide with strong light–matter interaction, high carrier mobility, and excellent dielectric confinement. This layer localizes the electric field in the sensing region and increases the interaction volume between the resonant field and the surrounding analyte. A pair of concentric circular rings, 3200 and 3800 nanometers in diameter and functionalized with MXene, surrounds the resonators, enhancing electromagnetic coupling, promoting efficient charge transport, and strengthening plasmonic interactions between resonator elements. An outer gold ring, 6000 nanometers in diameter, serves as the main plasmonic resonator supporting strong localized surface plasmon resonances with low optical loss. The entire multi-resonant assembly is embedded within a monolayer graphene sheet measuring 14,000 by 14,000 nanometers, which acts as a broadband absorber and a high-mobility charge transport medium whose electrically tunable chemical potential allows dynamic, active control of the resonance characteristics. Copper elements woven into the architecture provide supplementary conductive pathways that reinforce current distribution and coupling among the hybrid resonators. The structure rests on a silicon dioxide substrate, chosen for its low dielectric loss and mechanical robustness, which preserves the resonance quality factor.

The authors stress that the multilayer design is compatible with established microfabrication techniques. Fabrication would begin with a cleaned silicon dioxide substrate, followed by polymer-assisted transfer of monolayer graphene and thermal annealing. Gold and copper resonators can be deposited through electron-beam evaporation or magnetron sputtering with lift-off patterning, MXene rings through solution-based deposition, and the tungsten disulfide layer through chemical vapor deposition or thin-film transfer. With a unit-cell dimension of approximately 14 micrometers, the required feature sizes fall comfortably within conventional photolithography capabilities, and because fabrication imperfections remain far smaller than the operating terahertz wavelength, moderate tolerances are expected to have only limited influence on the electromagnetic response. For biosensing, the graphene surface could subsequently be functionalized with chikungunya-specific antibodies or aptamers using EDC/NHS or pyrene-based linker chemistries.

The electromagnetic modeling, performed in COMSOL Multiphysics, reveals a pronounced resonance at 0.355 THz, where electric-field simulations show the strongest and most spatially extensive enhancement. Varying the graphene chemical potential from 0.1 to 0.9 electronvolts produced dramatic modulation of the transmission contrast, which increased roughly 36-fold at the highest bias, from less than one percentage point to more than 27 percentage points, while peak transmission remained essentially unchanged above 98.6 percent. This asymmetric response—stable maxima paired with strongly modulated minima—arises because increasing chemical potential enhances graphene’s intraband conductivity, deepening resonant absorption through stronger light–matter interaction. The sensor also demonstrated remarkable angular robustness, maintaining peak transmittance above 97.8 percent across incident angles from 0 to 80 degrees, an important tolerance for realistic deployment where normal incidence cannot always be guaranteed.

Geometric optimization identified an outer circular resonator radius of 2500 nanometers and a square resonator side length of 2500 nanometers as the dimensions that maximize resonance strength, driving minimum transmittance down to approximately 65 to 67 percent and signifying optimal electromagnetic confinement within the active sensing region. When evaluated across refractive indices from 1.33 to 1.39, a range encompassing reported values for healthy plasma (approximately 1.35 RIU), healthy platelets (1.39 RIU), chikungunya-infected plasma (1.33 RIU), and infected platelets (1.38 RIU), the optimized configuration achieved a maximum sensitivity of 907 GHz/RIU, a figure of merit of 18.519 RIU⁻¹, a minimum detection limit of 0.061 RIU, a sensor resolution of 55.178, and a refractive-index resolution of 0.001 RIU. In comparative benchmarks against recently reported graphene- and hybrid-material-based terahertz biosensors—including graphene/copper/aluminum, graphene/silicon dioxide, MXene–graphene–black phosphorus, and graphene-integrated copper–silver designs—the proposed architecture’s sensitivity exceeded most published values, reflecting the synergistic field confinement produced by the five-material stack.

The machine-learning component addresses one of the central bottlenecks in metasurface development: the computational cost of repeated full-wave finite-element simulations during structural optimization. The team trained an XGBoost regressor, an ensemble method based on gradient-boosted decision trees, on simulation data covering incidence-angle variation and circular-ring dimension variation, using stratified sampling with 80 percent of data for training and 20 percent held out for independent testing, alongside five-fold cross-validation and grid-search hyperparameter optimization. The model captured more than 99.7 percent of response variance on unseen data, with mean absolute percentage errors below 0.162 percent and prediction accuracies from 99.838 to 99.959 percent. Acting as a computational surrogate, the trained model enables rapid interpolation across the design space without sacrificing the fidelity of the underlying electromagnetic model.

The authors are careful to frame the work as a computational proof-of-concept rather than an experimentally validated diagnostic. The sensor detects changes in the local dielectric environment surrounding the resonators, not viral particles or nucleic acids directly, and refractive-index sensing alone cannot intrinsically distinguish chikungunya from other viruses with similar dielectric properties. Analytical specificity in practice will depend on surface biofunctionalization with chikungunya-specific recognition molecules immobilized on the graphene or gold sensing surface. Future work will focus on device fabrication, biofunctionalization, calibration with reference refractive-index standards, experimental validation with clinically relevant plasma and platelet samples, and systematic evaluation of selectivity against related arboviruses—steps that would transform this numerically validated platform into a practical tool for rapid, label-free infectious disease diagnostics in the field.

Subject of Research: Label-free terahertz metasurface biosensing for chikungunya virus detection using a hybrid graphene–MXene–WS₂–Au–Cu architecture with machine-learning-assisted optimization

Article Title: Hybrid graphene–MXene–WS₂ terahertz metasurface detects chikungunya virus via machine learning

Article References: Arunachalam, G., Kalaiarasi, A., Hallur, G., & Parthasarathy, V. (2026). Machine learning-assisted hybrid graphene–MXene–WS₂ terahertz metasurface biosensor for highly sensitive label-free chikungunya virus detection. Results in Optics, 25, Article 101149. https://doi.org/10.1016/j.rio.2026.101149

Image Credits: AI Generated

DOI: 10.1016/j.rio.2026.101149

Keywords: chikungunya virus detection, computational biosensor design, high sensitivity biosensors, hybrid graphene MXene WS₂, machine learning in biosensing, multilayer architecture, nanomaterial-based sensors, public health diagnostics, refractive index sensing, terahertz metasurface biosensor, virus diagnosis in field settings, XGBoost surrogate model

  •  

Why enterprises should start with on-site AI agents

When I talk to people about agents interacting with websites, the conversation almost always starts with perception: how does an agent “see” a page? Is it screenshots or the DOM or the accessibility tree? In my previous InfoWorld article, “Accessibility is the first-class interface for AI agents”, I argued that the accessibility tree is becoming an increasingly important interface between websites and AI agents. From there the conversation shifts to actuation, and to ways of making it less brittle, which let a site expose its own actions as callable tools instead of forcing an agent to guess at buttons and forms.

That conversation matters. But it leaves out a more consequential architectural question, one that determines who is accountable when an agent gets something wrong: where does the agent live?

There are three plausible homes for an agent that interacts with your business: on-site, in-browser and off-browser. Each one trades control for reach differently. Right now, much of the industry’s attention is focused on the two homes furthest from the business: browser extensions that co-browse alongside a user, and autonomous agents running in the cloud that talk to your APIs or drive a browser on their own.

I think that is the wrong place for most enterprises to start.

If you run a business with real compliance exposure, or a brand you cannot afford to have misrepresented, the pragmatic move is to build the agent that lives on your own site first and treat reach as a problem you solve later, on your own terms.

Reach without governance is a liability

The appeal of in-browser and off-browser agents is obvious. They promise discovery, scale and automation you do not have to build or maintain yourself. An off-browser agent can compare your prices against every competitor and keep working after your support team has gone home. A co-browsing extension can act inside a user’s already authenticated session without requiring any special integration on your side.

But an agent you do not control is still speaking for your business.

An off-browser agent talking to your APIs or scraping your DOM runs on a model you did not choose, follows guardrails you did not write and represents your brand in a conversation you cannot see. If it misquotes a price, misstates a policy or initiates a transaction that creates a customer dispute, the fact that the agent belonged to somebody else may not make the resulting problem disappear.

There is also a deeper security problem. Computer-use agents interact with untrusted content by design. Anthropic’s guidance for browser and computer-use agents notes that webpages and application interfaces can contain adversarial instructions and recommends scoped permissions, human confirmation for high-stakes actions, and monitoring of agent behavior. OWASP’s AI Agent Security Cheat Sheet goes further, identifying agent-specific risks including prompt injection, tool abuse and privilege escalation, data exfiltration and memory poisoning.

In-browser agents are a better deal, because a human is watching the same screen and can catch a mistake before it lands. But the model, the tone and the decision logic are still outside your hands. For  or any other regulated industry, that is not a risk to take lightly just to pursue reach you have not yet learned how to govern.

What you actually gain by building at home

An on-site agent is less glamorous than the idea of your product being discovered by roaming agents across the open web. But it is the only home where the business keeps full governance.

You choose the model. You define the guardrails. You decide the tone, the escalation paths and exactly what the agent is and is not allowed to promise a customer. Because the agent has direct access to your systems, it does not need to reverse-engineer your checkout flow as an outside agent would. It can be given your actual domain knowledge and your actual APIs.

That matters because enterprises have solved this problem before. They did not expose databases directly to the internet; they introduced APIs. APIs were not just about integration. They created contracts, authentication, auditing and policy enforcement. On-site agents represent a similar evolution. Rather than forcing an external agent to infer behavior from a user interface, a business can expose governed capabilities through tools with explicit contracts.

WebMCP is a promising step in that direction. It makes it easier for a site to publish actions an agent can invoke, instead of forcing the agent to guess at the page. The important shift is not that the agent can click a button. It is that every action becomes observable, policy-governed and replayable.

The Chrome team’s WebMCP Sports demo is a good preview of what this can look like done well: an on-site assistant calling the site’s own WebMCP tools, with every call visible in the chat log. That is not a black box you are hoping behaves. It is an auditable interaction, with named tools and defined contracts.

The three homes

The cleanest way to think about this is as a spectrum.

  • On-site. The agent lives on your website. You ship it. You own the model, the tools, the tone, the policies and the telemetry. It has first-party access to your systems and your workflows. The trade-off is reach: it is coupled to your site, and it is not meant to carry the user’s journey across the web.
  • In-browser. The agent lives inside the user’s browser session, usually as a co-browsing extension or a browser-integrated assistant. It benefits from the user’s logged-in state and can act with the user present. That gives it real reach and a strong human safety net. But the business does not control the model or the guardrails, and the agent can still misrepresent the brand.
  • Off-browser. The agent runs elsewhere — in the cloud, on a server or on a user’s local machine and reaches your business by talking to APIs or driving a browser remotely. This is the widest-reach model, but also the least governed from the business’s point of view. It may compare competitors, cross workflows and act at scale, but you do not control the experience.

None of these homes is inherently bad. They solve different problems. But if your first priority is governance, accountability and brand integrity, on-site is the right starting point.

Start with the governed interface

For teams deciding where to put their first investment, three moves make the difference between a real interface and a chatbot glued to a homepage.

First, ship the on-site agent as the authoritative interface, not a fallback. It should have first-class access to your own APIs and domain knowledge — the same systems your support team and checkout flow already use — rather than being handed a scraped version of your own page.

Second, instrument every tool call it makes. If your agent calls a WebMCP tool to check inventory or apply a discount, log it the way you would log an API call from any other client. That log is your audit trail, your debugging tool and eventually your evidence when a regulator or customer asks what happened.

Third, design for human escalation from day one. Even a well-governed agent should not make every decision autonomously. Build explicit handoff paths to human operators for ambiguous or high-risk situations.

Taken together, those choices turn an on-site agent into a governed interface rather than a novelty feature. That distinction matters. The first is something an enterprise can safely operate; the second is something it will eventually have to defend.

When agents start talking to agents

There is another reason to build the on-site agent first: the three homes are unlikely to remain isolated.

Imagine that a user’s browser agent arrives at an airline website. It already knows the traveler’s preferences, calendar constraints, loyalty programs and perhaps their budget. The airline’s on-site agent knows something completely different: routes, seat availability, fare rules, upgrade eligibility and the airline’s operational policies.

Why should the visiting agent reverse-engineer all of that from a website?

A more natural architecture may be for the two agents to communicate.

This is no longer purely hypothetical. The Agent2Agent (A2A) protocol is explicitly designed to allow independent agents built by different vendors and frameworks to discover capabilities, exchange information, delegate work and coordinate tasks.

In that world, the user’s agent brings intent and user context. The site’s agent brings domain knowledge and governed execution.

And suddenly the on-site agent’s limited reach does not look quite so limiting. It does not need to travel across the web if other agents can come to it.

The incentive problem nobody is pricing in yet

There is a harder question underneath the technical one: who does the on-site agent actually work for?

A visiting agent, co-browsing or otherwise, is acting on the user’s behalf. An on-site agent, however well-built, is the business’s employee. And the moment the two negotiate a discount, an upgrade or a substitution, that exchange stops looking like a neutral handoff and starts looking like a sales conversation with an AI on each side of the table.

That tension is going to matter.

Businesses building on-site agents now should design their guardrails with that scrutiny in mind, rather than treating “the agent decided” as a shield. Control is worth having. It is also a responsibility. And building the agent that answers to you is the only way to exercise it.

The first agent should be the one you can govern

The history of enterprise software suggests a familiar pattern. Organizations adopt new interaction models by first bringing them under their own governance. Internal systems become APIs. APIs become platforms. Platforms become ecosystems.

AI agents will likely follow the same path.

That is why I think the first agent your business builds should not be the one that can reach the entire web. It should be the one whose behavior you can understand, measure and improve. Once that foundation exists, expanding outward becomes an architectural choice instead of a leap of faith.

Reach is tempting. But for regulated and brand-sensitive businesses, control has to come first.

  •  

Why digital transformations still fail

The consulting firms told us this would be different. They arrived with slick slide decks, expensive vendor packages, and promises to revolutionize how we do business. Their message was clear: Digital transformation was no longer optional; it was existential. Companies that failed to adapt would be left behind and crushed by more agile competitors with cloud-native architecture and data-driven strategies.

That was back in 2020, when Boston Consulting Group released research showing that 70% of digital transformations failed to meet their objectives. The consulting industry rushed to publish its frameworks, maturity models, and proprietary methodologies. Enterprise IT organizations spent millions on these programs, hoping to finally bridge the gap between technological capability and business value.

Several years on, I can say that little has changed. If anything, the issue has worsened.

The damage that was done

Most digital transformations didn’t just fail to deliver ROI; they actively damaged the organizations that undertook them. Technical debt accumulated as companies deployed monolithic cloud platforms that were neither modular nor scalable. Business misalignment became endemic as transformations focused on technology for its own sake rather than on solving actual business problems. Organizations found themselves locked into expensive vendor relationships that failed to deliver on their promises.

I’ve spoken with dozens of enterprise CIOs and CTOs over the past several years, and the stories are remarkably consistent. Transformations that were supposed to take six months stretched to two years. Budgets estimated at a few million exploded to six, eight, even twelve times the original projection. The consulting firms had excellent PowerPoint skills, but when it came to implementation, the results were consistently disappointing.

The damage wasn’t just financial. Organizations lost confidence in their IT capabilities. Talented people left because they were tired of being managed by consultants who couldn’t code their way out of a paper bag. Business stakeholders grew cynical about technology initiatives, having been burned too often by projects that promised transformation but delivered chaos.

Why the consulting models failed

Let’s be direct about what happened. The consulting industry discovered that digital transformation was highly profitable. They could sell their methodologies, vendor partnerships, and “best practices” frameworks, and charge premium fees for implementation support. The problem was that these frameworks were largely one-size-fits-all approaches disguised as bespoke solutions.

A major global bank doesn’t have the same requirements as a regional healthcare provider, yet both were sold the same transformation playbook. The consulting firms had invested too heavily in their methodologies to admit that the real answer might be to start with business requirements and work backward toward technology. Instead, they assembled prepackaged solutions optimized for vendor partnerships rather than clients’ actual needs.

The talent problem was equally severe. The consulting firms could certainly talk about digital transformation; they had excellent slides and compelling narratives. But when it came to implementation, the skill gaps were glaring. These organizations assembled solutions by following playbooks rather than understanding how the technology components actually fit together. The result was systems that were overengineered, overprovisioned, and ultimately underperforming.

Cloud computing was supposed to be the great enabler, but many organizations misunderstood and misapplied it. Organizations lifted and shifted their existing problems along with their existing architecture. Monolithic applications running on expensive virtual machines became the new normal, with organizations paying cloud costs that far exceeded their on-premises expenses, yet achieving none of the scalability benefits the cloud was supposed to deliver.

What we still need to learn

As we grapple with the next wave of technology transformation—this time centered on artificial intelligence—the lessons from digital transformation failures should be front and center. The first and most important lesson is brutally simple: Focus on business needs first. I know this sounds obvious, but I guarantee you that every failed digital transformation project lost sight of its core business requirements. They built technology for technology’s sake without understanding the problems they were trying to solve.

Too many transformations focused on individual business units rather than enterprisewide strategies. The result was a collection of systems that couldn’t work together cohesively. Isolated solutions felt like progress but actually made integration harder and created new dependencies that hadn’t existed before.

Organizations also need to invest in serious training for their people. I’m not talking about sending IT staff to vendor certification programs that teach them to pass tests on proprietary platforms. I mean fundamental architectural education that helps people understand how to assemble technology effectively.

We face a massive shortage of AI, cloud, and security architects, as well as other technical leaders who can design solutions that work. Rather than addressing this gap, organizations are placing unqualified people in these roles and hoping for the best. It’s past time to invest in education.

The case for simplicity

Here’s something that also should be obvious but clearly isn’t: You can solve the same business problem with $1 million or $20 million, depending on the sophistication of the IT organization building the solution. Both designs will work reasonably well, but one solution costs 20 times more because it is overbuilt and overengineered.

Organizations are adding AI to everything under the sun, even when simpler solutions would work just as well. They’re overprovisioning cloud resources because they lack the architectural discipline to rightsize their infrastructure. They’re building systems designed for scale they’ll never reach, complexity they don’t need, and features no one requested.

The path forward requires a minimalist approach. Build systems that are good enough for their intended purpose. Focus on requirements rather than capabilities. Resist the temptation to adopt every new technology just because it’s available.

Digital transformation didn’t fail because the technology was flawed. It failed because we forgot that technology exists to serve the business, not the other way around. To succeed with AI, we need to remember that fundamental truth. And remember the consulting industry’s tendency to sell us expensive solutions to problems we don’t have.

  •  

MacVoices #26247: Adam Engst on How AI Lets Non-Programmers Follow Professional Software Development (2)

Our conversation with Adam Engst continues with an exploration of  how AI can help non-programmers build sophisticated software by following professional development practices. Adam explains using specifications, architecture documents, and AI-guided decisions to create reliable apps, then examines the approach his app, SetShot, takes to macOS settings, privacy, security, user feedback, Cloudflare, GitHub, and minimizing sensitive data collection. 

💾

💾

  •  

The Foundations of the Lost Hospedería of the Catholic Monarchs Found in Guadalupe

Excavations carried out during the past month of July in the monumental complex of Guadalupe (Extremadura, Spain) have brought to light the foundation remains of the former Hospedería of the Catholic Monarchs (Guesthouse of the Catholic Monarchs), a lost historic building that has nothing to do with the current Hospedería del Real Monasterio that operates […]

  •  

Le bois change de dimension : pourquoi l'Europe en fait un matériau stratégique

Constructions à faibles émissions, bioéconomie, stockage certifié du carbone... Longtemps perçue comme une industrie de tradition, la filière bois européenne va changer d’échelle pour prendre une place prépondérante dans la transition écologique.

  •  

Three concepts cloud architects overlook

After two decades of cloud architecture consulting, I see an unchanging pattern in enterprise deployments. Organizations approach me with unexpectedly high cloud bills, operational chaos, and architectures that look good on paper but cause headaches in production. The common thread is almost always the same. Fundamental concepts that should be foundational to any cloud deployment are treated as optional or ignored altogether.

I’m not talking about exotic requirements, bleeding-edge technologies, or vendor-specific best practices. Basic engineering principles are somehow getting lost amid the excitement of cloud adoption. I wish I could say it’s rare, but after working with organizations across industries and geographies for years, I can confirm that missing these fundamentals is more common than most people realize. The results are predictable. Bills grow faster than business value, architectures require constant firefighting, and teams are stretched too thin to optimize anything.

The good news? You don’t have to start over, but you do have to go back to basics. Here are three concepts most cloud architects overlook that will make your architecture dramatically more valuable and efficient.

Identifying common ground

When deploying heterogeneous architecture, especially in multicloud environments, organizations must aggressively reduce silos. This means establishing common control planes for security, governance, and operations. You won’t get there by relying on whatever proprietary technology each cloud provider offers out of the box. Each provider wants you locked into their way of managing things. That is fine for simple deployments, but when you are running across multiple clouds and on-premises systems, proprietary control planes introduce redundancy, complexity, and cost.

You need a single control layer that spans your entire environment. Instead of managing 10 different security solutions from 10 different providers, you have one. Instead of separate identity management systems for each cloud, you need one that works everywhere. This eliminates the need to change security parameters in five different consoles, maintain five different skill sets for five different operational models, and reconcile five different governance frameworks. The common control plane ties everything together.

This might sound hard, but it’s not as bad as you think. (I will cover the specific patterns in a future article.) The real issue is that most architects have never been trained to think this way. They were taught to select the best services from each provider rather than abstract away the differences. This fundamental gap costs organizations real money every single day.

Cost observability and optimization

Most architects treat cost visibility and optimization as afterthoughts, things that can be bolted on after the architecture is in place. That backward approach shows up in the results. Without cost observability and optimization baked into your architecture from day one, you cannot understand where your money is going, where waste is accumulating, or where you should make changes to align expenses with delivered value.

The more complex and heterogeneous your environment, the more critical this becomes. You need a unified cost observability layer that spans public and private clouds and your own infrastructure. This is about building a layer that aggregates cost data from everywhere, provides a single source of truth for spending, and delivers the insights needed to actively optimize. Without this, you are flying blind, making decisions based on incomplete data and discovering problems only after the invoice arrives.

Too many organizations fail to gain control of their cloud spending because their billing data is scattered across multiple consoles, with no way to correlate usage across providers. They cannot see which teams, projects, or services are driving costs. They miss opportunities to right-size, consolidate, or eliminate waste. You cannot improve what you cannot measure. Without a common cost observability and optimization layer built into your architecture, you will never achieve the efficiency the cloud was supposed to deliver.

Consider the human element

Here is an uncomfortable truth most architects do not want to discuss: The more complex your architecture is, the broader the range of skills you will need to keep it running. Complexity requires expertise, and expertise requires hiring, training, and retention. If your architecture demands 15 different skill sets to operate, you’d better have a plan for finding and retaining the people with those skills.

I have seen beautifully designed architectures fail because the organization could not meet hiring requirements. They compromised by hiring underqualified individuals, which led to operational failures, security gaps, and mounting technical debt. The architecture itself was sound. The human infrastructure around it was not. This is a solvable problem. It starts with acknowledging that you are not designing for yourself. You are designing for the team that will inherit this system after you have moved on to your next assignment or promotion.

The solution isn’t just simplifying architecture, though that should be a goal. The key is to consider human factors in your design. What skills are required? How can you find and train people? What cultural changes are necessary for effective operation? These questions are essential; ignoring them risks failure.

The simple bottom line

I understand why most cloud architects miss these basic principles. No single course or book brings all of this together in one place. Cloud architecture has become a collection of best practices, vendor recommendations, and conference talking points, rather than a disciplined engineering discipline focused on business value.

As a result, architectures end up optimized in the wrong places, if they are optimized at all. They are expensive to run, difficult to secure, and nearly impossible to operate at scale without constant intervention. The cloud promises efficiency, yet we are not delivering it because we have lost sight of the fundamentals.

It’s time to go back to basics. Commonality, human factors, and cost observability and optimization are the three things that separate architectures that create value from those that create cost. Incorporate these concepts into your architecture and you’ll get ahead of most production systems in use today.

  •  

Bentham Science Launches International Journal of Wireless and Communication Engineering Innovation

Bentham Science Launches Two New Journals to Accelerate Research in Wireless Communications and Engineering

Bentham Science Publishers has announced the launch of two new peer-reviewed journals designed to capture the rapid transformation of modern technology: Wireless and Communication Letters and Current Engineering Letters and Reviews. Both publications are now open for manuscript submissions, offering researchers an international platform to share emerging discoveries in communication systems, engineering technologies, and interdisciplinary innovation. The launches arrive as advances in artificial intelligence, sixth-generation wireless networks, satellite systems, advanced materials, and sustainable engineering continue to reshape scientific research and industrial development.

Wireless and Communication Letters is focused on the technologies that enable today’s increasingly connected world. The journal will publish original letters, full-length research articles, comprehensive reviews, mini-reviews, and guest-edited thematic issues addressing both theoretical developments and practical applications. Its scope covers the complete communication chain, from antennas and radio-frequency hardware to signal processing, network architecture, cybersecurity, and intelligent software. By emphasizing the efficient dissemination of research, the journal aims to provide a rapid channel for findings that could influence the next generation of wireless infrastructure.

The technical challenges addressed by the journal are central to the future of digital connectivity. Fifth-generation networks have already introduced high-speed mobile broadband, ultra-reliable low-latency communication, and massive machine-type connectivity, but researchers are now investigating 6G systems capable of supporting even greater data rates, extremely precise sensing, and seamless integration with artificial intelligence. These systems may combine terahertz frequencies, reconfigurable intelligent surfaces, distributed antennas, edge computing, and advanced machine-learning algorithms. Such technologies require new approaches to spectrum allocation, energy efficiency, network coordination, and data security.

The journal also welcomes research on the Internet of Things and machine-to-machine communication, areas in which billions of sensors and devices are expected to exchange data with minimal human intervention. In these environments, communication protocols must operate reliably despite limited power, unpredictable radio conditions, and enormous numbers of connected nodes. Research into low-power wide-area networks, intelligent scheduling, network virtualization, and secure device authentication could help support applications ranging from industrial automation and smart cities to remote healthcare and environmental monitoring.

A further component of the journal’s scope involves the physical science of communication. Antenna design, electromagnetic propagation, microwave engineering, optical links, and satellite communication determine how information travels through real environments. Engineers must account for obstacles, atmospheric conditions, interference, polarization, bandwidth limitations, and the movement of users or spacecraft. Developments in compact antennas, beamforming, optical wireless communication, and satellite-terrestrial integration could improve connectivity in rural regions, disaster zones, transportation systems, and future space missions.

Wireless and Communication Letters is led by Editor-in-Chief Dr. Nasimuddin of the Antenna and Optical Department at the Institute for Infocomm Research in Singapore. Supported by an international editorial board, the journal states that it will apply a rigorous and objective peer-review process. This is particularly important in a field where theoretical claims must often be tested through simulations, prototypes, channel measurements, or performance comparisons. Research involving modulation, coding, information theory, cognitive radio, software-defined networking, artificial intelligence, privacy, and communication protocols will be considered within the journal’s broad technological remit.

Alongside the communications title, Bentham Science has introduced Current Engineering Letters and Reviews, an interdisciplinary journal intended to connect research across the full spectrum of engineering sciences. Announced on 3 August 2026, the journal will publish research articles, short communications, comprehensive reviews, mini-reviews, and thematic issues. Its mission is to bring together discoveries that are often separated into specialist fields, reflecting the reality that many modern technologies emerge from collaboration among mechanical, electrical, materials, chemical, biomedical, environmental, and computer engineers.

The new engineering journal will cover aerospace, civil, structural, transportation, manufacturing, energy, robotics, automation, nanotechnology, artificial intelligence, and digital engineering. It will also address sustainable engineering, renewable energy systems, smart materials, advanced manufacturing, and biomedical technologies. These subjects are increasingly connected: an electric vehicle, for example, depends simultaneously on materials science, power electronics, software, communications, manufacturing, and transportation engineering. An interdisciplinary publication can provide a forum for examining such systems as integrated technological platforms rather than isolated components.

The scientific importance of this approach is becoming more visible as engineers confront challenges involving climate change, resource efficiency, resilient infrastructure, and automation. Renewable energy systems require improved storage, power conversion, and grid management; smart materials can respond to changes in temperature, pressure, or electromagnetic fields; and artificial intelligence can optimize industrial processes by identifying patterns in large streams of sensor data. At the same time, engineering research must demonstrate reliability, scalability, safety, and economic feasibility if laboratory innovations are to produce measurable benefits in society and industry.

Both journals invite contributions from researchers, engineers, scientists, academics, and industry professionals worldwide. Bentham Science says that information about open-access policies, article processing charges, waiver eligibility, editorial policies, and complaints and appeals procedures is available through the respective journal websites. With their emphasis on rapid communication, technical rigor, and interdisciplinary exchange, the two publications seek to become new hubs for research at the intersection of connectivity, intelligent systems, sustainable technology, and engineering innovation.

Subject of Research: Wireless communications, communication engineering, interdisciplinary engineering research, emerging technologies, artificial intelligence, sustainable engineering, and advanced technological systems.

Article Title: Bentham Science Launches Two New Journals to Accelerate Research in Wireless Communications and Engineering

News Publication Date: 3 August 2026 (for the announcement of Current Engineering Letters and Reviews; no publication date is provided for Wireless and Communication Letters).

Keywords

Wireless communications, 5G, 6G, Internet of Things, satellite communications, antenna design, signal processing, artificial intelligence, engineering research, sustainable engineering, robotics, renewable energy, smart materials, advanced manufacturing.

  •  

A cloud deal too good to be true

The model of the forward deployed engineer is sweeping through enterprise IT like a gold rush, and I’m concerned that many companies don’t understand what they’re signing up for.

Let’s start with the headline numbers. AWS announced a $1 billion investment in a new Forward Deployed Engineering organization. Google Cloud committed $750 million to expand similar programs. Microsoft has been running Azure-focused embedded engineering teams for years, including partnerships with Accenture to scale forward deployed engineering practices. All three are pitching the same story: We’ll send engineers to work directly with your teams, help you deploy AI, and accelerate your digital transformation. You get top-tier technical talent for free, and we get to partner with you on your journey.

It sounds reasonable on the surface. It sounds collaborative, even generous. But I’ve been in this industry long enough to know that when a multi-billion-dollar company offers you something for free, they’re sure to get much more than they give.

What you actually get

The forward deployed engineer model isn’t new. The consulting industry has been doing some version of it for decades. What makes this different is the scale and the direct financial incentive behind it.

These engineers work for the cloud provider. They’re not your employees. They’re not independent consultants. They’re technically excellent professionals who are being paid to solve your immediate problems while simultaneously building relationships and architectures that favor their employer’s ecosystem. Think about it from their perspective. Those forward engineers are evaluated on whether customers succeed with their employer’s platform. They’re rewarded when enterprises adopt more services from that platform. Their career advancement depends on making AWS, Google Cloud, or Microsoft Azure the obvious choice for all of your technical decisions.

This isn’t a criticism of the individual engineers. Many of them are genuinely talented and genuinely want to help. But they’re operating within a system that rewards specific outcomes, and those outcomes align with the vendor’s financial interests, not necessarily yours.

The problem no one talks about

Here’s what I see happening at enterprises right now. A company decides they need help deploying AI. A cloud provider offers to embed engineers at no additional cost. Those engineers work alongside internal teams, make architectural recommendations, and help build out systems. Six months later, the company has a production AI system running on a single cloud platform, built by people with deep expertise in that specific platform.

The problem? Nobody evaluated whether that platform was actually the best choice for the business. Nobody looked at alternatives. Nobody asked whether a multicloud architecture or best-of-breed approach might deliver better results at lower cost.

The engineers embedded in these programs are not going to recommend that you split your workloads across providers. They’re not going to suggest you use open source tools where they make sense. They’re not going to point you toward a competitor when their employer’s solution will work well enough. That’s not how these programs are designed to function. What you’re getting is optimized architecture for a single cloud brand, not optimized architecture for your business.

The financial reality will hit

The bills are going to come due, and they’re going to be painful. I’ve watched this pattern play out before. When enterprises lock into a single cloud provider through these embedded engineering programs, they often discover two or three years later that they’re paying premiums that their more independent-thinking competitors avoided.

The reasons are straightforward. When you’re architecting systems around a single platform, you naturally fall into usage patterns that favor that platform’s pricing structures. You use their managed databases instead of portable alternatives. You adopt their AI services instead of evaluating third-party options. You build workflows that only work within their ecosystem. And when it comes time to renegotiate or benchmark against alternatives, you find that migrating would cost more than accepting whatever pricing they offer.

I’ve spent the past decade helping companies untangle from these situations. I’ve seen organizations with cloud bills 15 to 20 times higher than they should be, unable to migrate because their entire AI infrastructure is built on proprietary services that only work on one platform. The forward deployed engineer programs are accelerating this problem. They’re making it easier to get into these situations and harder to get out.

Think before you commit

Before you accept one of these programs, consider these three recommendations.

First, require independent architecture oversight from day one. Hire or engage architects who work for your company, not for your cloud provider. They should evaluate every recommendation made by embedded engineers against business requirements and compare options across providers. This isn’t about being suspicious of the engineers. It’s about ensuring that decisions are made with your interests in mind.

Second, demand a clear exit strategy before you begin. Ask the cloud provider to document which proprietary services you’re using, what migration paths exist, and what the cost would be to move to an alternative platform. If they can’t provide that information, or if the migration costs seem impossibly high, that’s a sign that you’re building technical debt that will be very expensive to service later.

Third, benchmark your costs continuously. Set up internal processes to compare your cloud spending against industry benchmarks and against what your competitors might be paying for similar workloads. Don’t wait until your contract renewal to discover that you’re paying premium prices. Monitor expenses from the beginning, and be willing to challenge your cloud provider if you’re not getting value that justifies the cost.

The bottom line

The forward deployed engineers are solving real problems. Enterprises genuinely struggle with AI deployment, and having experienced engineers available to help is valuable. I’m not suggesting these programs are fundamentally bad. However, they’re being marketed as neutral partnerships when they’re actually strategic sales programs designed to lock enterprises into specific platforms. The helpful engineers showing up at your office are building dependencies that will be very difficult to break. The “free” technical assistance is being funded by margins on services you’ll be buying for years.

Go in with your eyes open. Use these programs but add your own independent oversight. Build architectures that you could leave if you needed to. And don’t let the immediate satisfaction of having problems solved today blind you to the financial consequences that will arrive tomorrow.

  •  

Europe’s cloud sovereignty push may backfire

The European Commission’s latest push to reduce dependence on foreign technology providers is not surprising. If Europe believes that critical digital services could be disrupted by foreign governments, foreign legal systems, or foreign-owned providers, it will, of course, respond. That concern is now being expressed in the language of “kill switch” risk, meaning the fear that the cloud, AI, or semiconductor services that Europe depends on could be interrupted or constrained by forces beyond its control.

At a high level, that concern is valid. Europe is right to worry about strategic dependence. If critical public services, regulated workloads, or national-interest systems rely on infrastructure controlled elsewhere, sovereignty becomes more than a policy slogan. It becomes an architectural issue. However, I am skeptical of the leap from identifying the problem to assuming that a policy response will produce a cleaner, safer, or even more sovereign market. There is a good chance it may do the opposite.

What Europe is trying to protect

The motivation behind this effort is clear. Europe wants to reduce its dependence on cloud computing, artificial intelligence, and semiconductors from providers it does not fully control. It wants to ensure that core digital services cannot be switched off, legally constrained, or strategically influenced from outside the region. That is the public policy objective, and from a government standpoint, it makes sense.

The problem is that cloud markets don’t often respond to political intent as policymakers hope. The public cloud market is concentrated among a few big providers because scale matters. The hyperscalers have built global infrastructure, extensive services, ecosystems, and operating models that smaller regional players can’t match. Enterprises chose them for operational advantages, not geopolitical reasons.

Europe now finds itself in a difficult position. It wants sovereignty, but it also wants the benefits of scale, reliability, feature depth, and cost efficiency that usually come from very large cloud providers. Those goals do not always align.

Sowing enterprise confusion

One likely outcome of this push is that European enterprises will become increasingly confused about which public clouds they should select or avoid. That is not a minor point. Most enterprises already struggle with cloud strategy when the drivers are technical, financial, and operational. Add political sovereignty requirements, and the market becomes even harder to navigate.

Enterprises will now need to ask a more complex set of questions. Is a US-based hyperscaler with a localized European operating model acceptable? Is a European-branded sovereign cloud built on American technology better? Is a regional provider safer simply because it is smaller and local, even if it offers fewer services, weaker security tools, less resilience, and a less certain long-term future? At what point does “sovereign enough” become a legal or political judgment rather than a technical one?

This is where the market gets muddy. Policy discussions often imply a binary distinction between foreign and sovereign. In reality, cloud architectures are full of hybrids, partnerships, licensing arrangements, embedded dependencies, and supply chain layers, making neat categorization difficult. Enterprises do not buy cloud services based on a political slogan. They must navigate stacks of contracts, services, support structures, compliance obligations, and technical capabilities. The more politics enters that decision process, the less clarity there may be for buyers trying to make rational platform choices.

Sovereign clouds may not fix things

There is another reality that I think policymakers underestimate. Increased investment in sovereign cloud providers does not automatically create a durable sovereign cloud sector. In fact, history suggests the opposite.

Governments and enterprises may push investment toward smaller sovereign providers, but those providers still face the same brutal economics of the cloud market. They need capital, scale, customers, engineering depth, and ecosystem gravity. Many smaller providers will struggle to compete over time. Some will fail. Others will narrow their focus. Many will eventually be acquired, directly or indirectly, by larger players, including the very US-based cloud providers Europe is trying to reduce dependence on.

That’s the irony. Political pressure may spark a burst of sovereign cloud activity, but market gravity tends to reward scale. Sovereign cloud investment may create a temporary diversification, but in the long run, it could still end in concentration.

Sovereignty is not a bad goal, but the cloud business is structurally difficult. Running a competitive cloud platform is expensive. Matching hyperscaler capabilities is even harder. Enterprises eventually notice the gaps in services, AI tools, ecosystem support, geographic resilience, and operating maturity. When they do, they drift back toward the biggest and most capable providers.

Fragmentation comes before security

My concern is that Europe may be entering a period when cloud architecture is driven less by technical fit and more by political signaling. That rarely leads to simplicity. It usually results in fragmented strategies, duplicated platforms, inconsistent governance, and long procurement cycles.

Some organizations will choose a sovereign-first model for political reasons. Others will remain with hyperscalers but add contractual and architectural safeguards. Others will adopt a multicloud approach purely to avoid appearing overly dependent on one provider. Still others will split workloads by regulatory sensitivity, which sounds sensible until integration costs and operational complexity add up.

This is how confusion mounts. The question shifts from “Which platform best supports my workload?” to “Which platform is politically safest this quarter?” That is not a stable architectural framework.

Skeptical but attentive

I understand exactly why Europe is raising this issue. No responsible government wants critical digital services held hostage by external dependencies. That concern is rational, but rational concern does not guarantee rational market outcomes. My skepticism is not about whether digital sovereignty matters. It does. But can policy alone produce genuine long-term autonomy or will it create a more confusing procurement environment? At the same time, the market will quietly continue to consolidate around the largest global platforms.

The uncomfortable truth is that sovereignty is easier to announce than to implement. Cloud sovereignty is especially difficult because cloud markets reward scale, capital, ecosystem strength, and breadth of services. Those forces do not disappear simply because a regulator seeks more regional control. I think this issue will become more important over the next few years as cloud, AI, and geopolitical power become even more tightly linked. Europe is right to ask hard questions about dependence. But the answers are likely to be messy, and market outcomes may not look as sovereign as policymakers hope.

I don’t expect to see a clean break from foreign cloud providers. I do expect more hybrid arrangements, more sovereign branding, more enterprise uncertainty, more investment in regional providers, and eventually more consolidation than many people currently anticipate. That is not a failure of the idea. It is just the reality of how cloud markets tend to work.

The real challenge for Europe is not identifying the risk. It is building a response that does not create more confusion than the problem it is trying to solve.

  •  

Cloud at 20: How AWS shaped enterprise IT

It is tempting to date cloud computing from the launch of Amazon S3 in 2006 and the rise of infrastructure as a service (IaaS) that followed. That was certainly the moment the market changed in a visible, irreversible way. But the truth is that cloud began earlier, in the 1990s, when software as a service (SaaS), application hosting, managed services providers, and various forms of remote subscription computing started to reshape how enterprises thought about owning and operating technology. Even then, the core value proposition was familiar: Let someone else run the infrastructure, abstract the complexity, deliver capability as a service, and allow the business to consume only what it needs.

What AWS changed was the scale, accessibility, and precision of the execution. Amazon turned infrastructure into a programmable utility. It made compute and storage available in ways that were elastic, self-service, API-driven, and globally reachable. That was the breakthrough. Enterprises had outsourced pieces of technology before, but now they could rent raw infrastructure with unprecedented speed and flexibility. The launch of Amazon S3 was especially important because it provided a durable, scalable storage foundation that became one of the building blocks for modern digital business.

AWS changed everything

Technology markets are rarely transformed by the first company to think of an idea. They are transformed by the first company to make that idea operationally real, economically viable, and broadly consumable. AWS did exactly that. It built a model for infrastructure as a service that allowed enterprises, startups, and eventually governments to rethink the entire life cycle of IT delivery.

Looking back from 2026, it is difficult to remember how radical this concept once seemed. At the time, many enterprise leaders considered public cloud too risky, too immature, too uncontrolled, or simply too foreign for conventional IT governance. There were concerns about security, compliance, vendor dependency, performance, data residency, and reliability. Many of those concerns were valid. Early cloud adoption often ran ahead of cloud maturity, and many organizations discovered that moving quickly did not always mean moving wisely.

Still, the economics of agility overwhelmed the inertia of the old model. Provisioning that once took months could be done in minutes. Capital expenditure gave way, at least in part, to operating expenditure. Experimental workloads became easier to justify. Digital businesses could scale without building data centers first. AWS led that transition, and the rest of the industry followed, including competitors that helped mature the market.

Cloud’s strengths and liabilities

If the first decade of cloud was about acceleration, the second decade was about correction. Enterprises learned that cloud was not automatically cheaper, not automatically simpler, and not automatically better. It was better when used with discipline. It was more cost-effective when architected intelligently. It was more resilient when governance, operations, and security were designed into the system rather than added later.

This is when the industry grew up. We learned about cloud financial management because too many organizations assumed elasticity would control cost, only to discover that unused resources, poor workload placement, and fragmented accountability could drive spending far beyond expectations. We learned that public cloud could provide extraordinary innovation and reach, but also that not every workload belongs there. Latency, sovereignty, compliance constraints, legacy integration challenges, and predictable high-volume workloads all forced a more nuanced view.

We also learned about concentration risk. As enterprises standardized on a small number of hyperscalers, questions emerged around resilience, lock-in, and strategic dependency. The answer was never simplistic multicloud posturing for its own sake. It was architectural realism. Use the public cloud where it creates a clear advantage. Keep options open where business risk requires it. Understand portability, but do not romanticize it. In other words, cloud became less ideological and more practical.

Cloud is now an assumption

Perhaps the most important shift of all is that we no longer debate whether cloud is real or whether enterprises should use it. That argument is over. Cloud is baked into the cake. It is part of enterprise operating reality. The modern enterprise assumes on-demand infrastructure, platform services, automation pipelines, managed databases, identity fabrics, observability stacks, and globally distributed application delivery. Even when workloads remain on-premises or at the edge, they are often built, governed, or operated with cloud-native thinking.

This is maturity. Cloud is not a project or a trend. It is not even a strategy by itself. It is an enabling model that now underpins enterprise strategy. Businesses no longer ask whether to adopt cloud in the abstract. They ask how much cloud, which cloud services, under what governance model, at what cost profile, and in support of which business outcomes.

That may sound less exciting than the early days of disruption, but it is actually the mark of success. The most powerful technologies eventually disappear into standard practice. Electricity, networking, virtualization, and mobile platforms all went through this process. Cloud has done the same.

How cloud supports the AI race

As enterprises move aggressively into AI, cloud has entered another pivotal phase. AI is not replacing cloud. It is intensifying the importance of cloud while also changing how value is measured. Training, tuning, deploying, and governing AI systems require immense computational scale, specialized infrastructure, distributed data access, and operational consistency. Public cloud providers are well positioned to offer those capabilities, particularly with GPUs, AI platforms, managed model services, and data integration tools.

But this is not a repeat of the early cloud era. Enterprises are more sober now. They know the importance of cost, latency, and data gravity. They know that governance and accountability matter more in AI than perhaps anywhere else in modern IT. The role of cloud in the AI race is therefore foundational, but not absolute. Some AI workloads will run in public cloud. Some will be distributed across edge computing environments. Some will remain in private environments for reasons of sovereignty, economics, or control. The key is not to force a universal answer. The key is to create an architecture that aligns AI ambitions with operational reality.

Cloud should play the role it has gradually earned: not as a religion, but as a strategic utility. For AI, the cloud is where many enterprises will source scale, experimentation speed, global reach, and managed innovation. The winning organizations understand where cloud creates leverage and where other operating models make more sense.

Changing how enterprises think

The real story of the past 20 years is not just that AWS launched S3 and helped popularize infrastructure as a service. It is that cloud changed enterprise behavior. It normalized service consumption over asset ownership. It moved architecture toward abstraction, automation, and modularity. It forced IT organizations to broker capability rather than build everything from scratch. It redefined speed as a core competitive requirement.

And now, as AI becomes the next forcing function, cloud stands less as a novelty and more as the platform on which the next era will be built. That is a remarkable outcome for something that, in many ways, started with the old idea that computing could be delivered remotely on a subscription basis. We have been heading here for longer than many people realize. In the past two decades, led in large measure by AWS and the broader hyperscale movement it accelerated, cloud has evolved from a gamble to an indispensable foundation.

Hard to believe? Yes. But also inevitable in retrospect.

  •  

Decoding Human Language Neurons with AI

In a groundbreaking study that redefines our understanding of how language is encoded in the human brain, researchers have mapped the diverse landscape of neurons distributed across frontal and temporal cortical regions, revealing a complex yet lateralized neural architecture for human language processing. By leveraging advanced single-neuron recording techniques alongside sophisticated language models, the team has identified not just the locations but the nuanced encoding properties of neurons implicated in various linguistic computations. This work illuminates how language, a uniquely human faculty, is instantiated at the neuronal level with precision and regional specificity.

The study’s comprehensive neuronal recordings spanned key brain areas historically associated with language, including the frontal cortex, anterior temporal cortex, and posterior temporal cortex. These regions were chosen given their established roles in speech production and linguistic comprehension, as well as their demonstrated selective responses in prior localized brain imaging studies. Importantly, the neurons examined were broadly distributed across both hemispheres and these cortical regions, showcasing the widespread neural substrate involved in language tasks.

One of the seminal findings was that roughly half of the neurons, 289 out of 579, exhibited selective responsiveness to one or more linguistic features. Intriguingly, this selectivity was evenly distributed across the three cortical sites — frontal, anterior temporal, and posterior temporal — and did not significantly differ between the left and right hemispheres. This suggests a foundational neural scaffold where language-related computations recruit a multitude of neurons across large-scale networks rather than isolated hotspots, emphasizing distributed processing over modular localization.

However, beyond this broad distribution, the study uncovered striking lateralization and regional differentiation in the strength and informational content of neural modulation. Neurons within the left hemisphere exhibited significantly stronger modulation—quantified by their z-scored activity changes—in response to linguistic features compared to their right hemisphere counterparts. This enhanced sensitivity encompassed a range of linguistic elements, including lower-order features like pitch, underscoring the superior role of the left hemisphere in detailed linguistic encoding.

Further dissecting these lateralized effects across cortical regions revealed that the posterior temporal cortex showed the most pronounced difference in left-right modulation strength, significantly outperforming other areas. This aligns well with the notion that posterior temporal areas are central to decoding complex linguistic dependencies and syntactic structures, functions critical for fluent language comprehension and production.

Conversely, the prefrontal cortex displayed the strongest overall neuronal modulation to these language features, both in the left and right hemispheres, compared to temporal regions. This finding suggests a hierarchical and possibly integrative role for the frontal cortex in orchestrating language processing, perhaps linked to higher-order syntactic planning, working memory, or executive control mechanisms required for natural speech.

The neural predictivity analysis, leveraging embeddings from cutting-edge contextual language models, further corroborated the lateralized and regionalized pattern. Neural activity in the left anterior temporal cortex was most accurately predicted by these language model features, highlighting this region’s role in abstract linguistic representation and semantic integration during language tasks.

Methodologically, the study capitalized on the precise temporal resolution of single-neuron recording combined with sophisticated statistical analyses, including permutation and rank-sum tests, to quantify neuronal response selectivity and modulation. This rigorous approach afforded a fine-grained characterization of how individual neurons adapt their firing patterns to various syntactic and prosodic elements of language in real-time.

Collectively, these data challenge conventional notions that neural language processing is confined to narrowly defined “language centers.” Instead, the findings advocate for a model of language representation as a widely distributed but regionally specialized system with marked hemispheric dominance. This has profound implications for understanding the neural basis of language disorders, suggesting that therapeutic interventions might need to consider both distributed network integrity and hemispheric targeting.

Moreover, the study’s integration of naturalistic language models with neurophysiological data marks a pioneering step in computational neuroscience, bridging theoretical frameworks of language with tangible neural mechanisms. By showing how models trained solely on linguistic input can approximate neuronal responses, this research points toward a future where artificial intelligence and neuroscience synergistically unravel human cognition.

Importantly, the results underscore the unique neural architecture supporting language that has evolved in humans, outstripping earlier simplistic models focused on gross anatomical mapping. These advances set the stage for future investigations that might explore how these neuronal populations interact dynamically during complex language tasks such as conversation, narrative comprehension, or bilingual processing.

In conclusion, this landmark research paints a detailed, high-resolution portrait of the neuronal building blocks underpinning human language. It reveals an exquisitely lateralized and regionally differentiated system whereby distributed neurons collectively encode the multifaceted features of speech. Such insights not only deepen fundamental neuroscience but also hold promise for novel clinical interventions and computational linguistic advancements.


Subject of Research: Neuronal encoding of human language features across frontal and temporal cortical regions; lateralization and regional differentiation of linguistic processing in the brain.

Article Title: Mapping the neuronal building blocks of human language with language models.

Article References:
Cai, J., Kfir, Y., Jamali, M. et al. Mapping the neuronal building blocks of human language with language models. Nature (2026). https://doi.org/10.1038/s41586-026-10691-5

Image Credits: AI Generated

DOI: https://doi.org/10.1038/s41586-026-10691-5

  •  

Revolutionary Atom-Thin Coating from NUS CDE and Applied Materials Partnership Breaks New Ground in Chip Miniaturization

In the relentless quest to push the boundaries of semiconductor technology, researchers from the National University of Singapore (NUS) in collaboration with Applied Materials have unveiled a groundbreaking advancement that promises to reshape the future of microchip manufacturing. As the global semiconductor market races towards the trillion-dollar mark propelled by demand for faster computing, smarter artificial intelligence, and more compact electronic devices, addressing fundamental physical constraints in chip architecture has become a critical imperative. A newly developed atom-thin coating — a monolayer of crystalline tungsten disulfide (WS₂) — presents a transformative solution, elegantly overcoming a pressing bottleneck in chip miniaturization with profound implications for speed, reliability, and efficiency.

Traditional transistor miniaturization has long driven performance gains in integrated circuits. However, as transistors and their connecting copper wires shrink into the sub-10 nanometer regime, the surrounding protective layers—essential for maintaining electrical integrity—resist further reduction. These layers, typically tantalum-based barrier and liner materials, must maintain a minimum thickness of around four nanometers. In future nanoscale interconnects, these coatings may consume nearly half the cross-sectional area of the copper wiring, severely throttling electrical conductivity and device speed. The NUS and Applied Materials team’s innovation resides in synthesizing an ultrathin WS₂ film, less than a nanometer thick, that simultaneously fulfills the dual role of barrier and liner, drastically slashing thickness without compromising performance.

This pioneering coating, grown on industry-standard 200-millimeter silicon wafers using a low-temperature thermal atomic layer deposition process at 350 degrees Celsius, exemplifies a remarkable confluence of scalability and compatibility. The process avoids plasma, guaranteeing conformal deposition with precise thickness control down to a single atomic layer. Notably, this method achieves uniform coverage in high aspect ratio trenches, exceeding 95% conformity even at depth-to-width ratios of 10:1. Such attributes position this WS₂ monolayer as a viable drop-in replacement within existing semiconductor fabrication lines, bridging the formidable divide between laboratory breakthroughs and industrial applicability.

The WS₂ film’s threshold thickness of approximately 0.7 nanometers contrasts starkly with the conventional six nanometer standard, enabling a future 20-nanometer-wide copper wire to retain over 90% of its conductive cross-section. This relatively unobstructed copper path translates into reduced electrical resistance and elevated current carrying capacity, directly enhancing chip speed and energy efficiency. Extensive electrical testing demonstrated a monumental reduction in resistance—exceeding a factor of one million—compared to uncoated counterparts. The superior adhesion properties offered by the WS₂ liner promote smooth and continuous copper film formation, vital for producing reliable, defect-free interconnects at such ultrathin dimensions.

Beyond adhesion, the WS₂ monolayer serves as a robust diffusion barrier that impedes copper migration into silicon and dielectric materials under thermal and electrical stress. In accelerated aging tests, conventional barrier-free copper rapidly reacted with underlying silicon, forming deleterious intermetallic compounds and defect clusters. In stark contrast, WS₂-coated samples exhibited no such degradation, maintaining pristine interfaces even after prolonged exposure. Remarkably, devices using the atomically thin barrier exhibited projected lifetimes surpassing unprotected designs by an order of magnitude, signaling a dramatic leap in device durability.

Central to the WS₂ film’s efficacy is its polycrystalline structure composed of myriad tiny grains and grain boundaries arranged in random orientations. Unlike continuous single crystals, where aligned grain boundaries can form direct diffusion channels, the staggered grain orientation in multilayer WS₂ films creates a complex labyrinth that frustrates copper atom penetration akin to the staggered offsets in a well-built brick wall. This insight, derived from computational modeling by NUS chemists, identifies nanoscale grain architecture as a key parameter in optimizing barrier functionality, challenging the entrenched paradigm that perfect crystallinity is always advantageous.

The discovery that a single atomic layer can supplant the combined barrier and liner stack confronts long-held assumptions in semiconductor interconnect design. Prior industry standards dictated separate layers with cumulative thicknesses of several nanometers to provide necessary protection and adhesion. By collapsing these essential roles into an atomically thin WS₂ sheet, researchers open new vistas for continuing Moore’s Law scaling into unprecedented regimes. Professor Silvija Gradečak, co-director of the NUS-Applied Materials Corporate Lab, emphasizes that this fundamental shift in approach heralds a new class of interconnect architectures tailored to atomically precise materials engineering.

The process’s compatibility with low thermal budgets—vital for avoiding damage to complex multilayer device stacks—and its wafer-scale uniformity underscore its readiness for integration into contemporary manufacturing ecosystems. These breakthrough properties allow semiconductor producers to adopt WS₂-based coatings without extensive equipment overhauls or processing disruptions, facilitating rapid technology transfer. Dr. Hippolyte Astier highlights that such advancements transcend the immediate generation of chips, positioning the industry to harness this technology across multiple forthcoming innovations extending out to 2037 and beyond.

Applied Materials’ Director of Engineering, Dr. John Sudijono, notes the criticality of merging academic ingenuity with industrial constraints through the Corporate Lab framework. The collaborative environment enabled iterative validation of WS₂ films under realistic fabrication conditions, ensuring the material meets demanding reliability, scalability, and process compatibility benchmarks. This convergence of theory, experimentation, and commercialization is essential to bridging the notorious gulf between laboratory demonstrations and full-scale production deployments in semiconductor manufacturing.

Looking forward, the team is exploring refined control over WS₂ grain orientation and microscopic interface phenomena to fine-tune long-term stability and electrical behavior. Further studies aim to exploit the low-temperature vapor-phase growth technique to deposit other two-dimensional materials within diverse chip components, expanding the scope of atomic-scale coatings in integrated circuit design. This foundational research not only sets a new standard for interconnect barriers and liners but also signals the inception of a broader materials revolution in microelectronics.

The ultrathin WS₂ monolayer innovation thus represents a monumental stride towards sustaining the pace of semiconductor evolution. By ingeniously combining barrier and liner functionality into a single atomic layer with industrially scalable fabrication, this discovery resolves a pressing miniaturization bottleneck, empowering the continuation of chip performance scaling in an era where every nanoscale dimension counts. As the semiconductor industry confronts the ultimate physical limits of transistor and interconnect shrinking, atomically precise materials like WS₂ will be vital enablers of future computational breakthroughs, underpinning the technology transformations of tomorrow.

Subject of Research: Not applicable

Article Title: Low-temperature wafer-scale growth of ultrathin tungsten disulfide for bifunctional interconnect barriers and liners

News Publication Date: 31-Mar-2026

Web References: https://doi.org/10.1038/s41928-026-01592-6

Image Credits: College of Design and Engineering, NUS

Keywords

Semiconductors, Microelectronics, Materials engineering, Materials science

  •  
❌