Over the past five years, America has committed hundreds of billions of dollars to building and modernizing critical infrastructure. From the Infrastructure Investment and Jobs Act and CHIPS and Science Act to the more recent Rural Health Transformation Program, federal investments are reshaping the networks, facilities, and systems communities will depend on for decades.

Across the country, state and local leaders are making consequential decisions about where to direct infrastructure investment, how to maximize the value of existing assets, and how to ensure today's investments support the services communities need.

At Ready, we've had an unusual vantage point into that work. Our software helps governments plan, administer, and oversee more than $14 billion in federal infrastructure investment across 30 states and territories. Working alongside the institutions managing these investments has given us firsthand insight into how infrastructure decisions are made, the challenges institutions face, and the needs emerging as their programs advance.

That work has brought a recurring gap into focus: critical institutions and services need near-cloud and access infrastructure. They need computing, data, and connectivity close enough to support the work happening locally, and practical ways for people and critical systems to use those capabilities.

A broadband connection can reach a hospital, school, or public safety facility without giving it everything it needs to deliver dependable digital services. 

Three lessons from our work have shaped how we think about closing that gap.

Lesson 1: Existing investments reveal what needs to be built next

State broadband offices have spent years building a detailed understanding of their states' digital infrastructure. Through BEAD and other programs, they've mapped connectivity gaps, evaluated existing networks, and developed relationships with the institutions responsible for serving their communities.

What Broadband Directors Must Know About AI Infrastructure

, the knowledge and capabilities developed through these programs can inform infrastructure decisions long after the original funding is spent.

But working alongside these institutions has revealed something else: the needs that emerge as investments take shape don't always fit neatly within the programs that brought them to light.

A state may begin by identifying where broadband is missing and discover that connected communities still lack access to essential services. A public institution may have reliable connectivity but lack the equipment, computing capacity, or operational support to put it to greater use. It may also depend on distant systems for records, applications, and other capabilities that become unavailable when the connection fails.

Our work with state broadband offices began with software to help governments manage complex infrastructure programs. But working closely with those institutions revealed needs that software alone couldn't address. Closing those gaps requires physical infrastructure, an operating plan, and a buyer able to fund and sustain it. That is why we moved down the stack into Hypercube, access infrastructure, and the services needed to deploy and maintain them.

The experience has reinforced something I believe is particularly important for infrastructure founders: identifying an unmet need is only the beginning. Understanding how institutions make decisions, secure funding, procure solutions, and sustain them over time is what turns an opportunity into infrastructure that delivers lasting value to the people who depend on it.

Lesson 2: Critical services need more than a broadband connection

One of the clearest lessons from our work is that meeting the objectives of an infrastructure program doesn't necessarily mean communities can access the services the investment was intended to support.

, I described the near-cloud as a shared layer of compute, data, connectivity, and AI capability close to the people and critical systems that need it. Connecting a facility is one milestone. Giving it the local capacity to run useful services and keep essential functions available is another.

Consider a rural hospital. Broadband may connect clinicians to remote systems, but continuity during a network outage could require selected patient records, an application, and a sign-in process that remain available locally. As I explored in 

What Happens When the Cloud Is Unreachable?

, nearby computing only helps if the other dependencies needed to use it remain available too.

That requirement is shaping Hypercube: a purpose-built modular data center that brings compute, storage, and multiple connectivity options closer to critical institutions. Built from first principles, Hypercube is designed to house the local infrastructure that hospitals, public safety agencies, utilities, and other institutions need. The workloads and supporting systems must be configured around each mission, including what needs to keep working when remote services cannot be reached.

People also need places and equipment that let them use the services this infrastructure supports.

Oklahoma offers a concrete example of investing in the access infrastructure a broadband connection alone doesn't provide. Building on its broadband investments, the Oklahoma Broadband Office 

 in trusted institutions, creating private, connected spaces where residents can access remote healthcare, workforce support, education, and other services.

Oklahoma shows how an existing investment can reveal the next missing piece and lead to a funded decision. Portals address the human access requirement. Hypercube addresses the local computing and connectivity requirement. Both start with what an institution needs to deliver a useful service.

