Eaton's Equipment Forge: Multi-Agent AI for Complex Engineer-to-Order Decisions

Enterprise Complex Business: Every Link Interconnected

Eaton, a century-old power management company serving data centers, grids, factories, and large buildings, faces rising demand for customized equipment and faster delivery driven by AI data center construction. Part of its business operates under an Engineer-to-Order (ETO) model: after a customer specifies technical requirements, engineering must judge whether existing designs meet them or need reconfiguration; procurement checks materials and suppliers; manufacturing evaluates production conditions. The final quote and lead time aggregate judgments from multiple departments.

According to prior Palantir supply-chain disclosures, Eaton's operations involve over 100,000 sales orders per day, 300+ factories, 32+ million distinct parts, and 72+ ERP instances . In this environment, an engineering-feasible design may be unworkable in procurement; a supplier may have stock but the component might not meet all technical standards. Worse, when one condition changes, prior judgments must be re-verified.

The AIPCon 11 demo centered on an Arc Flash safety requirement. Arc flash is a high-energy electrical hazard; special protection requirements affect equipment design and component selection. If a critical component has a one-year procurement lead time, the delivery plan must be re-evaluated. Switching to a second supplier seems straightforward, but the new component must fit the design, meet safety standards, and the BOM and delivery schedule must be rechecked.

Historically, this information lived in separate engineering systems, ERPs, procurement platforms, and personal records. Departments could query their own data, but complex exceptions required emails, spreadsheets, and manual coordination. Eaton VP and Chief Data & AI Officer Ross Schalmo noted that customer questions are simple — "Can you make it? When will it arrive?" — but the enterprise must give a commitment that engineering, supply chain, and the factory can all honor.

Equipment Forge organizes multiple specialized agents around this workflow. After a customer requirement enters the system, an agent identifies special conditions against engineering standards, then checks BOM, suppliers, and material lead times. Business users can view engineering requirements, supply risks, and their delivery impact in a single workspace.

Multiple Agents in Relay: How One Engineering Requirement Affects the Whole Order

The demo starts with the customer's engineering requirement.

1. Requirements Analysis Agent

Reads the customer's specification documents, compares them against Eaton's product standards and historical engineering-decision knowledge, and identifies special requirements that could affect equipment configuration. In the live case, it found a deviation related to arc-flash safety, which could impact design and downstream component selection.

This is more than document extraction. Customer requirements mix natural language, product parameters, and standard clauses; the system must translate them into engineering constraints that other business steps can consume. Eaton combines product standards with historical engineering knowledge for the agent to use. Schalmo emphasized this is not just faster PDF reading , but converting unstructured customer asks into structured information other processes can act on.

2. BOM Availability Agent

BOM (Bill of Materials) lists components needed to manufacture the equipment. This agent checks the initial BOM against the customer requirement and engineering design, then combines material and supplier data to judge supply feasibility of the current configuration.

The system quickly flagged a problem: a key component tied to the arc-flash requirement had a procurement lead time of up to one year . The UI highlighted this component in red, exposing the delivery risk of the original plan.

3. Human-in-the-Loop Supplier Substitution

Staff then consider a second supplier. If another vendor can provide a component meeting the same engineering requirements, the long lead time might be avoided. But swapping suppliers isn't just updating a procurement record: the new component must fit the equipment design, satisfy safety requirements, and the BOM and delivery plan must be re-validated.

In the demo, after the user selects a candidate, a new round of agent analysis is triggered. The system traces affected customer requirements, product configurations, and BOMs through Ontology relationships, re-checks relevant materials and supplier data, recalculates dependencies, and updates delivery and quote options.

Several agents handle different tasks, but they all operate on the same order . Constraints found in requirements analysis feed into the BOM agent's judgment; supply risks discovered in material checks feed into subsequent option evaluation. When staff change a supplier, related engineering and delivery conditions are re-verified automatically.

Eaton deliberately retains human decision points . Agents analyze, provide evidence, and propose candidates; humans review, weigh trade-offs, and own the final business commitment. After a decision, the system continues downstream tasks. This reflects manufacturing reality: a shorter supplier lead time doesn't guarantee engineering validation; technical substitutability doesn't mean procurement and delivery conditions are satisfied. Especially for power-equipment safety, supplier selection, and customer promises, the enterprise still needs clear approval authority.

