On November 12, Anthropic released Claude for Manufacturing. One plugin, 17 skills, 4 connectors: Autodesk Fusion, Infor, Microsoft 365, Oracle NetSuite.
The official example is very specific: a batch of steel arrives two weeks late, and the procurement officer asks Claude which customer orders are affected and how much steel the other plants still have; after the procurement officer approves, with a plugin released by Infor itself, Claude can place a purchase order with another supplier and reschedule the affected production in Infor.
This message was interpreted as "AI has begun to touch ERP." But among the 17 skills, the hardest is neither placing orders nor production scheduling—it is quoting.
1. Among the seventeen skills, what quotation has to flip through is the entire factory's ledger
The plugin covers six domains: sales, quality, operations, supply chain, design, and system settings. The official description of the quoting skill is: read customer requirements, list missing information, compare the costs of similar work orders, and draft a quote for publication. There are four actions in this sentence, and each corresponds to a type of data.
| Skill Domain | Official example | Dependent system data | The Cost of Making a Mistake |
|---|---|---|---|
| Sales | New work order quotation | Actual orders, inventory, production steps, work order costs (NetSuite) | Quote too low and you lose money; quote too high and you lose the order. |
| Quality | Inspection Failure Investigation and Corrective Action Report | Reports on similar historical issues, inspection records | Measures do not address the root cause, and the problem recurs |
| Operations | Production Report | Production targets, equipment downtime, downtime losses | Downtime costs cannot be calculated clearly, so there is no basis for improvement. |
| Supply Chain | Sourcing from other suppliers, RFQ, and quote comparison | Purchase orders, inventory, supplier historical quotes | Wrong inquiry target selected; delivery date cannot be made up |
| Design | Fusion Model Variants and Scoring | Existing model, engineer target parameters | The variant cannot be manufactured; this round was wasted. |
| System Settings | Conversational onboarding ("Set us up") | Accounts, interfaces, and permissions for each system | Thought it was connected, but it's actually only half-connected |
A quotation must assemble seven categories of data: BOM version, routing and standard labor hours, work center rates, yield and loss, available inventory (including items under inspection and reserved), subcontracting and freight, and exchange rates and tax rates. If any one category is an estimate, the quotation is an estimate—AI merely delivers this estimate to the customer faster.
It is worth noting that the four things the NetSuite connector retrieves are: actual orders, inventory, production steps, and work order costs. The first three determine 'whether it can be made,' while the last determines 'whether it is profitable after being made.' Only when these four are all in place can you 'quote based on actual cost'; yet the current situation for most enterprises is standard cost plus markup, with variances left to be absorbed in one go at year-end.
Proportion of manufacturers still manually entering data in the 2025 Manufacturing Leadership Council survey (cited by Anthropic on the release page)
This number brings the problem back down to earth. If work order costs, labor hours, and yield rates were always entered by hand in the first place, plugging in an LLM won't make quotes more accurate—it will only make wrong quotes come out faster and sound more plausible.
There is another distinction that is often confused: cost visibility does not mean cost quotability. If work order costs are only aggregated at the order level, there will be no usable reference when a new model comes along; only when they are aggregated at the operation level—labor hours, yield, and rate for each operation—can a new drawing be broken down into an estimable combination of operations. This also explains why the connector uses the two items "production steps" and "work order cost," rather than a single total amount.
II. Connectors are read-only; writes are left to the original manufacturer: this division of labor is correct
There is a detail on the launch page that is easy to overlook: the Infor connector for Claude for Manufacturing only supports querying records; to modify data, you have to use the plugin that Infor itself released.
This is not a lack of capability; it is a division of responsibility. The risk of read operations is "seeing what one shouldn't see," which is addressed through permissions; the risk of write operations is "making a wrong change that cannot be restored," which is addressed through validation, approval, and audit trails in the business system. Putting these two things into the same connector is equivalent to letting an external analysis tool bypass all the control points of the original system.
Query connector
Read-only. Permissions follow the logged-in user. If it answers wrong, you can ask again — the cost is one conversation.
Write plugins
Modifying documents. Goes through the original system's validation and approval flow. A mistake means a reversal, an explanation, and evidence on file.
The official announcement also states two design principles: every task ends with user review; and Claude can link numbers and conclusions back to the underlying data and documents. The second matters more than "accuracy" — if the reviewer can only see a paragraph of conclusions, all they can do is believe it or not believe it; only when they can follow links back to the original documents are they actually reviewing.
Don't casually turn "can query" into "can modify."
The most likely moment in a demo: the purchasing manager sees the AI identify the affected orders, then asks, "So can it just change the delivery dates?" That one sentence turns the project from an "analytics tool" into a "write-operation project" — budget, approval levels, validation scope, and rollback plans all have to be redone. Write operations must be a separate project; don't sneak them into a reporting project and launch them quietly.
3. Permission inheritance is convenient, but what it inherits is an expired authorization table
The official documentation is explicit: Claude's access permissions follow the user's own permissions in Infor. Architecturally this is very clean — no need to build a separate account system, and in an audit you can clearly answer "who it represents."
The problem is that it inherits "this person's permissions at this moment," and those permissions are often the result of historical accumulation. Roles changed without revocation, projects ended without cleanup, temporary authorizations left switched on — these are the norm in enterprises, not the exception. Handing them to an agent that reads data 24/7 amounts to amplifying all that legacy at once.
The quotation scenario is especially sensitive. Sales should see price lists and lead times; cost accounting should see work order costs and rates; purchasing should see supplier quotes. The three visibility surfaces are different by design. If, for convenience, you run it with an account that has broad permissions, the AI sees the whole company's cost structure — and then writes it into a quote that will be forwarded to a customer. That isn't a technical failure; it's an information leak.
The most dangerous thing isn't the AI quoting the wrong price — it's the AI writing a cost structure that sales should never see into a quote that will be forwarded externally.
There are two more hidden entry points: a departed employee's account was never disabled, and the agent is still reading data on their behalf; and pricing approval and cost data maintenance are handled by the same person, so the moment the AI is connected, that separation-of-duties wall is torn down. Neither shows up in the permission table — only process checks can find them.
4. Before connecting to Odoo, fill in four tables first
If you want to land this capability on Odoo, don't rush to connect a model. Without those four tables in place, it doesn't matter which model you connect.
- Cost basis table. Standard cost, moving average, actual cost — which one is the quotation basis; BOM versions and effective dates; which materials are priced by lot.
- Labor hours and rates table. Work center rates, setup hours and quantity tiers, and how outsourced operations are priced. In Odoo these correspond to work centers and operation times; leave the fields empty and quoting can only rely on guesswork.
- Yield and scrap table. Yield, scrap rate, and rework rate by operation. This is the most easily overlooked item, and the one most capable of throwing a quote off by a dozen points.
- Quote version and validity table. Price lists, currency, exchange rate as-of date, approver. A quote has a shelf life, and the model doesn't know which version is still valid.
All four tables share one requirement: every entry must have an "effective date." For tables without effective dates, both people and models can only guess from context — and the guessed cost is exactly the kind of error that most resembles an answer.
Three actions for the CIO:
- First, backtest ten historical quotes. Take real quotes that were won and real quotes that lost money, have the AI recompute them from existing data, and compare the differences. Wherever the differences cluster, fix that table — don't start by rewriting prompts. Prompts can't cure dirty data.
- Snapshot permissions by role, not by individual account. Create a dedicated role for the quoting agent whose permissions equal what the role should have, inheriting no one's historical authorizations; departures and role changes trigger permission reviews instead of waiting for an audit to discover them.
- Use general-purpose connectors for reads, and vendor plugins for writes. Write paths must go through the original system's validation and approval, with human confirmation and a rollback plan retained in between. This isn't being conservative — it's what lets the project pass internal controls.
A quote is the only piece of paper in a manufacturing company that simultaneously states cost, price, and commitment. AI can write it faster, but writing it correctly presupposes that those seven categories of data already have an owner, a version, and an effective date.
Back to that batch of steel that was two weeks late. What really let the buyer press approve wasn't how smart the model was, but that the orders, inventory, and work order costs it checked were all in the system, and that they could follow the links back one by one. The barrier to getting an agent into ERP has never been on the model side.
Sources: Anthropic, "Introducing Claude for Manufacturing" (2026-11-12, including 17 skills, 4 connectors, permission following, human review, and the "does not operate equipment" statement); the 2025 Manufacturing Leadership Council survey cited on Anthropic's announcement page (79% of manufacturers still enter data manually); Infor's manufacturing plugin documentation released around the same time; AI Soda's "Daily AI Hotspots November 13" Chinese summary of the above announcements (2026-11-13).
Notes on sourcing: the skill list, connector scope, permission inheritance method, and "every task ends with user review" are all quoted from Anthropic's official announcement page; the steel delay case is an official example, not a verified customer case, and the official page discloses no named customers. The 79% figure is self-reported by survey respondents, with no sample size or questionnaire text available, so this article treats it as a "vendor citation." The seven categories of data and four tables required for quoting are a distillation of implementation experience and do not represent the official positions of Anthropic or Odoo.
