A reasoning layer for hardware engineering

A mechanical engineer at a mid-sized manufacturer costs her employer, fully loaded, somewhere between $150,000 and $180,000 a year. In a representative week she will spend roughly a fifth of her working hours hunting for information that already exists somewhere inside the company, and another quarter on documentation, change paperwork, and follow-up chasing that no one with her training should be doing. The remaining time is what the company actually hired her for.

This is not a time-management failure. It is the default state of every hardware organization in the world, from a forty-person robotics startup to a hundred-thousand-person OEM. The operational surface beneath the PLM, the ERP, the MES, the quality system, the CAD vault, the supplier portal, the Teams threads, and the dozen spreadsheets that hold the actual truth of the business is a substrate no one designed and no one owns. It has no line on the org chart and no line in the budget. It consumes, by honest accounting, a third of the productive capacity of the most expensive engineering labor in the building.

Forty years of enterprise software have quietly accepted this as a cost of doing business. It is not a cost of doing business. It is the largest untaxed inefficiency in industrial engineering, and until eighteen months ago it was technically impossible to address. That constraint is gone. The companies that move first will open a productivity margin over their competitors that cannot be closed by hiring.

Ask a hardware engineer what they did last Tuesday. The honest answer, if they trust you, is some version of the following. They opened a ticket about a field failure on a galvanized bracket. They pulled the drawing from the vault, checked the part history in the PLM, opened the ERP to find which open orders contained the affected assembly, cross-referenced the supplier's qualification status in a spreadsheet maintained by procurement, dug through an email thread from nine months ago to find out why the original material was chosen, messaged the quality lead to ask whether a stainless substitute would require re-qualification, and then, once they had arrived at the judgment they had been hired to render in the first place, spent forty minutes filling out the ECR form in the correct format and copying the same information into three downstream trackers so nothing would fall through.

None of this is engineering. All of it is the job. The industry has, over time, made a decision it never explicitly made: the scarcest and most expensive labor it employs should be used as a human integration bus between systems built in different decades by vendors with no commercial incentive to interoperate. The engineers are not the problem. They are doing exactly what the tooling forces them to do. The tooling is the problem, and the tooling has been the problem for so long that the industry has stopped noticing.

The second-order effects are where the real money hides. A change that takes a week to route through the approval chain is not a one-week cost; it is a week of downstream teams building against a spec that may already be obsolete. A decision whose rationale lives only in a retired engineer's sent folder is not a minor documentation gap; it is a latent defect in the organization's memory that will surface, expensively, the next time someone tries to touch the same subsystem. Rework, launch delays, scrap, warranty exposure, and engineering turnover all trace back, with depressing consistency, to the same root cause: the context required to make good decisions is scattered, stale, and unreachable at the moment it is needed.

The instinct of every hardware executive confronted with this problem is to assume their PLM vendor will solve it. They will not. The incumbents are not lazy and they are not unaware. They are structurally disqualified, and the reason is worth stating carefully because it defines the shape of the opportunity.

PLM, ERP, MES, and QMS are, by design, databases of record. Each owns an authoritative slice of the world — product structure, transactions, execution, conformance — and each has spent decades optimizing for the integrity of its own slice. Their commercial model depends on being the authoritative store. It does not depend on, and is in some cases actively harmed by, interpreting the stores they do not own. A PLM vendor that built a high-quality analytical layer over ERP data would be doing unpaid work for its largest competitor. It does not happen, and the political economy inside their customers makes it harder still.

The deeper disqualification is philosophical. The incumbents record what happened. They do not, and cannot, explain why. The rationale behind a material change, the field failure that triggered it, the supplier conversation that constrained it, the trade-off the program manager accepted on a Thursday afternoon — all of this lives in email, chat, meeting notes, and human memory. The databases of record have no hook for any of it. When the person who made the decision leaves, the why leaves with them, and the organization is left with a row in a table and no ability to interrogate it. Every subsequent change to the same subsystem is then made with a corrupted understanding of the one that came before. This compounds for decades, and it is why mature hardware companies are so often surprised by their own products.

Fixing this is not a data integration problem. Connecting the systems is table stakes. The hard part is answering questions that no dashboard can answer: if we switch this fastener from galvanized to stainless, what happens to the open orders, the in-process WIP, the qualified supplier list, the production schedule, the cost roll-up, and the three downstream assemblies that were qualified against the original spec — and is the change worth making in the first place? Until recently, no software on earth could answer that question. A senior engineer with twenty years of institutional memory could approximate it. Nothing else could.