Equipment Forge demonstrates a continuous flow from requirements analysis through material checking to option adjustment. Eaton has not released average quote-speed improvements for the new system, nor confirmed that the one-year-lead-time component has actually been replaced. The second supplier was a viable candidate discussed on stage; actual procurement and delivery outcomes remain undisclosed.

Shared Business Context Across Agents: What Role Does Ontology Play?

Sequential agent execution is achievable with many frameworks today. Eaton's business further demands that agents share the same order's context and continue analysis when conditions change.

In large enterprises, data is scattered: customer requirements in CRM or engineering docs, product configurations in PLM, BOM/materials/procurement in ERP. Each system holds a piece of the business but not necessarily the explicit relationships.

The requirements agent knows the special safety requirement; the BOM agent knows a component is out of stock; procurement knows the supplier's latest lead time. Without explicit links, the system cannot determine which components a customer requirement affects, or what must be rechecked after a supplier change.

Figure 1: Palantir Foundry Ontology Core three-layer architecture: Semantic, Kinetic, and Dynamic

Palantir Ontology provides a unified business object model. Per official technical docs, Ontology uses Objects, Properties, and Links to describe enterprise business objects, their attributes, and relationships. Orders, product configurations, parts, suppliers, and factories become distinct object types linked to existing data sources.

In Eaton's scenario, a customer requirement constrains an engineering configuration; the configuration maps to a BOM; the BOM contains specific components; components link to suppliers and their expected lead times; materials and production conditions jointly determine the delivery commitment.

When the requirements agent identifies a special safety requirement, downstream agents can follow the related configuration to check materials. A component supply risk lets the system trace affected equipment and delivery conditions. When staff evaluate a supplier swap, dependencies re-enter the validation cycle.

This information doesn't have to be passed between agents via natural language. Agents can query properties and check links around concrete business objects, then hand analysis results to downstream processes.

However, once relationships are established, data state changes must be handled: suppliers update lead times, engineers modify designs, customers adjust requirements. Subsequent analysis must use correct data and configuration versions; already-formed proposals may need re-validation.

Palantir's Ontology provides Functions and Actions for this. Functions execute computations and logic on business objects; Actions modify business objects or trigger operations per defined rules, with permissions and validation conditions controlling execution.

For example, in similar business systems, an approved substitute-material decision can modify the relevant business object via a controlled action, making it available to downstream programs. What can be modified, who has permission, and whether conditions are met are managed by the business system.

These are general Palantir platform capabilities. Eaton has not disclosed the full Object Types, Functions, Actions, and approval rules configured in Equipment Forge. The live demo confirms that multiple agents perform linked analysis around Ontology, humans retain key decisions, and the system continues processing after human choices.

At runtime, Ontology also depends on underlying data accuracy. If ERP material status isn't updated promptly, or historical engineering standards are stale, agents can produce inaccurate analyses. The business model organizes data and relationships; data quality, standard maintenance, and approval accountability remain the enterprise's responsibility.

From Engineering Documents to Business Execution: How Eaton Connects the Underlying Data

Equipment Forge isn't Eaton's first use of AI for engineering and supply-chain processes. At DevCon 4, Eaton development lead Takoda Denhof presented a production-grade engineering document automation pipeline.

Figure 2: DevCon 4 session — Process Orchestration × Eaton (Takoda Denhof × Matt Hawes)

Engineering specification files lack a uniform format; some run thousands of pages. Previously, engineers read each document manually, located technical requirements, and compiled the information for downstream design and business processes.

Eaton uses AIP Process Orchestration to automate these files. The system reviews complex engineering specifications, extracts information, and converts results into native Ontology objects for downstream business logic. Palantir's official DevCon 4 materials cite this as a production-grade complex-process automation case.

From document extraction to Ontology objects, an extra structuring step is added. If the system only produced a document summary, downstream programs would still need to reinterpret the engineering meaning. Converting extraction results into business objects lets the information participate in queries, calculations, and further business processing via object properties and relationships.

Equipment Forge's requirements-analysis scenario echoes this earlier practice. Customers submit unstructured engineering requirements; agents match them against Eaton's product standards and historical engineering knowledge, identify special conditions, and pass the derived constraints to the BOM Availability Agent.

Both presentations involve engineering knowledge moving from unstructured files into Ontology, then being consumed by downstream business logic. However, Eaton has not publicly stated whether Equipment Forge directly reuses internal components from the DevCon 4 project, nor disclosed the specific document-parsing models, object schemas, or inter-agent communication protocols.