Lesson 3: Plan for long-term operation from the start

One of the most important lessons we've learned is that building infrastructure and operating it successfully are two very different challenges. A solution that works in one location may become difficult to manage across hundreds of sites, particularly when the institutions hosting it have entirely different responsibilities.

For near-cloud infrastructure, deployment is the beginning of an operating obligation. Someone must monitor equipment, maintain power and cooling, keep software and data current, and respond when something fails. A hospital or public safety agency needs a clear plan for who carries those responsibilities alongside its existing teams.

The experience has reinforced the importance of designing for deployment and long-term operation from the beginning. Technology, monitoring, maintenance, and support must be consistent enough to scale, while installations accommodate the realities of individual locations.

For Hypercube, that means designing the physical infrastructure, BOSS monitoring and management, and Ready Services deployment and lifecycle support together. Site conditions and workloads will vary, but each installation should build on a repeatable approach to configuration, maintenance, and support.

The ability to operate and maintain a system at scale is as important as the ability to build it. Infrastructure investment should account for both from the outset.

A new standard for infrastructure investment

These three lessons lead to three questions for America's next generation of infrastructure investment:

Answering those questions requires looking beyond individual projects to understand how infrastructure, institutions, and services work together.

Working alongside the institutions responsible for those investments has convinced me that the next buildout must bring dependable capability closer to where it is needed. Hypercube is our response to the missing near-cloud infrastructure. Together with access infrastructure, it can help turn America's existing investments into services people and critical systems can use and depend on, in blue skies or gray.

Working alongside governments overseeing more than $14 billion in federal infrastructure investment across 30 states and territories has revealed a critical lesson: building infrastructure is only the beginning.

Discover lessons from managing $14B in infrastructure investment, from broadband expansion to delivering essential services and building for long-term impact.

What Working Inside America's Infrastructure Investment Taught Us | Ready.net

What comes after billions in infrastructure investment? These are the lessons from Ready's work with government institutions on turning funded projects into lasting services and identifying the next infrastructure opportunities.

What Working Inside America's Infrastructure Investment Taught Us

What Working Inside America’s Infrastructure Investment Taught Us

When someone arrives at a hospital in need of emergency care, doctors need answers quickly. What medications is the patient taking? Are there existing medical conditions? What did the latest tests show? Much of that information is stored in electronic health records, often accessed through services that depend on infrastructure outside the hospital.

But a hospital can lose access to those records even when the cloud services supporting them are operating normally. All it takes is a failure in the network connecting the hospital to those services.

For a rural emergency department, losing that connection could mean suddenly losing access to medication histories, allergies, and recent test results. Staff turn to downtime procedures, potentially working with incomplete records, making phone calls, or documenting care on paper until access is restored.

Hospitals have long prepared for such disruptions. But more essential services now depend on interconnected digital infrastructure, from medical imaging and laboratory systems to pharmacy operations. AI adds another layer of dependence. Hospitals already use AI to interpret medical images, review patient information, and identify patients at risk. As AI becomes part of more everyday decisions, losing access may mean losing a capability clinicians rely on to deliver better care. 

As more essential services rely on cloud infrastructure, operators must plan for three conditions:

A working network doesn't guarantee a working service

, I introduced four standards for infrastructure: Accessible, Buildable, Capable, and Dependable. 

Dependable asks whether a service can continue when supporting infrastructure becomes unavailable. Some functions should remain operational at a reduced level rather than allowing the entire service to stop.

A hospital doesn't necessarily need every feature of its electronic health record to remain operational during an outage. It needs clinicians to retain access to enough reliable information to treat patients safely.

That distinction changes how resilience should be evaluated. A backup server may be functioning, but clinicians could still lose access if authentication depends on an unreachable service. A secondary network connection may offer little protection if both routes share the same upstream dependency.

Operators must begin with the service they need to deliver and trace everything required to make it work: data, applications, authentication, computing, devices, connectivity, electricity, and the people and procedures supporting them.

Then comes the critical decision: What is the minimum acceptable service during a disruption?

