5 pages · 62 KiB · PDF v1.0.1
Get the full report.
Enter your email to download the full report.
Agent adoption brings infrastructure competition back to a specific question: can the capacity a customer needs enter production at the agreed location, date and service level? For an asset and project development platform, the opportunity is to coordinate land, power, cooling, connectivity and acceptance into a credible delivery commitment.
Modularity is one engineering route to that outcome. It moves repeated integration into a factory, allowing sites to reuse design, procurement and testing work. Its value must nevertheless be measured in operating results: how much time does it remove between capital commitment and the first service that a customer can accept and pay for?
What the new evidence strengthens
SpaceX management described factory-integrated power, cooling and inference clusters. NVIDIA DSX POD explicitly connects factory integration to prepared site infrastructure.[1][2] These support treating modularity as a method of delivery, beyond a particular enclosure or building format.
Crusoe announced Spark Liquid on 21 October, with up to 3.5 MW of compute per unit (a vendor figure) and production planned for 2027. Existing Spark customer deployments must not be relabelled as delivered Spark Liquid capacity.[3] A product roadmap and operating experience strengthen the direction without establishing our own costs, schedules or customer demand.
Our assessment: the useful question is how prepared power becomes production capacity sooner. Agent user counts do not determine how many modules to order. Modular construction can serve large campuses as well as distributed sites; it does not by itself imply a small footprint, edge location or low latency.
1. Make power delivery a sequence of verifiable states
“Power available” is an inadequate project status. A preliminary capacity estimate, an executed connection agreement, equipment on site, energization and sustained-load acceptance represent different evidence. Capacity, dates, accountable parties and operating restrictions must appear in the same delivery record.
| Delivery stage | Evidence required | What remains unproven |
|---|---|---|
| Resource and connection | Supply design, capacity boundary, connection or supply conditions, relevant permitting path | A target date is not a guaranteed energization date |
| Engineering readiness | Coordinated electrical, protection, cooling, fire and network design; interface responsibilities | Delivered equipment is not an integrated system |
| Operating readiness | Startup, failover, sustained-load, thermal and network tests | Nameplate MW is not continuous IT MW at the required SLA |
| Commercial readiness | Customer acceptance, billing commencement, operating handover and defect responsibilities | Technical acceptance is not customer revenue |
This is a proposed diligence framework, not a jurisdiction-specific legal checklist. On-site generation also requires assessment of fuel, emissions, operating permissions, backup and maintenance. A generator order alone does not establish reliable supply.
Which part of the schedule does modularity shorten?
An illustrative critical-path model is:
Time to first production ≈ max(site ready, power ready, modules delivered, network ready) + integration and customer acceptance.
This assumes the first four paths can run in parallel; real schedules must preserve their dependencies. Prefabrication mainly reduces on-site integration and rework. If a connection or permit still determines the critical path, earlier module delivery may merely increase inventory financing. NVIDIA also specifies prepared site power, cooling and network connections.[2]
NVIDIA’s 21 October announcement cites deployment at a prepared site in as little as fourteen days, with partner delivery targeted for early 2027. This excludes the full process of securing land, power and permissions and cannot become our project commitment.[5]
Delivery records should therefore distinguish planned readiness, verified readiness and remaining restrictions. Module payment milestones should be coordinated with actual site readiness.
2. Match the workload and keep suppliers and operators replaceable
Inference is not one workload. Interactive sessions, long-context tasks, batch processing, tool execution and training have different network, storage, memory, response-time and power requirements. Moving an entire agent workflow closer to its user may be less effective than keeping only latency-sensitive or local-data components nearby and centralizing the rest.
Design should begin with the actual workload and service objectives, followed by module capacity, redundancy and connectivity. Testing must cover complete-task latency and failure rates. Single-device throughput, peak rack power and geographic proximity cannot individually establish suitability.
For Lintel, repeatable delivery interfaces are more useful than a preferred module shape. Power quality, permissible load changes, cooling conditions, failure boundaries, fiber routes, fire interfaces, maintenance access and acceptance criteria should be jointly inspectable by the developer, equipment supplier and operator.
Standardization should also preserve adaptation. New GPU generations can change rack density and thermal requirements. Upgradeability must be demonstrated through structural, piping, electrical and network limits, including the impact of replacement on adjacent units. The word “modular” provides no such assurance.
Large entrants bring both demand and competition
Large cloud providers, model companies and vertically integrated operators may purchase third-party sites. They may also build internally, buy modules directly and control their own power supply. Their investment supports the market direction without guaranteeing a developer's margin.
As reference designs and supply networks mature, buyers can compare delivery partners more easily and routine integration may become less valuable. Defensible differences require project evidence: dependable energization, verified interfaces, less rework, replaceable suppliers and an organization accountable for delay and defects. These are capabilities to test, not claims of Lintel's demonstrated performance.
3. Separate facility duration from short compute contracts
Inference pricing can reset quickly while land, energy commitments and facility debt persist for years. A compute operator's willingness to accept short contracts does not establish that a developer or lender can carry the same exposure. Short upstream revenues cannot automatically cover long fixed obligations.
Facility investment must identify who bears minimum payments, ramp-up vacancy, excess power use, upgrades and early exit. A combination of committed capacity and flexible expansion may be worth assessing. Its financeability still depends on actual contract terms, credit, duration and security, rather than industry enthusiasm.
| Risk | How it reduces modular value | Required test |
|---|---|---|
| Power delay | Idle equipment, financing and storage costs | Critical path, delay responsibility, staged procurement and cancellation cost |
| Short contracts or customer loss | Long obligations lose revenue coverage | Minimum payments, replacement-customer lead time and retrofit cost |
| Large buyers build internally | Less external procurement and lower delivery margin | Actual procurement boundaries and competitive bids on equal terms |
| Density and cooling changes | Additional investment or early obsolescence | Upgrade limits, downtime and conservative residual value |
| Distributed operations | More maintenance, spares and connectivity expense | Lifecycle cost and recovery testing |
Recover the full investment boundary
GPU rent divided by module price is not a facility payback model. Development costs should cover site control, design, permits, civil works, connection, electrical infrastructure, cooling, networking, commissioning, construction-period funding, contingency and working capital. Whether GPUs belong in the capital base must match ownership of the associated revenues. Facility sale, leasing and retained operations require separate models.
The economic value of earlier production is the present value of earlier net receipts, less the modular premium, earlier procurement funding and remaining delivery risks. A shorter schedule creates revenue value only when a customer actually pays sooner.
4. A stronger thesis with explicit failure conditions
Our research proposition is: where power, site readiness and customer demand are independently supported, standardized factory integration can shorten the path from prepared power to productive service. Value depends on complete delivery accountability and a compatible financing structure.
Validation should compare projects with equivalent service boundaries: first billing date, total investment, defect closure, sustained usable IT capacity, operating cost and contract coverage. Samples should include delayed, modified and idle modules, not only successful installations.
The proposition weakens if site work persistently controls the schedule, the modular premium exceeds earlier receipts, customers prefer centralized facilities that meet their latency needs, or direct procurement removes the developer's margin. A pilot should find those boundaries rather than label every project modular.
Lintel and INTERTIE.ai research should meet at the acceptance interface. The former asks when and where specified facility conditions can be delivered; the latter asks which workloads pay and whether operating cash supports the compute assets. In this series, Lintel denotes the asset and project-development research perspective and INTERTIE.ai the compute-cloud and agent-operations perspective. These labels describe research scope; they do not establish legal entities, ownership, contracting parties or financing.
Sources and method
- SpaceX official transcript, 20 October 2026, transcript p.10. Management commentary, not a module-delivery record.
- NVIDIA DSX POD reference design, accessed 22 October 2026; site preparation, intended applications and partner responsibilities. A vendor architecture, not a project schedule guarantee.
- Crusoe Spark Liquid announcement, 21 October 2026. Existing Spark and planned 2027 Liquid production remain distinct; vendor specifications have not been independently measured.
- INTERTIE.ai: Agents and infrastructure, original research dated 26 September 2026; revised on 22 October 2026.
- NVIDIA DSX POD announcement, 21 October 2026; ready-site prerequisite and early-2027 availability.
New-evidence cutoff: 22 October 2026. Engineering frameworks, risk analysis and conclusions are our analysis. No private project evidence, project quotation or return commitment is included. Prepared and source-checked by Codex. Research edition v1.0.