Writing
Not All AI Problems Are Language Problems - AI in Advanced Manufacturing
A reflection on agentic AI, advanced manufacturing, physical systems, and why intelligence is broader than language interfaces.
I was fortunate enough to spend some time recently at the University of Nottingham with Giovanna Martinez Arellano, talking about AI, agentic systems, and some of the problems being explored in advanced manufacturing. It was a conversation that was both energising and humbling. In my own work, I’ve been spending a lot of time looking at Agentic AI, orchestration, and the idea of self-organising systems - most of that naturally sits in the world of digital systems, knowledge work, software delivery, business processes, and AI-enabled products.
Giovanna’s work is focused on AI in advanced manufacturing. Think aerospace, high-value engineering, precision components, complex materials, and production environments where the tolerances are tiny and mistakes are expensive. The University of Nottingham has an incredible research environment for this: The Omnifactory. Much of the research group’s work is directed towards a vision of a factory that is highly flexible, highly configurable, and highly intelligent. Rather than being optimised for mass-producing thousands of identical things, their research and “The Omnifactory” is aimed at the production of complex “ones” - the kind of specialist parts, assemblies, and systems that may only be produced in very small numbers, but need to be manufactured with extraordinary precision. The Omnifactory is a factory that can, in principle, reconfigure itself around the thing being made.
There were some super interesting contrasts in our daily-exposure to AI and how the problems we’re encountering are framed.
In the AI conversations I have most often, the starting point is usually information: documents, emails, tickets, reports, customer requests, workflows, knowledge bases and approvals. The challenge is understanding, organising, routing, generating, or acting on information that is expressed through language.
Many of the examples Giovanna talked through started somewhere else entirely. They started with materials, machines, movement, tolerances, sensors, and physical processes. The challenge was not understanding what somebody meant, but understanding what was happening. That difference sounds obvious when written down, but it connects directly to the idea behind the title of this piece: not all AI problems are language problems. Some are rooted in the behaviour of physical systems, and that changes both the nature of the problem and the kinds of intelligence that are useful in solving it.
As someone who spends a lot of time discussing AI in organisational and digital contexts, walking around that environment was a useful reminder that AI is a broad field of study. It did not make me think, “manufacturing needs LLM agents”. If anything, it made me wonder whether those of us working around digital transformation, consultancy, and AI-enabled products have allowed the current LLM wave to shape our mental model of what Agentic AI looks like.
In knowledge-work settings, that framing often makes perfect sense. Language models are a natural fit for documents, emails, tickets, decisions, workflows, customer requests, internal knowledge, and human-facing processes. But in physical and operational environments, agencies can look very different. It can be a drilling system adapting to material behaviour, a vision model detecting degradation, a robot cell responding to an unexpected component state, a sealant process adjusting to a material that is curing as it is being used, or an orchestration layer co-ordinating machines, people, tools, parts, and enterprise systems.
The question I’ve been sitting with since is not whether all of these things should be called agents. It is whether our current conversations about Agentic AI are broad enough to comfortably include them.
The problems looked simple until they didn’t
One of the projects we spoke about was high-performance drilling. On the face of it, drilling a hole sounds like the kind of thing manufacturing has surely already solved. The reality, particularly when working with advanced materials, is much more complex. Different layers of material, microscopic gaps, unknown defects, varying resistance, heat, pressure, vibration and tool wear all change the problem as the process unfolds. The machine is not just executing a fixed instruction. It is operating in a changing physical context, where the right next action depends on what is being sensed and inferred in the moment.
Another project focused on sealant application and extrusion. Again, there is a version of the problem that sounds straightforward: move a robot arm to the right location and squeeze a tube of sealant. You might be surprised to hear that movement of the robot is not the hard bit of that problem. The hard bit is applying the right amount of material, at the right pressure, with the right consistency, while the material itself is changing over time. Some sealants cure as they are being used, including inside the tube the robot is trying to squeeze. That means the system has to account for time, pressure, flow, visual feedback, material behaviour and the desired end state of the seal itself.
We also discussed research around robotic hand-offs between stations. There were movable beds, configurable frames, robot arms with interchangeable tooling, and autonomous delivery robots moving around the shop floor. That immediately brings you into the world of orchestration, but not the clean and abstract version we often talk about in software. This is orchestration with physical constraints: the part has mass, the robot has reach, the tooling has tolerances, and the machines may have been designed independently, by different vendors, at different times, with different assumptions. Getting the whole system to work together is both a robotics problem and a software interoperability problem.
The final area we discussed was on systems that orchestrate measurements and adjustments as manufacturing and assembly progress. When you are producing complex structures, you cannot simply make thousands of parts independently, bring them together at the end, and hope everything lines up. Errors compound and small deviations matter. If you are working on something like a fuselage or a spacecraft component, the tolerances are extremely tight and the consequences of getting it wrong are significant. You need to measure and adapt as you go, because the process of making the thing changes the state of the thing being made.
Across all of these examples, the AI challenge was not really about automating a business process. It was about understanding and responding to physical state. The data was not primarily documents, messages or tickets. It was voltage, pressure, speed, force, video, geometry, movement, defects, material behaviour and time, which naturally leads you towards different kinds of systems.
Where LLMs Fit in Manufacturing
A lot of the AI conversations I find myself in are shaped by language because a lot of the business problems I see are shaped by language. Customers describe what they need in emails, calls, drawings, reports, rubrics, care records, assessment notes, historic files, PDFs, spreadsheets and systems that were never really designed to support the way the work actually happens.
Processes are often semi-structured, with just enough shape to look repeatable, but enough human variation to make traditional automation painful. That is where LLMs are genuinely useful. They are good at working with messy language. They can extract intent from an email, summarise a long document, identify missing information, generate structured outputs, classify requests, draft responses, and help humans navigate large amounts of organisational context. When people talk about AI making businesses “better, slicker, faster”, a lot of the immediate opportunities sit here, because so much organisational work is still mediated through language.
Manufacturing businesses are not exempt from that. In fact, one of the things I have seen first-hand when looking at order processes in one UK manufacturing business is how human some of these interactions still are. This is something that occurs in many manufacturing organisations, particularly older or less digitally mature businesses where processes have evolved over many years around people rather than systems. A customer may ask for something by email via a long-running relationship with someone who “just knows” what they mean. There may be an ERP system somewhere, but the path into it is often full of human interpretation, manual rekeying, and informal knowledge that sits with individuals rather than the organisation. That is a very natural place for LLMs to help, because the job is to turn semi-structured human communication into something the organisation can act on.
The focus of the conversation with Giovanna was not really on those kinds of language-centric business processes. The challenges we explored were much more rooted in physical systems, operational constraints, and the realities of manufacturing environments, where understanding and responding to the state of the world has simply been prioritised ahead of problems centred on interpreting documents or processing emails.
The conversation kept returning to systems that were interacting with the physical world. Systems that needed to observe, infer, adapt and respond based on what was happening around them. Once you start looking at those kinds of environments, you begin to encounter AI in forms that are much less language-centric.
Advanced manufacturing is one example, but it is hardly the only one. Utilities, infrastructure, logistics, energy and transport all contain similar patterns. Consider something like infrastructure inspection. A utility company inspecting electricity pylons is not primarily dealing with documents. It is dealing with assets distributed across a landscape. The raw inputs might be drone footage, photographs, weather conditions, maintenance history, location data and sensor readings. The challenge is identifying deterioration, damage, risk or change.
The useful intelligence in that system may be recognising cracks, corrosion, loose fittings, vegetation encroachment, damaged insulators or subtle signs of degradation that would be difficult for a human to spot consistently at scale. Language enters the picture later, when findings need to be explained, documented, prioritised or turned into work orders. Seen this way, the language model becomes one component in a larger system rather than the centre of it. The expertise may sit in computer vision models, simulation systems, control loops, optimisation engines, sensor fusion, or highly specialised models trained on a particular operational problem.
When does a system start to feel agent-like?
The phrase “Agentic AI” is somehow becoming increasingly overloaded and at the same time increasingly narrow. In a lot of the commercial technology conversation, an agent is implicitly an LLM with tools: something that can receive an instruction, reason about what to do, call APIs, use data sources, maybe maintain some state, and produce an answer or take an action. That is a useful pattern, and it is one I am actively interested in. There is a lot of value in systems that can co-ordinate work across tools, services, documents and people. But the manufacturing examples made that definition feel too narrow.
A drilling system that senses material behaviour and adapts its approach is doing something that feels agent-like. A sealant extrusion system that changes pressure based on curing behaviour and visual feedback is doing something similar. A robot cell that detects a missing component and decides whether to continue, stop, change tooling or escalate is operating in much the same territory. None of these systems necessarily need to be conversational, and none of them necessarily need an LLM at their core.
That does not mean every adaptive system should suddenly be labelled an agent. There is still value in being precise. A deterministic service with a fixed API is not an agent simply because we have renamed it, and a control system is not automatically agentic because it reacts to a signal.
What I found myself thinking about instead was the relationship between agency and expertise. An LLM agent is often useful because it can navigate ambiguity, language, organisational context and human interaction. An expert system may be useful because it understands a very specific operational domain in extraordinary depth. It might specialise in visual inspection, robotic control, battery disassembly, drilling, routing, scheduling or anomaly detection, using computer vision, reinforcement learning, optimisation, simulation, time-series analysis or techniques that have little to do with language models at all.
The more examples Giovanna talked through, the more it felt like these systems belong in the same broad conversation, even if they are built very differently. Part of the reason this stood out to me is that we all tend to view AI through the lens of the problems we encounter most often. If your world revolves around documents, workflows, enterprise systems and customer interactions, then LLM-based agents feel like the natural evolution of AI. If your world revolves around robotics, manufacturing processes, inspection systems or physical infrastructure, that framing may feel incomplete.
Thinking Across Multiple Layers
One thing that emerged from the conversation was how many different layers of activity have to come together for a vision like the Omnifactory to work. This is not to say that every AI problem should be viewed as needing layers of orchestration. Many AI use-cases are much narrower and can deliver value without needing to consider an entire organisational ecosystem. But in the kind of advanced manufacturing setting Giovanna is working within, it becomes difficult to ignore the interactions between different levels of the system.
At the level of a single manufacturing step, there may be sensing, inference, control and feedback happening in near real time. A drilling operation is not simply a task on a process map. It is a dynamic system with inputs, constraints, measurements, decisions and outcomes. The timescales are completely different from the organisational workflows many of us associate with AI agents.
At the level of a manufacturing cell or sequence of operations, attention shifts towards co-ordinating machines, tools, parts and movement. A part may need to be drilled, inspected, moved, sealed, measured, adjusted and assembled. Each station has capabilities and constraints. Each hand-off introduces uncertainty. If something is missing, damaged or outside tolerance, the system needs to determine what happens next.
At the organisational level, the problems start to look much more familiar. Orders, designs, contracts, schedules, supply chain constraints, ERP systems, customer updates, compliance and reporting all sit around the manufacturing process. This is where language-heavy systems and LLM-based agents begin to fit naturally into the picture.
Beyond that sits the wider environment: weather, regulation, geopolitics, material availability, energy prices, demand forecasts and strategic priorities. At that level, AI starts to blend into forecasting, simulation and decision support.
In reality, most organisations modernise incrementally, tackling one problem at a time. The value of the example was that it made it easier to see how different forms of intelligence can exist at different levels of a system, each solving a different kind of problem. Some may benefit from language models. Others may benefit from optimisation, planning, computer vision, simulation or traditional control systems.
AI still has to live inside real systems
There was also a familiar theme running through many of the examples we discussed: integration.
The Omnifactory vision depends on systems working together across boundaries: robots, tools, sensors, models, workstations, delivery systems, enterprise platforms, researchers, operators and engineers. Some of those systems are modern. Some may be old. Some were designed to interoperate. Many probably were not.
Anyone who has spent time around software delivery, DevOps, enterprise architecture or digital transformation will recognise the challenge. Integration has long been one of the places where ambitious projects struggle, and much of the DevOps movement emerged in response to exactly those kinds of organisational and technical disconnects.
AI does not magically remove that complexity. In some ways, it adds another layer to it. If you introduce a model that can interpret state and recommend action, you still need to decide how it receives data, what it is allowed to do, how confidence is represented, how exceptions are handled, how humans remain in control, how decisions are audited, how the system is monitored, and how failure modes are managed.
This is where I think there is genuine overlap between advanced manufacturing, utilities, cyber, logistics, healthcare, public sector operations and many other domains. The data and domain expertise differ, but the architectural questions often sound remarkably similar. What is the source of truth? What state does this component own? What events matter? What happens when information is incomplete? When should the system act autonomously, and when should it escalate? How do we observe behaviour across the whole system rather than just individual components?
That is also where consultancies and technology teams can add value, provided we do not reduce every AI conversation to the tools we happen to know best. The work is rarely just selecting a model. It is understanding the environment, shaping workflows, defining boundaries, integrating with existing systems, building feedback loops, making behaviour observable, and ensuring humans can intervene when necessary.
Not everything intelligent looks like chat
Whilst there were immediate, practical things I could take away and apply to conversations I am already having - particularly around the use of computer vision and YOLO video models for problems like utilities inspection, asset condition monitoring and visual fault detection - it also left me with a more reflective discomfort about how easily I default to thinking about AI through the lens of language models.
That is somewhat understandable - LLMs are where much of the current hype, investment , and customer interest sits. They are also genuinely useful, particularly in the kinds of organisational contexts I spend most of my time working in.
But spending time with somebody approaching AI from a very different direction was a good reminder of how much broader the landscape really is. There are forms of intelligence that do not look like chat, do not produce prose, do not reason through natural language, and do not need to mimic human communication to be valuable. Some of the most impactful AI systems may be almost invisible to the people using them. They may sit inside inspection processes, control loops, robotic cells, planning systems, maintenance workflows or manufacturing operations.
That does not make LLMs less relevant. If anything, it makes the overall picture more interesting. You can easily imagine environments where language models sit at the organisational and human-facing layers, helping people interact with complex systems, while specialised models and expert systems operate closer to the physical reality of the work itself.
A human might ask a natural language question about production status, asset condition, maintenance priorities or operational risk. The answer may ultimately come from a collection of systems that understand video, sensor data, geometry, workflow state, historical patterns and domain-specific constraints.
That feels like a richer way of thinking about Agentic AI than simply imagining a collection of chatbots calling tools.
Reflecting on AI vs LLMs
The main thing I am taking away is a question for myself and for others working in similar spaces: when we talk about Agentic AI, what range of systems are we actually talking about?
In many organisations, LLM-based workflow automation will absolutely be where value is found. There is nothing wrong with that. But it is only one expression of AI, and perhaps only one expression of agency.
Sometimes the challenge is understanding material behaviour as a manufacturing process unfolds. Sometimes it is identifying deterioration in physical infrastructure. Sometimes it is co-ordinating machines that were never designed to work together. Sometimes it is making continuous adjustments while something is being built, because waiting until the end means the opportunity to correct has already passed.
Those problems require intelligence too, but they are not language problems. They are problems of observation, interpretation, adaptation and control, rooted in the behaviour of physical systems rather than the interpretation of human-style communication.
The broader point, at least for me, is that the part of AI closest to our own work can very easily become the whole of AI in our heads. Spending time with people working in different domains is a useful reminder that the field is much broader than the slice we happen to see every day.
As more organisations try to work out what AI means for them, the shape of the problem should influence the shape of the solution. Different environments, different constraints and different forms of expertise naturally lead to different kinds of intelligent systems, and recognising that starts with accepting a fairly simple idea: not all AI problems are language problems.