For the hospital, the requirement might be access to essential patient histories, medication information, and allergies throughout a four-hour connectivity outage, even if electronic ordering and other functions remain unavailable. Clinical leaders would need to determine which records are essential, how current they must be, and what alternative procedures are safe.

Once those requirements are defined, infrastructure investments can be evaluated against what the service actually needs.

Three operating conditions for dependable service

Cloud and local infrastructure can work together to preserve essential functions when remote systems become unreachable. For more sophisticated services, a backup connection or stored records may no longer be enough. Continuity may also require local networking, computing, and eventually AI models that can run without reaching a distant facility.

For a rural hospital, one illustrative approach would maintain selected patient information locally, allowing clinicians to access critical records during an external connectivity outage. The approach would need to account for the hospital's existing systems, security requirements, and clinical needs.

1. Normal operation: Cloud-connected care

Clinicians use the hospital's primary electronic health record while a local system keeps an updated, secure copy of essential patient information. The same infrastructure could also support AI applications and other services during normal operations, so long as critical patient-record access remains protected.

If the hospital loses its connection to the cloud, clinicians can turn to locally stored records using an application and sign-in process that works without internet access.

They may still be able to review medication histories and allergies, even if electronic ordering or access to newly updated records is unavailable. Staff follow established downtime procedures, with local computing, networking, and backup power keeping the essential service running.

When the connection returns, hospital staff verify that the primary systems are working and update patient records with information documented during the outage. Any missing or conflicting information needs to be resolved before normal workflows resume.

Each stage requires preparation, from keeping records current and ensuring staff can access them to deciding who manages the transition back to normal operations.

For a deeper look at the role of local computing and storage, check out 

Different failures require different safeguards

The response depends on what failed. A 911 dispatcher using AI-assisted translation may need an alternative communications path or local capability when the primary connection fails. A school district responding to ransomware may need to keep affected systems isolated until they can be safely restored.

A backup connection may help during a network outage, while local computing and data can allow certain services to continue without access to the cloud. A power failure calls for backup electricity. Recovering from a cyberattack may require isolated copies of critical information and careful verification before systems are brought back online.

Many hospitals, public-safety organizations, and other essential service providers already have backup systems and downtime procedures in place. The question is whether those protections cover the dependencies that matter most. 

Before investing in more infrastructure, operators need to understand where their existing protections fall short and what would actually improve service continuity.

Organizations also need to know whether their continuity plans will work in practice. A hospital, for example, could simulate a four-hour loss of external connectivity to see whether clinicians can still access the patient information they need. Before the exercise, clinical and technical teams would agree on which functions must remain available and what level of disruption is acceptable.

During the exercise, teams should record which functions remain available, which become limited or unavailable, how long local operations can last, and who takes charge. They must also test whether information recorded during the outage can be reconciled and normal service restored safely.

Testing against different types of disruption gives organizations a clear picture of their vulnerabilities and the evidence they need to make informed infrastructure investments.

The infrastructure being built today will serve communities for decades, as AI takes on a larger role in healthcare, public safety, education, and other essential services. Decisions about where computing and data reside, how services continue locally, and how they recover will shape what communities can rely on.

Continuity and recovery belong in those decisions from the start. We should know which functions can survive a lost connection, what remains available locally, and what it takes to restore the full service.

The infrastructure behind those services must deliver what people need, when and where they need it, in blue skies or gray.

What happens when a hospital loses access to the cloud? Jase Wilson explores how local computing, essential data, and recovery planning can keep critical services operating when connectivity fails.

What happens when cloud connectivity fails? Explore how local computing, essential data, and recovery planning help hospitals keep critical services running.

What Happens When the Cloud Is Unreachable? | Ready

State broadband directors have spent years of their careers working to connect communities to reliable, high-speed internet. Their efforts have helped lay the foundation for a more connected America, navigating complex funding programs, coordinating with providers, and working to reach communities that have long been left behind.

The $42.45 billion BEAD program represented a historic milestone in that effort, committing America to building broadband networks that would serve communities for decades. But as states worked to deliver on that promise, a new technological shift was already underway. Just over a year after BEAD became law in 2021, ChatGPT brought generative AI into mainstream awareness, beginning a shift in expectations for what those networks would need to deliver.