Beyond documents, another effort integrates existing enterprise data platforms.

In October 2025, Snowflake and Palantir announced a platform partnership , naming Eaton as a showcase customer. The integration enables bidirectional, zero-copy interoperability between Snowflake Iceberg Tables and Palantir Foundry, allowing teams to use existing data under appropriate access and governance mechanisms, reducing repeated data migration and copying for new applications.

Eaton's then-Chief Data Officer Ross Schalmo noted in the press release that the native Snowflake-Palantir integration lets the team cut tedious data movement and redirect development resources toward agent-based product configuration, pricing, and quoting, as well as factory digital twins and field product services.

The joint announcement also mentioned engineering-manufacturing supply-chain coordination, including inventory, on-time delivery, and quality metrics.

These data scenarios align closely with Equipment Forge's problem space. Customer requirements and engineering standards come from different documents and systems; BOMs, supplier lead times, and production conditions may be managed by other platforms. To answer whether a configuration can be delivered, agents must analyze these data together in the context of a single business transaction.

In Palantir's public Ontology backend architecture, after data enters the business object layer, there are corresponding query, indexing, and modification mechanisms:

Object Data Funnel indexes Foundry data sources and user modifications submitted via Actions into the object database, updating relevant indexes as underlying data changes.

Object Set Service (OSS) provides object query, filter, aggregation, and loading capabilities to applications.

Actions apply defined and validated modifications to object data and support recording operation history.

Figure 3: Palantir Ontology backend architecture — Object Data Funnel, Object Set Service, Functions, and Actions

Thus, enterprise applications can read data around business objects, execute computations, and write back authorized modifications. For continuously changing orders, configurations, and supplier information, this read-write mechanism provides foundational support.

The above services are part of Palantir's publicly disclosed platform architecture; Eaton has not revealed which backend components or deployment parameters Equipment Forge actually uses. Therefore, public materials cannot determine its object-update latency, task orchestration approach, or specific execution protocols.

Returning to Eaton's demo, a relatively complete business processing chain is visible: customer requirements are analyzed by agents into engineering constraints; constraints flow to BOM and supplier checks; a long-lead-time component is discovered; staff evaluate a second supplier; the system re-analyzes affected dependencies per the new choice and updates delivery and quote options.

Eaton calls this end-to-end linkage across customer requirements, engineering configurations, material supply, and delivery commitments a Digital Thread .

This digital thread didn't appear from nowhere. Eaton had already spent years on supply-chain data integration, ERP data governance, and engineering document structuring. When the partnership expanded in 2024, ERP data mapping, cleansing, and migration were explicit application directions; earlier supply-chain projects helped Eaton identify material shortages, assess revenue impact, and propose actions based on historical handling records. Palantir's case study at the time reported a 25% productivity improvement from that supply-chain work — a figure not attributable to Equipment Forge.

In the 2026 demo, Eaton placed more complex engineering and delivery analysis into a multi-agent workflow. Engineering standards, business objects, and supply-chain data become reusable information for different agents, while humans step in when supplier and delivery trade-offs are needed.

Equipment Forge has not yet disclosed how many real orders it covers, which factories have deployed it, or the long-run accuracy and tangible benefits of multi-agent analysis in production. Eaton's goal is to let Engineer-to-Order business retain custom design capability while approaching Configure-to-Order (CTO) response efficiency . The talk also envisioned future customer-facing visibility into manufacturability, delivery times, and the impact of different choices.

For a complex order, the final delivery date often hinges on many interlinked conditions. A part needing a year to arrive cannot be changed by an agent , but the agent can surface the problem early , clarify which configurations are affected, and help staff evaluate alternatives.

Eaton has shown how this work can be relayed across different agents. Whether the full system runs stably across more products, factories, and real orders will depend on future production disclosures.

References

Palantir AIPCon 11 (Sep 10, 2026): Delivering the Power Infrastructure for AI | Eaton at AIPCon 11

Palantir: Process Orchestration × Eaton | DevCon 4

Snowflake (Oct 16, 2025): Snowflake and Palantir Announce Strategic Partnership for Enterprise-Ready AI & Analytics

Eaton (May 29, 2024): Eaton deepens partnership with Palantir to enhance AI use in operations

Palantir: Supply Chain Risk & Resilience — Eaton Case Study

Palantir: Ontology Backend Architecture