Eaton's Equipment Forge: Multi-Agent Collaboration via Ontology for Complex Orders
At Palantir AIPCon 11, Eaton demonstrated Equipment Forge, a multi-agent system where specialized agents analyze engineering requirements, check bill-of-materials availability, and evaluate supplier alternatives for custom electrical equipment, all coordinated through a shared ontology that maintains context across the order lifecycle while keeping humans in the loop for critical 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 electrical equipment with faster delivery driven by AI data center construction. Part of its business operates on an Engineer-to-Order (ETO) model: after a customer specifies technical requirements, engineering must judge whether existing designs meet them or need configuration changes; procurement then verifies materials and suppliers; the factory assesses production conditions. The final quote and lead time aggregate judgments from multiple departments.
Palantir previously disclosed Eaton's scale: over 100,000 daily sales orders, 300+ factories, 32+ million distinct parts, and 72+ ERP instances . In this environment, an engineering-feasible design may be unprocurable; a supplier may have stock but the component might not meet all technical standards. Worse, a single change forces re-checking of prior judgments. Information is scattered across engineering systems, ERPs, procurement platforms, and personal records, requiring emails, spreadsheets, and manual coordination for exceptions.
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 work: after a customer requirement enters the system, agents cross-reference engineering standards to identify special conditions, then check BOMs, 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 Impacts the Entire Order
The demonstration starts with a customer-submitted engineering requirement. The first agent, Requirements Analysis , reads the specification document against Eaton's product standards and historical engineering decision knowledge to identify configuration-impacting special requirements. In the live case, it found a deviation related to Arc Flash (electrical arc safety) that could affect equipment design and 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 downstream processes can consume. Eaton combines product standards with historical engineering knowledge for the agent — "not just making PDF reading faster, but turning unstructured customer requirements into information other business steps can understand and process."
Next, the BOM Availability Agent checks the initial Bill of Materials (BOM) against the customer requirement and engineering design, then combines material and supplier data to judge supply feasibility. It quickly flagged a critical arc-flash-related component with a procurement lead time of up to one year , highlighted in red, exposing the delivery risk of the original plan.
The team then considers a second supplier. If another supplier can provide a component meeting the same engineering requirements, the long lead time might be avoided. But switching suppliers isn't just a procurement record change: the new component must fit the equipment design, meet safety requirements, and the BOM and delivery schedule must be re-validated. In the demo, after the user selects a candidate, the system triggers another round of agent analysis. It traces affected customer requirements, product configurations, and BOMs through the ontology, re-checks materials and supplier info, recalculates dependencies, and updates delivery and quote options.
Several agents handle different tasks but always work on the same order . Engineering constraints from requirements analysis feed the BOM agent; supply risks from material checks feed later option selection. When a user changes a supplier, related engineering and delivery conditions are re-verified. Eaton retains human decision points : agents analyze, provide evidence and candidates; humans review, weigh trade-offs, and own the final business commitment. This reflects manufacturing reality — a shorter supplier lead time doesn't mean the component has passed engineering validation; technical substitutability doesn't guarantee procurement and delivery conditions hold. Especially for power equipment safety, supplier selection, and customer promises, the enterprise still needs clear approval authority.
Equipment Forge shows a continuous flow from requirements analysis to material check to option adjustment. Eaton did not release average quote-speed improvements for the new system, nor confirm that the one-year-lead-time component has been replaced. The second supplier was a viable candidate discussed live; actual procurement and delivery outcomes remain undisclosed.
Multi-Agent Shared Business Context: What Role Does Ontology Play?
Sequential agent execution is achievable with many frameworks today. Eaton's business demands that agents share the same order's information and continue analysis after conditions change. In large enterprises, data lives in separate systems: customer requirements in CRM or engineering docs, product configurations in PLM, BOMs/materials/procurement in ERP. Each system holds a piece of the business but not necessarily the explicit relationships.
The Requirements Analysis agent knows the special safety requirement; the BOM agent knows a component is short; 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 re-checked 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 Object, Property, and Link to describe enterprise business objects, their attributes, and relationships. Orders, product configurations, parts, suppliers, and factories become distinct objects 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 estimated lead times; materials and production conditions jointly determine the delivery commitment.
When the Requirements Analysis agent identifies a special safety requirement, downstream agents can follow the configuration to check materials. A component supply risk lets the system trace affected equipment and delivery conditions. When a user considers a supplier swap, dependencies re-enter the validation process.
This information doesn't have to be passed between agents via natural language. Agents can query attributes 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 Function and Action mechanisms. Functions execute computations and logic on business objects; Actions modify objects or trigger operations per defined rules, with permission and validation controls.
For example, in similar business systems, an approved substitute material can be written back to the relevant business object via a controlled action for downstream use. What can be modified, who has permission, and whether conditions are satisfied 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 confirmed that multiple agents perform linked analysis around the Ontology, humans retain key decision rights, and the system continues processing after human choices.
At runtime, Ontology also depends on underlying data accuracy. If ERP material status isn't updated timely, 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 Underlying Data
Equipment Forge isn't Eaton's first AI use in engineering and supply chain. At DevCon 4, Eaton development lead Takoda Denhof presented a production-running engineering document automation pipeline.
Figure 2: DevCon 4 session: Process Orchestration × Eaton (Takoda Denhof × Matt Hawes)
Engineering specification files lack uniform format; some run thousands of pages. Previously, engineers read each manually, located technical requirements, and compiled information for downstream design and business processes.
Eaton uses AIP Process Orchestration to automatically process these files. The system reviews complex engineering specs, extracts information, and converts results into native Ontology objects for downstream business logic. Palantir's DevCon 4 official write-up lists 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 attributes and relationships.
Equipment Forge's requirements analysis echoes this earlier practice. Customer-submitted unstructured engineering requirements are matched against Eaton's product standards and historical engineering knowledge by an agent, which identifies special conditions and passes the derived constraints to the BOM Availability Agent.
Both presentations involve engineering knowledge moving from unstructured files into Ontology, then being used by downstream business logic. However, Eaton hasn't disclosed whether Equipment Forge directly reuses internal components from the DevCon 4 project, nor the specific document parsing models, object schemas, or inter-agent communication protocols.
Beyond documents, another effort is integrating 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 stated 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, the agent must bring these data together in the context of a single business case.
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 applications with object query, filter, aggregation, and loading capabilities.
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.
These services are part of Palantir's publicly disclosed platform architecture; Eaton hasn't 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 propagate to BOM and supplier checks; a long-lead-time component is discovered; the user evaluates a second supplier; the system re-analyzes dependencies based on 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 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, with humans stepping in when supplier and delivery trade-offs arise.
Equipment Forge has not yet disclosed how many real orders it covers, which factories are deployed, or the long-term production accuracy and tangible benefits of multi-agent analysis. Eaton's goal is to let Engineer-to-Order business retain custom design capability while achieving response efficiency closer to Configure-to-Order . The talk also envisioned future customer self-service for manufacturability, delivery times, and the impact of different choices.
For a complex order, the final delivery date often depends on many interlinked conditions. A part needing a year to arrive cannot have its supplier's actual capacity changed by an agent , but the agent can surface the problem early, clarify which configurations are affected, and assist the user in evaluating 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 depends on future production data disclosures.
References Palantir AIPCon 11 (September 10, 2026): Delivering the Power Infrastructure for AI | Eaton at AIPCon 11 Palantir: Process Orchestration × Eaton | DevCon 4 Snowflake (October 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
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
DataFunSummit
Official account of the DataFun community, dedicated to sharing big data and AI industry summit news and speaker talks, with regular downloadable resource packs.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