By the time states received BEAD allocations in the summer of 2023, AI was already reshaping expectations for what digital infrastructure could make possible. Today, states are building networks intended to serve communities for decades, even as those expectations keep changing. Connecting communities remains essential, but states also need to understand what their infrastructure can do, what other systems it depends on, and what happens to essential services when part of the system fails.

As AI changes what digital infrastructure needs to deliver, broadband directors have an opportunity to build on the work they've already done. Their expertise and relationships can help states understand how networks, computing, power, and critical services fit together, and identify opportunities to make better use of existing infrastructure.

Consider a small manufacturer in rural America. Today, broadband connects the factory to suppliers, customers, and remote technical support. AI could soon help inspect products, identify equipment problems before machines fail, and improve production. Delivering those capabilities reliably requires more than a fast connection, with computing and data potentially distributed across the factory, nearby facilities, and distant data centers. Keeping relevant equipment records and an AI model locally could allow the factory to detect problems and support operations without depending on a continuous connection to a distant cloud.

, I described the emerging three-tiered architecture of AI infrastructure: device, near-cloud, and far-cloud. Near-cloud infrastructure brings computing and storage closer to the communities they serve, reducing delays and allowing certain services to continue when distant systems become unavailable. But proximity alone isn't enough. Those capabilities also require reliable power, access to essential data, and network connections that support local operations.

A computing facility might sit a few miles from the institutions it serves, yet network traffic could travel hundreds of miles through a distant exchange point before reaching it. Where computing happens matters, but so does how the network connects people and institutions to it.

Broadband directors already understand the geography of connectivity, from last-mile networks to middle-mile routes and interconnection points. Their knowledge provides a starting point for identifying existing assets that could support new capabilities.

A network hub with sufficient power and cooling could house computing and storage that serve nearby institutions. A public library or community college with reliable broadband could connect residents with remote specialists, educators, or other services unavailable locally.

The next opportunity isn't necessarily to build more infrastructure, but to get more out of the infrastructure America has already built.

The more useful our digital services become, the more we depend on them. AI accelerates the shift by moving increasingly important work into systems that rely on continuous access to data and computing. Broadband programs already plan for resilience through backup power, redundant equipment, and alternate connections, but protecting individual assets is not the same as keeping the services they support available. A network can look resilient on paper while hiding shared dependencies that become obvious only when something fails.

Consider two supposedly independent fiber routes serving a community that cross the same bridge. Or several facilities that depend on the same electrical substation. Multiple providers may even rely on the same underground conduit. In each case, what appears to be redundancy can disappear with a single failure, potentially disrupting services across an entire region.

The problem extends beyond the network itself. Placing computing capacity near a community does little good if the applications, records, or AI models required to use it become unavailable. Consider a local AI model helping a utility identify equipment problems. If maintenance histories, equipment records, or current operating data are only accessible through distant systems, the model may lose access to the information needed to make useful assessments during a network disruption. Keeping essential records accessible locally, alongside the models that use them, can allow certain services to continue operating even when connections to distant systems fail.

Identifying shared dependencies often requires information held by different providers, institutions, and public agencies. No single organization necessarily sees the whole picture. State broadband offices can help connect those perspectives, uncover vulnerabilities that individual projects may overlook, and build a shared understanding of how networks, power, computing, and essential services depend on one another.

From broadband maps to infrastructure intelligence

Broadband offices can build on the information gathered through BEAD to develop a more complete picture of their states' infrastructure. Imagine putting that knowledge to work on a broader infrastructure map. Start with one region, work with providers and other agencies, and ask three questions:

Repeating the exercise across regions could help states compare risks, identify opportunities to put existing assets to work, and set priorities for future investments. Success could mean eliminating a shared point of failure, keeping an essential service running during an outage, or enabling a rural community to access services previously unavailable locally.

Broadband offices don't need to operate data centers or manage private networks themselves. Their role is to bring the right organizations together, identify shared needs, and help states act on the opportunities their infrastructure maps reveal.

