Aitomatic and the factory FDE: the hard work lies outside the model

“A confident wrong answer is dangerous on the fab floor.” That sentence does not come from a workplace safety manual. It appears on the homepage of Aitomatic, a company selling what it calls “Digital Engineers” to physical industry.

For anyone who wants to be an FDE, that line is worth more than many job descriptions. No public FDE listing from Aitomatic has been found, so any picture of the role at the company should be treated as inference.

Even so, public material on the company points in a fairly clear direction. In factory AI, the hard part of deployment probably lies outside the model: getting the knowledge out of engineers’ heads, connecting it with production data, then proving the system knows when it might be wrong. If this is the field you are aiming for, those are the things to practise.

An open base model does not tell the whole story

SemiKong, Aitomatic’s open-source model for semiconductors, was built on Llama 3.1 70B, according to a Meta case study. That detail alone does not show where the hard work lies, since tuning a base model for semiconductors can also be very laborious.

A clearer clue lies in how the company is described. Meta writes that Aitomatic helps semiconductor businesses capture and scale their deep expertise through Domain-Expert Agents (DXA).

A 2024 case analysis on the Zilliz blog describes the OpenSSA architecture, meaning small specialised agents, with a process that opens by capturing knowledge from process engineers and equipment experts.

Many people can download an open base model, but the expertise in the heads of a factory’s engineers can only be obtained on site. That is the reason to infer that the hard part of a deployer’s job lies here.

So the first task is probably a conversation rather than a line of code. If you have never deliberately practised this skill, start here.

Imagine asking an equipment engineer: “When do you stop the machine?” He replies: “When this signal looks a bit odd.” That answer is not yet usable, and asking more about the general procedure rarely helps.

Ask instead about the last three times he stopped the machine. Which signal looked odd, odd compared with what, was there a time it looked odd and he kept running, and who had the authority to decide? Each such story gives you a draft rule and a test case drawn from real life.

Phoenix shows where the bottleneck is

Why go to such trouble over expert knowledge? The Zilliz post uses TSMC as an example: with the same technology, results still differ between fab projects, and the fab in Phoenix, Arizona struggled for lack of on-site expertise.

This bottleneck is not confined to the United States. VnEconomy, in a piece published on 13 March 2025 around AISC 2025, summarised the view of Aitomatic’s CEO that Vietnam still lacks AI experts and highly skilled semiconductor engineers. The two settings are very different, but both turn on people with expertise.

The notable detail is TSMC Arizona’s listing for an AI Forward Deployed Engineer, also in Phoenix. Do not rush to treat the two facts as cause and effect. What is worth reading is one line of requirements in the listing: a solid understanding of software engineering fundamentals and agile development methods.

One line does not speak for the whole posting, but it is enough to draw a piece of advice. To get into factory AI, you should not abandon your trade to relearn semiconductors from scratch. Software engineering remains the ticket in, while knowledge of the factory is what you must pick up quickly enough to talk with the people running the machines.

Six items on a homepage make a data exercise

Aitomatic’s homepage describes the context of semiconductor manufacturing with six things: equipment, recipe, lot, process state, quality and yield. Read as an engineer, this is almost the brief for your first week at a customer.

Imagine the yield of a lot drops and an engineer asks the agent why. To answer, the system must know which equipment the lot passed through, which recipe it ran, what the process state was at the time, and which run the quality results belong to.

Now suppose the lot ID in the quality system does not match the one in the equipment log. Then, however good the model, the answer rests on two wrongly joined records, and it still sounds very confident.

So the first thing to do is pick one real question, map the path its data takes, and check every join before touching the prompt.

94% can still mean 144 errors per shift

Aitomatic reports a result of its own in semiconductors: 2,400 defects classified per shift at 94% accuracy. This is the company’s claim, with no independent evaluation so far, so treat it as a place to start asking questions rather than a conclusion.

The arithmetic is simple: if that rate applies across the whole shift, 6% of 2,400 is 144 misclassifications. The 94% figure does not say where those 144 fall.

Suppose a shift includes 100 defects of a type that could ruin a whole lot. In theory, the system still reaches 94% even if it misclassifies all 100, and it also reaches 94% if all 144 errors fall on less harmful defects.

The same number can mean a major risk or a good tool, and only analysis by defect class can separate the two.

At a customer, this is where your job begins. Ask the engineers which defect types they cannot afford to miss, measure those separately, and design a branch that passes uncertain cases to a person rather than guessing. The warning about the fab floor at the top of this article, once written as code, looks exactly like this branch.

Combining the signals into a practice plan

Each document above reveals only part of the job. The table below brings those parts together; the middle and right columns are inference and advice, not official job descriptions.

Public signal	Work you may meet at a customer	How to practise and prove it
Capturing knowledge from process and equipment engineers	Interview people on the machines, rewrite what they say as rules	Turn three real incidents into test cases, and put the full example in your portfolio
Context of equipment, recipe, lot, yield	Connect data across several systems, handle mismatched IDs	Write a trace of one defect across at least two data sources
Small specialised agents (OpenSSA)	Scope a narrow problem rather than a general assistant	Build an agent that solves only one type of question and states clearly what it refuses
Confident errors are dangerous; self-reported 94%	Measure by defect class, design a hand-off branch to people	Publish a confusion matrix and hand-off rate, not just accuracy
Production deployment with continuous optimisation	Monitor and fix the system after go-live	Describe a time your system degraded and how you found out
TSMC requires software fundamentals and agile	Write production code, not just demos	Keep tests, CI and code review in your sample project

The jobs may not be only at Aitomatic

In February 2025, Aitomatic announced that its DXA Factory platform had been chosen by ITOCHU Techno-Solutions and FPT for global deployment, with FPT aiming at industrial AI. If this model expands, much of the deployment work could go through system integrators.

This is still inference, but it suggests a broader way to look for work. Do not search only for the title “FDE” on an AI company’s site.

Read listings from integrators and factories as well, and look for the real signs: working directly with process or equipment engineers, who looks after the system after go-live, and whether production data falls within the scope of the job.

The same announcement gives the final stage of the DXA lifecycle as production deployment with continuous optimisation. Use that phrase as a template for your CV: a line saying only “built agents for factories” says very little, while a line stating whom you took rules from, which defect class you measured and what you fixed after reaching production tells the whole job.

In interviews, you can also turn the tables with one question: “The last time your system gave a confident wrong answer, what happened next?” How they answer tells you where the real work lies.

A demo can win on smooth answers. On the fab floor the measure is much harder: the first time your system says “not sure”, the engineer on shift still trusts it.