For the entire history of enterprise software, automating a workflow meant specifying it. You wrote the rules, encoded the exceptions, maintained the rule base as the business changed, and accepted that anything the rules could not anticipate would fall back to a human. This is why the last mile of every serious manufacturing process still runs on Excel and email: the exceptions are where the real work lives, and the exceptions cannot be pre-specified.

Reasoning models collapse this constraint in a narrow but decisive way. They make it possible, for the first time, to automate work that requires reading unstructured context, interpreting it, and acting on it with the judgment of a competent junior engineer. This is exactly the kind of labor that dominates hardware operations. It is not frontier R&D. It is the vast middle: pulling the right document, verifying the right field, notifying the right stakeholder, flagging the right risk, composing the right ECR, and catching the one thing everyone else missed because no human reads every email. It is the work engineers complain about on Friday afternoons, and until now no software company could credibly touch it.

The capability landed in the vertical least prepared to absorb it. Manufacturers run older systems, longer qualification cycles, heavier regulatory overhead, and thinner internal AI expertise than their software-native peers. This is not a reason for pessimism. It is the reason the opportunity is as large as it is. The gap between what is now technically possible and what these companies currently do is wider here than in any other industry, and the ones that close it first will not be operating on the same cost curve as the ones that do not.

Sutra is the interpretive layer above the existing manufacturing stack. It is not a PLM, an ERP, or a replacement for any database of record. It has no ambition to become one, and this is the point. The opportunity is defined precisely by the fact that the incumbents cannot pursue it, and any company that tries to both own the authoritative data and interpret across the authoritative data will lose to a company that does only the second thing.

The architecture has three components and they are deliberately narrow. The first is a unified interaction surface across every system where engineering context actually lives — PLM, PDM, ERP, MES, quality, email, chat, document stores, spreadsheets — accessible through natural language. An engineer asks a question about a part, a supplier, a change, an order, or a failure, and receives an answer with its sources in seconds. The value of this alone, measured honestly against the baseline in the opening section, is on the order of eight to ten hours recovered per engineer per week. Most enterprise software sells for less on larger claims.

The second is impact analysis. Before a change is committed, Sutra reads across the full operational context and returns what the change actually implies: which bills of materials are affected, which open orders are exposed, how the production schedule shifts, what the cost and lead-time trade-off looks like, whether quality needs to re-qualify, what to do with existing inventory, and which stakeholders need to be looped in before the decision is finalized rather than after. This is work that senior engineers and program managers currently do in their heads, incompletely, under deadline. When it is done well, it is invisible. When it is done badly, it is the field failure that shows up six months later and eats the quarter.

The third is the execution of the repeatable. Most operational workflows in a hardware organization are templated and low-judgment once the underlying decision has been made. ECR creation, stakeholder notification, form filling, approval chasing, traceability logging — every company already has SOPs for these, and no one follows them faithfully because no human can. Sutra executes them. Agents navigate the people, the processes, and the context on autopilot, and the engineer returns to the work she was hired to do.

The sequencing is deliberate. Sutra begins by sitting inside an existing workflow and augmenting it. It observes how decisions are actually made, rather than how the SOP says they are made. It watches where the judgment calls live and where the rubber-stamps live. It begins making suggestions. It begins doing the paperwork. Over months, it captures the decision logic itself, and the workflow runs end to end with the engineer reviewing rather than executing. This is not a replacement for engineering judgment. It is the first product in the history of the industry that treats engineering judgment as the scarce resource it is and refuses to spend it on anything else.

The near-term product pays for itself in hours recovered per engineer per week and will be bought by anyone who takes a pilot seriously. The medium-term product owns the repeatable operational workflows of a hardware organization end to end. The long-term product is the memory of the industry — the layer that knows why every decision was made, what it depended on, what it implied, and what happened next, and that makes this knowledge queryable, auditable, and actionable across the entire organization. For the first time in the history of manufacturing, tribal knowledge stops walking out the door when a senior engineer retires.

This is also the prerequisite for every other AI ambition a hardware company currently has. The present conversation about “AI in manufacturing” is largely wishful, because the context any useful model would need to reason over does not exist in unified, queryable form. Sutra builds that substrate as a side effect of being useful on day one. The companies that deploy it are not merely recovering engineering hours; they are becoming the first hardware organizations in which AI can be applied to anything real at all.

The case against building this is that the problem has been ignored for forty years, and nothing that has been ignored for forty years can be as valuable as it looks. The case against that case is that the capability required to solve it has existed for eighteen months. Every hardware company that intends to be competitive in a decade will need this layer. The only remaining questions are who builds it, and whether it is built by a team that understands the problem is reasoning, not records. Both questions have the same answer.