The networks funded through BEAD will serve communities for decades, and broadband offices have an opportunity to help states understand how those networks fit into a much larger infrastructure system. The next phase can begin while construction and oversight are still underway, using the same planning and coordination expertise to prepare for the services communities will need.

A more complete infrastructure map gives broadband directors something concrete to bring to state leadership: where their regions are vulnerable, where existing assets could do more, and where coordination could improve essential services. Governors and state legislatures will ultimately decide how to keep that expertise in place, whether through permanent broadband offices or other long-term arrangements. Broadband directors can help define the next mission by showing what their states stand to gain.

BEAD's long-term value will be measured not only by the locations connected, but by what those connections make possible. AI is expanding those possibilities, from new tools for rural businesses to better access to essential services and infrastructure that keeps working through disruptions. Broadband directors have helped connect America. The next step is to connect and protect America.

Continue the conversation at Leaders Summit XI

The next chapter of broadband won't be shaped by any one office alone. At 

, state broadband leaders will come together to discuss construction, supplemental deployment, monitoring, and long-term oversight, with a focus on protecting today's investments and preparing for what comes after BEAD. 

As AI reshapes digital infrastructure, state broadband directors have an opportunity to lead beyond BEAD. Jase Wilson explores how states can build on their broadband investments, identify critical infrastructure dependencies, strengthen resilience, and prepare for the next generation of essential services.

Broadband directors helped America map the connectivity gap. Now they can help states understand how networks, computing, and power must work together to deliver resilient, AI-enabled services.

As AI reshapes infrastructure needs, discover how state broadband directors can build on BEAD investments, strengthen resilience, and plan for what comes next.

AI is advancing faster than the infrastructure required to ensure it delivers what people need, when and where they need it. The next phase of the AI buildout will be defined not only by what intelligence can do, but by whether the systems underneath it can deliver when and where people depend on them.

AI’s most consequential promise may be its ability to make scarce expertise available to far more people, in far more places.

A doctor can bring more context into a remote visit. A teacher can give more individualized support. A dispatcher can understand a caller speaking another language. A utility operator can spot emerging problems across the grid earlier and respond with better information.

AI has the potential to loosen constraints of geography, time, cost, and the number of qualified people available. But AI only creates value when intelligence can reach the people and systems that need it, where and when the work actually happens.

Turning AI capability into dependable service therefore requires more than powerful models and applications. The infrastructure supporting the service has to pass four tests:

Accessible. Buildable. Capable. Dependable.

Together, they form the ABCDs of AI-ready infrastructure.

Can people and critical systems reach and use the service?

Accessibility means every participant in a service has a usable path to the people, systems, and information required to complete the job. Depending on the service, that may require the right interface, equipment, connectivity, privacy, authentication, data access, or support.

Consider a 911 dispatcher taking a call from someone who speaks a different language. AI could help transcribe and translate the conversation in real time while the dispatcher determines what is happening and coordinates the response. For that service to work, the caller must reach 911, the dispatcher must be able to access location information, maps, records, and response systems, and the translation service must have the correct audio, sufficient compute, and reliable connectivity to support a live emergency.

Accessibility means giving the people and systems that depend on a service a usable path to it in the context where the work happens.

Can the infrastructure be deployed where and when the service is needed?

A service may be valuable and technically feasible, but the infrastructure still has to fit the places where the work happens and come online on a practical timeline.

Imagine a state wants to add local AI capacity across dozens of hospitals, schools, emergency communications centers, and utility sites. Building a new facility for every location would be slow and expensive. Existing sites offer a different path because many already have power, connectivity, security, and operating capacity in the places where services are needed.

The Buildable test asks whether that existing capacity is actually usable. Is enough power available? Is cooling sufficient? Will the equipment fit? Can approvals be secured? Can installation and support happen inside an operating facility?

Technical feasibility at one site is not enough. The deployment model also has to repeat. Standardized designs, installation methods, repair, replacement, and expansion determine whether one successful deployment can become ten, fifty, or hundreds without reinventing the process each time.

Buildability is therefore both local and systemic: a deployment has to work at a specific site, and the model has to work again at the next one.

