Superintelligence in Textile Manufacturing: Orders, Sizes and Deadlines

Superintelligence in textile manufacturing, in practical terms, means a layer of AI agents that works from your real production data and answers only what is recorded. The safest way to start is to give the agent structured data on orders, size runs and production stages. It can then report status and lead times to B2B customers on WhatsApp and alert your team when a stage drifts from the agreement. Without that foundation, AI only writes well-phrased answers about information nobody has confirmed.

Key takeaways

• The agent should read orders, size runs and stages from structured sources. It should never infer a deadline from old conversations.
• A size run is data with rules (style, color, size, quantity). It needs to be split into the ordered size run, the cutting size run and the produced size run.
• Promised date, forecast date and actual date are three different fields, and the agent may only quote what production planning (PPC) has validated.
• Delays are flagged by objective triggers and handed to a person, not by the model's impression.
• The ideal starting point is a single flow, such as order status lookup, with every answer logged and a success metric agreed in advance.

Why is a textile order harder for an agent than it looks?

A textile order is rarely one line with a product and a quantity. It carries style, color, print, fabric, sizes, washing, trims and, often, approval of a pilot piece. Any one of these items can delay delivery without the sales team noticing.

The B2B customer (a retailer, a wholesaler, or a garment maker buying from a knitting mill, for example) asks a simple question: when does my order ship? The correct answer depends on whether the fabric has arrived, whether cutting is released, whether the subcontracted sewing shop has capacity, whether the laundry has returned the lot and whether shipping has a slot. In many companies, that information lives in the ERP, in PPC spreadsheets, in WhatsApp groups and in the memory of whoever walks the shop floor.

If an AI agent is connected to that disorganized mix, it tends to repeat stale information or fill gaps with something plausible. In B2B service, a plausible but wrong date is worse than "I will confirm with production." That is why the work starts with data and rules, and only then with the language model. The same logic applies to other areas of the plant, as described in how to start with AI in manufacturing, beginning with maintenance and quality.

Anthropic's own guidance on agents follows the same spirit: prefer simple, predictable workflows, and add autonomy only when it is needed and verifiable. Here the autonomy is deliberately small: read, explain and alert.

How do you structure the order and size run so the agent can read them?

The first step is to separate what is a recorded fact from what is free text. The agent needs clear fields. Free text (salesperson notes, voice messages, emails) enters only as secondary context, marked as unconfirmed.

An order that an agent can read usually has these fields:

• Order and customer identifiers, with the contact authorized to receive information.
• Styles included, each with description, fabric and color.
• Size run per style and color, with quantity per size.
• Order entry date, the date promised to the customer and the conditions of that promise (for example, color approval).
• Current stage, with status, owner and expected completion date.
• Open items, such as pilot approval, a missing trim or a down payment, when it is a condition for production.
• Commercial rules that affect the answer, such as whether partial delivery is allowed.

About the size run: it is the distribution of quantities by size (and by color) within a style. The most common mistake is treating it as a single number. In practice there are at least three versions: the size run ordered by the customer, the cutting size run (which can change because of fabric yield and marker layout) and the size run that was produced and checked. If the agent does not know which one it is quoting, it passes on ambiguous information, such as saying an order is complete when only the medium size has been finished.

It is also worth recording the size run rules as data: minimum multiples per color, whether the customer accepts color substitution, whether they accept quantity variation on delivery and who has authority to approve exceptions. These rules stop the agent from promising something the company would not do.

How do you define lead times the agent can safely report?

For the agent, a lead time should be a set of fields, not a sentence. We recommend separating three concepts:

• Promised date: what was agreed with the customer and is on the order.
• Forecast date: the current PPC estimate, based on the remaining stages.
• Actual date: what really happened at each stage, used for audit and learning.

Each stage (fabric purchase or arrival, approval, cutting, sewing in-house or at a subcontractor, laundry or finishing treatment, trimming, quality check, shipping) should have a planned date, an actual date, an owner and a status. Date calculation, with capacity, holidays and dependencies, should stay in deterministic rules in the system or in PPC. The language model does not recalculate lead times: it reads the result and explains it clearly.

In practice, this means building lookup tools with a closed return. Instead of giving the agent free access to a spreadsheet, we offer a function such as get_order_status that returns the current stage, the forecast, open items and the date of the last update. Anthropic has good material on how to design tools for agents, with emphasis on clear returns and names that do not confuse the model.

Two precautions make a difference. The first is stating the age of the data: if the subcontractor's last update was many days ago, the agent should say so and not treat the forecast as current. The second is recording conditions: if the lead time depends on the customer approving the color, the agent mentions that dependency in its answer, which avoids friction later.

When and how should the agent flag delays?

Flagging a delay does not mean asking the model to "notice" problems. It means defining objective triggers that the system checks and that activate the agent or a person. Some common triggers:

• The forecast for a stage has moved past the date promised to the customer.
• A stage has gone without an update for longer than PPC accepts.
• A dependency (fabric, trim, approval) is still pending close to the start date of the next stage.
• The checked size run differs from the ordered size run, with a shortfall by size or color.
• A subcontractor or laundry reported a quality problem and requested rework.

When a trigger fires, the recommended flow has four steps. The agent logs the alert with the data that caused it. It routes the alert to the owner (PPC or sales) with a short summary. It waits for the human decision on the new date or the solution, such as a partial delivery. Only then does it tell the customer, with the validated date and the cause in plain language. The agent does not invent a new date or offer compensation.

If the message to the customer is outbound, over WhatsApp, there are channel rules the agent must respect: the service window, approved templates and the contact's permission. We cover this in the WhatsApp 24 hour customer service window and how an AI agent should act. Without that care, the delay notice may simply not be delivered or, worse, cause problems for the business number.

There is also a governance point. If the agent starts to influence who gets priority in production or delivery, the decision stops being purely informational and moves into sensitive territory. Even in B2B relationships, it is wise to keep human review and a record of the criteria, in line with the discussion of automated decision-making under LGPD and the right to review. Customer contacts are personal data, so the agent should also see only the orders of the customer it is talking to.

Illustrative scenario: order status at a garment maker

Imagine a women's fashion garment maker that sells to retailers and produces part of its pieces at subcontracted sewing shops. This is an illustrative scenario, unrelated to any real customer.

A buyer writes on WhatsApp asking about an order for a dress collection. The agent identifies the contact, confirms they are authorized in the customer record and calls the lookup tool. The result shows that cutting is complete, sewing is at the subcontractor with completion expected the following week, and finishing has not started. The promised date is unchanged, with a note that the subcontractor's forecast was updated recently.

The agent replies with the current stage, the forecast and the date of the last update, and asks whether she wants to be notified when the order is checked. It quotes no amounts and promises nothing beyond what is recorded.

Days later, PPC records that a trim (the zipper for one of the colors) has not arrived. The pending dependency trigger fires. The agent creates an alert for PPC with the style, color and affected stage. PPC decides to deliver the other colors first and sets the new date. Only then does the agent tell the buyer, explaining the cause and offering partial delivery if the commercial rule allows it. If she wants to negotiate something different, the conversation goes to the responsible salesperson with the history already summarized.

How do you apply this in practice without putting operations at risk?

The method we use with companies has four moves: map, limit, pilot and hand over. Applied to textile manufacturing, it looks like this:

• Map: document how an order is created, where each stage is recorded, who updates what and how customers ask today. Measure the starting point, such as the time spent answering status questions and how often information conflicts.
• Limit: define which data the agent reads (only the order of the customer in the conversation), which actions it can take (look up, summarize, open an alert) and what always stays with humans (new date, discount, size run exception, quality complaint).
• Pilot: choose one real flow, such as order status lookup, with a log of every answer, the sources consulted and a success metric agreed with operations. Before it talks to customers, test with simulated scenarios, using techniques such as mock tools and sandbox testing for AI agents.
• Hand over: give the team the documentation, the rules, the monitoring dashboard and the criteria for deciding whether the project expands, adjusts or stops.

It is worth treating risks explicitly. The NIST AI Risk Management Framework offers a useful vocabulary for mapping and managing risks in AI systems, and the ANPD is the reference for data protection guidance in Brazil. Neither replaces the concrete design of the rules in your own process, but both help organize the internal conversation.

Frequently asked questions

Can AI calculate the delivery date of a textile order? It can support the calculation, but the date should follow PPC and system rules, with capacity, dependencies and calendar. The agent reads the result and explains it to the customer. If it recalculates on its own from loose text, the risk of promising a wrong date goes up.

Do we need a new ERP to put an AI agent in this flow? Not necessarily. What matters is that orders, size runs and stages sit in consistent sources that can be reached through a controlled lookup, whether that is an ERP, a database or even a well-kept spreadsheet at the start. If each department records things differently today, the first project is to standardize the fields, and that brings value even without AI.

Should the agent notify customers about delays automatically? It can notify them after a person validates the new date and the message, especially in cases with commercial impact. For outbound WhatsApp messages, you need approved templates and the contact's permission. Routine notices that do not change a promise can be automated with more freedom, as long as they are logged.

How do you stop the agent from answering about another customer's order? With access control in the lookup tool, not only in the model's instructions. The function should return only orders tied to the contact authenticated in that conversation, and attempts outside that scope should be blocked and logged. This protects customer data and reduces the risk of a leak through error or through manipulation of the conversation.

Sources

• Anthropic: Building effective agents
• Anthropic: Writing effective tools for agents
• NIST AI Risk Management Framework
• ANPD: Autoridade Nacional de Proteção de Dados