Can the complete service perform the required job at the required level?

Capability is a service-level test. The required standard may include response time, accuracy, throughput, data freshness, capacity, privacy, and the appropriate level of human involvement. The right standard depends on the mission.

An electric utility analyzing equipment conditions may need fast local processing and current operational data. A school using AI-assisted tutoring may prioritize student privacy and reliable access. A public safety application may require near-real-time information and very little tolerance for delay. Each service creates a different performance envelope for the infrastructure supporting it.

Those requirements determine how much computing capacity is needed and where the workload should run. Some workloads can run effectively on a device. Others are better suited to centralized infrastructure. Others require shared compute, storage, and data closer to the institution or critical system.

Capability is ultimately a fit question: does the complete architecture meet the standard the service actually demands?

Can the service keep working through disruption and recover when dependencies fail?

Dependability begins with a clear definition of what must remain available when normal conditions change. Which functions must continue? How long can reduced operation be sustained? What can degrade safely? What has to happen for full service to return?

In the 911 example, an AI-assisted translation workflow may normally rely on a remote service. If that connection fails, another network path, local capability, or reduced set of functions may need to keep the service operating until remote systems return.

Continuity depends on the full chain supporting the service: power, cooling, compute, storage, data, identity, connectivity, monitoring, maintenance, and accountable operators. Recovery matters just as much as continuity. Systems may need to reconnect, synchronize queued information, reconcile changes made during reduced operation, and verify that normal service has resumed.

Dependability means designing and testing both continuity and recovery before either is needed.

What AI-ready infrastructure must deliver

The real test of AI-ready infrastructure is not how impressive the underlying technology is. It is whether an important service can actually be delivered in the real world.

Our work with the institutions responsible for funding, planning, deploying, and operating critical infrastructure has reinforced a consistent lesson: the hardest failures rarely come from a single missing technology. A service fails because some part of the complete delivery chain cannot be reached, deployed, perform at the required level, or continue through disruption.

That is what the ABCDs are designed to test. Pick one service your institution depends on and ask:

Explore the Resiliency Playbook for practical guidance on planning and deploying infrastructure that can deliver critical services where they’re needed — with the access, capacity, deployment model, and resilience to keep them working.

A practical framework for evaluating whether AI infrastructure can turn powerful technology into dependable real-world services by making it accessible, buildable, capable, and dependable.

A practical framework for evaluating whether AI infrastructure is accessible, buildable, capable, and dependable enough to deliver real-world services.

The ABCDs of AI-Ready Infrastructure

The ABCDs of AI-ready Infrastructure

AI infrastructure is becoming three-tiered: 

. At one end, enormous centralized campuses train and serve increasingly powerful models. At the other, phones, laptops, vehicles, and machines are becoming capable of running AI locally. Between them sits the Missing Middle: the near-cloud, a distributed layer of shared compute, data, connectivity, and AI capability close to the people and critical systems that need it.

Both ends are necessary. But the truth is that AI models can do far more than those two extremes alone can deliver. The person who needs an AI-enabled doctor, mental wellness check-in, tutor, or other critical service is unlikely to get the model’s full potential through a pocket computer. And for critical services, the model must remain useful in blue skies or gray.

The Missing Middle fills the space between those extremes. It gives hospitals, utilities, public safety agencies, schools, and other institutions enough nearby compute, data, connectivity, and supporting systems to run more capable services without recreating an entire hyperscale cloud locally.

Consider a hospital imaging department. AI can help flag CT scans that may need prompt attention, helping clinicians prioritize which scans to review first. Running that capability nearby may improve response time, reduce unnecessary data movement, and allow parts of the workflow to remain available when outside connectivity is lost.

The hospital does not need the entire cloud inside the building. But critical scans, records, and supporting systems should not always have to make a thousand-mile round trip to a distant data center before useful work can happen. Enough capability needs to remain nearby for the workflow to keep working where care is delivered.

A phone can run a small AI model in your hand. A giant data center hundreds of miles away can run far more powerful models in the cloud.

But many of the most consequential AI services fit neither extreme. They need more computing power, data, and supporting infrastructure than an individual device can provide, while also benefiting from being closer to the people, equipment, and records they serve.

The idea extends beyond putting compute at the edge. Critical services depend on more than processing power. Applications, data, identity, connectivity, and other supporting systems may also need to remain available nearby.

For critical infrastructure, the goal is not primarily to shave milliseconds off latency. The goal is to keep useful capability available when remote dependencies slow down, disappear, or fail.

AI needs infrastructure ready for anything

Putting compute nearby solves only part of the problem. A server inside a hospital or utility facility provides little continuity if authentication, application data, communications, or model access disappear when the outside connection fails.

A rural hospital may keep AI processing local and still lose the imaging workflow if patient records or authentication remain available only through far-cloud systems.

The same problem applies to NG911 routing, emergency communications, utility operations, and other critical services. Keeping the model nearby matters only if the records, permissions, communications, and other dependencies needed to use it remain available too.

For Americans to fully realize the benefits of AI, services must be 

. The infrastructure underneath them must work in blue skies and gray: power, storage, connectivity, physical protection, sensing, and software working together so useful capability remains available through ordinary conditions and disruption.

Resilience creates the foundation for local AI

Local AI and infrastructure resilience do not need to be separate projects. An electric cooperative hardening a communications site may already need reliable power, protected equipment, network diversity, backup connectivity, and monitoring. Adding compute and storage can make the same investment capable of supporting local AI workloads.

The same opportunity exists for hospitals, public safety agencies, universities, and military installations. Rather than build dedicated AI infrastructure alongside separate resilience infrastructure, the physical layer can serve both.

Resilience creates immediate operational value, while added compute and storage expand what the same infrastructure can support as AI demand grows.

Every node adds capability to the network

A single node serves a place. A network of nodes can serve a region. Each deployment adds local capacity, another resilient point of service, and another place where critical workloads can keep running closer to the people and systems that need them.

The real opportunity is not to scatter isolated boxes across the country. It is to connect and manage distributed infrastructure as one system, so capacity, connectivity, equipment health, and failures can be coordinated across many sites.

Working with infrastructure owners and public institutions has made the operating challenge concrete for us. Distributed infrastructure becomes more useful when operators can see and manage it as one system. That challenge is shaping what we are building at Ready: 

 brings compute, storage, connectivity, and sensing closer to critical systems; BOSS provides visibility and control across the distributed fleet; and 

 creates places where people can actually reach the services the network makes possible.

The next AI buildout will fill the Missing Middle

Hyperscale campuses will continue getting larger. Devices will continue getting smarter. Neither trend eliminates the need for infrastructure in between.

For every critical AI-enabled service, ask:

The answers determine where a workload belongs and which supporting systems must be deployed with it.

AI infrastructure has largely been defined by concentrating extraordinary amounts of compute in a few places and compressing increasingly capable intelligence into ever-smaller devices.

I believe the next major infrastructure category will emerge in the Missing Middle. AI models are already capable of extraordinary things. The infrastructure question now is whether those capabilities can reach the people and critical systems that depend on them, close enough to be useful and resilient enough to remain available in blue skies or gray.

AI infrastructure is growing at two extremes: massive cloud campuses and increasingly capable devices. The Missing Middle is the distributed layer in between, bringing compute, storage, connectivity, and resilience closer to the institutions and critical systems that need AI to work where the work actually happens.

AI infrastructure needs a layer between hyperscale clouds and devices. Explore the Missing Middle: distributed compute built closer to critical systems.

The Missing Middle of AI Infrastructure

Explore the Missing Middle of AI infrastructure: near-cloud compute, storage, connectivity, and resilience deployed closer to hospitals, utilities, and other critical systems.

The Missing Middle of AI Infrastructure | Ready.net

 requires every Eligible Entity to run an additional BEAD challenge and application round to reach remaining unserved locations. The remaining unserved locations resulted from defaults in federal or state broadband funding programs, such as RDOF, locations misreported as served in previous versions of the Broadband Data Collection (BDC) program, unfulfilled planned service challenges, and locations new to the Fabric.

Whenever NTIA finalizes and delivers the Supplemental BEAD Eligible Location List, the process kicks off:

NTIA then reviews the final list and sets a funding cap, and the state has 90 days to run a second Benefit of the Bargain round and submit a Supplemental Deployment Plan.

The full scope is roughly six months of sequenced, clocked work, arriving on top of subgrantee agreements, environmental and permitting reviews, milestone monitoring, and semiannual reporting.

The good news is that this challenge process is narrow and prescriptive. It is removal-only, there is no rebuttal round, and there are no discrete challenge types to administer. Almost everything that makes it hard can be done before NTIA delivers your list. Here are 7 steps we recommend:

NTIA’s list will be based on funding and availability data tied to Fabric v8, removing locations that don't appear in v9 or otherwise handled by the Final Proposal.

Based on supplemental data provided by Eligible Entities, it may also include locations affected by defaults or descopes across federal, state, and local programs. Prior to receiving the list from NTIA, leverage your office's local knowledge to identify additional locations that you believe should be eligible, including current or imminent defaults and descopes. This gives you the best chance of reaching the highest number of unserved locations possible.

Building your list proactively also enables you to begin planning for and designing your supplemental challenge and application round with an approximate list of locations. This is critical in a compressed timeline that will run parallel to all of the other BEAD implementation tasks in front of you.

2. Inventory your state and local enforceable commitments

Eligible Entities are responsible for reviewing the NTIA-provided lists and applying all applicable reason codes, where feasible. This will primarily consist of identifying locations already covered by other state or local enforceable commitments for broadband buildout.

Gather the location-level data and documentation for each existing commitment before NTIA’s list arrives. There are many other priorities you're juggling and being prepared ensures that you can complete the task in thirty days or less, without sacrificing other obligations.

3. Set your evidence standard before the challenge window opens

The challenger carries the burden of proof. A simple provider attestation is not enough. Evidence will vary by technology and may include performance data, network designs, subscriber records, construction documentation, permits, or other proof of qualifying service.

Define the evidence your office will accept, how it will be evaluated, and who will review it before the challenge period begins. The evidentiary standards must be unbiased and applied consistently across technologies and challengers.

4. Set up your challenge and adjudication process now

States will need clear processes and workflows for eligible challengers to register, identify locations, submit evidence, and receive determinations. Your team also needs a way to conduct reviews, record decisions, and retain the supporting evidence for NTIA.

Decide those mechanics as soon as possible. Draft your instructions, FAQs, notifications, and publication process in advance. Even a relatively small supplemental list can generate a large amount of work.

5. Confirm your budget and procurement path early

Programmatic costs for the challenge process and second Benefit of the Bargain round are not subject to the two percent administrative cap. Personnel, fringe, and contracts are allowable, but Initial Planning Funds cannot be used for this work.

Review your current Final Proposal Funding Request budget and determine whether you need a modification. If you plan to use an existing vendor or consultant, confirm whether the current contract can cover the new scope or whether a task order or change order is needed.

6. Prepare for the second Benefit of the Bargain round now

Once NTIA approves the final supplemental list, states have 90 days to run the second Benefit of the Bargain round and submit a Supplemental Deployment Plan. Reuse first-round application materials, certifications, scoring frameworks, and processes wherever feasible.

A practical guide state broadband offices can take now to prepare for the next BEAD challenge process before NTIA’s eligible location list arrives.

Blog

What Working Inside America's Infrastructure Investment Taught Us

What Happens When the Cloud Is Unreachable?

What Broadband Directors Must Know About AI Infrastructure

The ABCDs of AI-ready Infrastructure

The Missing Middle of AI Infrastructure

7 Steps to Get Ready for the Next BEAD Challenge Process

Turning America’s Trusted Institutions Into Points of Care and Opportunity

Five Principles for Long-Term BEAD Post-Award Execution

Ice Storms, Floods, and Fiber: How Minnesota Builds Resilient Networks

What Consultants Must Know About Subgrantee Agreements

Streamlining BEAD Post-Award Management: Why States Need Standardized Milestones

Practical Framework for LEO Satellite Broadband Oversight