What robots do in production today is far narrower than what research demos show. The pattern TechnoLynx treats as deployable is a large language model (LLM) planning over a vetted library of robot skills, with a human in the loop for situations the library does not cover. Most robots in production environments still run narrowly preprogrammed routines in controlled conditions, and robots that learn new tasks from demonstration or instruction are still largely confined to pilot programmes. Before any of that comes a plainer question: can the expected outcome be reached at current capability levels? By TechnoLynx’s assessment, a repeatable, menial task automated reliably is far more likely to have measurable return than a robot expected to out-think its operators.
That framing decides most of the architecture below. For a component-by-component tour of which generative AI parts are deployable, covering planners, vision-language-action models, generative control policies and world models, the companion article goes deeper; here the focus stays on what reaches production and what stalls on the way.
What AI and robotics deployments run in production, not as pilots?
AI runs in production robotics where it handles a bounded perception or coordination problem inside an otherwise engineered system: navigation and fleet coordination in warehouses, vision-based targeting in agriculture, and human-robot collaboration in picking. The installed base gives the scale. The International Federation of Robotics (IFR World Robotics 2026) reports a global operational stock of industrial robots of 5 million units in 2025, with more than 600,000 new units installed that year. The IFR attributes part of the growth to advances in AI, machine vision and sensing, alongside easier programming and integration lowering deployment costs.
Service robots tell a similar story. Professional service robot shipments rose 24% to almost 250,000 units in 2025, and transportation and logistics led with 117,500 units, a 47% share, according to the IFR (September 2026). These robots are primarily used for transportation and material flows.
What are concrete examples of AI in robotics, such as autonomous mobile robots in warehouses, agricultural field robots, drone-based inspection, or collaborative robots for quality control?
Autonomous mobile robots (AMRs) have made a significant contribution to warehouse performance and productivity. A 2024 review of warehouse AMRs notes that, unlike automated guided vehicles, AMRs make their own decisions, need no pre-installed infrastructure to navigate, and can route around obstacles and other robots without a designer laying out paths. Locus Robotics reports that thousands of its AMRs run across more than 40 DHL Supply Chain sites as daily fulfilment rather than isolated pilots, and cites 30-180% increases in units picked per hour; those are vendor figures. Amazon reports that its DeepFleet foundation models, trained on millions of hours of fulfilment-centre data, help assign tasks and route robots around congestion, raising the efficiency of its robot deployments by 10%.
Agricultural field robotics gives an independently measured example. John Deere’s See & Spray uses boom-mounted cameras and onboard processors to scan over 2,500 square feet per second at up to 15 miles per hour, identify weeds and trigger individual nozzles. Deere reports the system was used across more than five million acres in the 2025 season, with customers cutting non-residual herbicide use by an average of nearly 50%. An independent University of Arkansas trial measured a 43-59% reduction in herbicide against broadcast application.
Collaborative picking shows how the work gets split. The 2024 AMR review describes robots that struggle with differently shaped items because of their end effectors, and humans who handle those items easily but tire from walking, so the robot meets the picker at the shelf and the picker places the product.
Humanoids sit at the other end: the IFR says recent advances have enabled impressive pilots, but most current applications remain specialised and often need human teleoperation.
What is the difference between AI and robotics, and when does a robot need AI?
Robotics is the engineering of machines that sense and act in the physical world; AI is software that learns from data or reasons over it, and a robot can run perfectly well without any. A welding robot repeats the same motion thousands of times a day with submillimetre precision, and when the task changes, engineers reprogram it by hand. That is classical programmed automation, and for a fixed task in a fixed cell we would choose it.
A robotic system needs AI when the variation it must handle cannot be enumerated in advance: objects of many shapes, layouts that change, routes that must adapt to traffic, or instructions given in natural language. The table below is how we would map the choice.
| Situation | Approach that fits | Why |
|---|---|---|
| Fixed task, fixed cell, known parts | Classical programmed automation | Predictable, analysable behaviour; existing safety standards were written for it |
| Variable inputs, fixed task (weed detection, object localisation) | Learned perception feeding engineered control | AI handles the variation; the action stays bounded |
| Many known sub-tasks combined differently each time | LLM planner over a vetted skill library | The planner sequences; the skill library abstracts away control |
| Open-ended tasks in unstructured settings | End-to-end vision-language-action model | Improved generalisation to novel objects, but high inference latency and no feasible formal verification |
Which layer of a robot stack should the LLM own, and which should stay fast and closed-loop?
In the stacks described below, perception turns sensor data into a scene description, planning decides which sub-task comes next, and control executes each sub-task in a closed loop. Localisation and mapping sits between perception and planning, giving the robot its own pose and a map to plan over. A 2023 survey sees potential for foundation models across the stack, from perception to control: LLMs generating code or common-sense reasoning, vision-language models giving open-vocabulary recognition.
Plan-Seq-Learn (PSL), a modular framework, makes the composition explicit. An LLM produces a high-level plan, a sequencing module uses off-the-shelf vision models to estimate target poses and reaches them with a motion planner, and a reinforcement learning (RL) policy learns the short-horizon, contact-rich interaction at each stage. Stage termination conditions (grasp, place, open) are checked from visual pose estimates so the system knows when to move to the next step. The PSL authors note that LLMs break long tasks into sub-goals well but lack a way to produce low-level control, while RL discovers control behaviours but struggles with long-term reasoning.
The rate mismatch keeps large models out of the fast control loop. GPT-4 calls added several seconds of latency in the Interactive Task Planning (ITP, 2023) experiments, and Text2Motion (2023) reports 2-10 seconds per API query. As an illustrative estimate, a16z’s Oliver Hsu puts manipulation control at 20-100Hz, and a 7B-parameter model on edge hardware at 50-100ms per inference, adequate for 10-20Hz but not for tight feedback loops. Model predictive control (MPC) or a learned RL policy runs the fast loop; the LLM decides what that loop should be doing next. Perception gets its own treatment in our piece on computer vision as the bottleneck layer in robotics.
Can LLMs handle robotic planning and reasoning at production reliability?
LLMs handle robotic planning best when they choose among skills that have already been built and tested, and even then the published success rates fall short of production bars. SayCan (2022) set the pattern: LLMs carry semantic knowledge but lack real-world experience, so pretrained skills and their value functions constrain the model to actions that are feasible in the robot’s actual environment. The PSL authors describe LLM planning over a predefined skill set as particularly effective across many robotics tasks, while noting these methods assume a skill library that abstracts away the control problem.
The failure data is instructive. On contact-rich nut-assembly tasks, SayCan’s success dropped from 86.5% to 41.5% on average because of cascading failures, and on tasks of 3-10 stages SayCan and task-and-motion planning averaged 37-38% against 95% for PSL, which learns each stage’s interaction control with RL instead of calling fixed skills. Text2Motion, which checks geometric feasibility across the whole skill sequence before executing anything, reached 82% on challenging tabletop tasks where prior language-based planners reached 13%. Code as Policies (2022) takes another route, having the LLM write policy code that processes perception outputs and parameterises control primitive APIs.
Model choice and hallucination are live constraints. The PSL authors found that of the publicly available LLMs they tried, only GPT-4 produced correct plans across all their tasks, and they still deleted plan components containing hallucinated objects or conditions. Judging planner reasoning quality before it touches hardware is taken up in our article on the AIME benchmark for planning reasoning.
So the answer to “can LLMs do this at production reliability” is yes only for specific task classes. A 95% planner in simulation is a promising research result, not evidence of a 99.9% production system.
What belongs in a skill library, and how it should be vetted
A skill library an LLM planner can call is a set of individually tested functions, each with a language description, a parameterised motion primitive underneath, and a way to judge whether it can succeed from the current state. ITP exposes Python skills such as grasp_cup and pour to GPT-4’s function-calling layer by parsing their docstrings, and its grasp_cup skill uses a feedback policy that centres the gripper on the cup so the grasp is reliable. Adapting ITP to a new task needed only new task guidelines and skill documentation.
The planner’s reliability depends on the fidelity of the skills it calls. Text2Motion trained a single policy per skill and reports Q-function precision and recall above 95%, with skill success of 99% for pick, 90% for place, 86% for pull and 97% for push. It also found that LLMs propose symbolically invalid skills such as picking up the table, which can get spuriously high value estimates, so it rejects any plan containing a skill flagged as out of distribution by ensemble variance. We would vet each skill as its own component: a measured success rate under realistic conditions, explicit preconditions, a termination check, and a refusal path when inputs fall outside what it was trained on. The weakest vetted skill caps the plan, because the planner can only be as reliable as the steps it chains.
As libraries grow, the planner should see only the skills relevant to the current task, which turns skill lookup into a retrieval problem; our article on the inverted file index for skill retrieval explains how IVF indexing speeds that vector search.
How do you wire an LLM planner into a robot’s control loop without breaking safety?
The LLM planner should never sit inside the control loop: it emits a sequence of skill calls, each skill runs its own closed-loop control, and a safety layer that does not trust the planner checks every plan before execution. The PSL authors make the point directly: their LLM only specifies where the robot should go and how to leave the area, and it is not capable of the low-level control, which is learned separately.
LLM-enabled robots inherit hallucinations and jailbreaking vulnerabilities, and the RoboGuard authors (2025) note that traditional robot safety ignores LLM vulnerabilities while LLM safety ignores physical risk. RoboGuard grounds predefined safety rules in the robot’s environment with a shielded root-of-trust LLM, then resolves conflicts with temporal-logic control synthesis; under worst-case jailbreaking it cut execution of unsafe plans from over 92% to below 3% without hurting performance on safe plans.
Standards set the floor underneath. ISO 10218-1:2025 (edition 3) gives safety requirements for industrial robots treated as partly completed machinery, with integration and applications covered in ISO 10218-2:2025, and it excludes service robots with public access, medical robots and consumer products. Collaborative robots near people must also meet ISO/TS 15066, and those standards were written for programmed robots with predictable behaviour, not learned policies. A planner choosing among certified, analysable skills keeps far more of the system inside the scope those standards were written for than a learned end-to-end policy does.
Where the human stays in the loop
Humans belong at three points: approving or interrupting plans, handling requests the skill library cannot serve, and recovering from execution failures. ITP lets a person interrupt at any stage with a new prompt, which triggers replanning that takes account of the updated goal and the steps already completed. When asked for a drink whose ingredient was unavailable, ITP said so and stopped rather than improvising. Graceful degradation is the handoff pattern to design for: the robot recognises unfamiliar territory and requests human help instead of failing silently. Our article on robots and humans working together looks at that division of labour from the operator’s side.
Pilots stall on reliability arithmetic, drift and integration
AI robotics projects stall between pilot and production partly because research measures mean success while operations pay for every failure. Hsu’s arithmetic is worth doing for any proposed deployment: a picking robot at 95% success attempting thousands of picks a day fails 50 times a day, each failure needs someone to clear a jam or restart the system, and manufacturing typically requires reliability above 99.9%. Failures also cluster: a 95% policy might fail half the time on the 10% of cases that differ from training.
Distribution shift compounds it. Deployment environments are out of distribution by definition, and Hsu gives the example of a policy at 95% in the lab that might drop to 60% in deployment because of lighting, textures and camera angles. Tensorleap, a vendor selling explainability tooling, describes the slower version: sensors drift, calibration degrades, success rates erode quietly, and teams eventually face failures they cannot explain from logs. Perception errors propagate through planners too; ITP’s authors note that misidentifying milk as taro jam would produce the wrong drink.
Then there is the facility. A deployed warehouse robot must take assignments from the warehouse management system, coordinate with other robots, report status and log events, and a policy that picks perfectly is of limited use if it cannot do those things. Maintenance is the last wall: a learned policy has weights rather than code, and diagnosing whether a fault lies in perception, planning, control, hardware or integration takes expertise most maintenance teams lack. Formal verification of a 7B-parameter model is infeasible, and testing can show the presence of failures but not their absence.
The leading opportunities and failure modes line up neatly. LLM planners pay off where natural-language instruction or task recombination saves engineering time over a fixed set of reliable skills; they fail on hallucinated steps, cascading errors across stages, perception mistakes passed upward, and latency that rules them out of anything fast. Hsu’s prescription is reliability engineering adapted for learned systems: failure clustering by root cause, graceful degradation that asks for help, hybrid architectures with programmed fallbacks, and runtime monitoring for drift, with the goal of failures that are recoverable, detectable and bounded.
Are embodied AI and physical AI different from AI in robotics?
Embodied AI refers to AI systems grounded in the physical world that learn through perception and action, and a 2025 policy paper places it at the intersection of LLM-based agentic AI and classical robots, since industrial arms lack autonomy and chatbots lack bodies. We treat “physical AI” as a near-synonym for embodied AI. By AI in robotics, by contrast, this article means a learned component (a detector, a fleet scheduler) inside an engineered system.
The distinction matters architecturally because of where the learned model sits. Vision-language-action (VLA) models cast control as next-token prediction over visual and language tokens. RT-2 (2023) co-fine-tunes a vision-language model on robot trajectories and web data, expressing actions as text tokens, and across 6,000 evaluation trials it showed better generalisation to novel objects and rudimentary reasoning such as picking the smallest object. That is measurable capability. Models such as Gemini Robotics-ER and NVIDIA’s Isaac GR00T N1 mark further algorithmic progress, though the same paper notes they are only slowly being paired with hardware able to use it.
The cost of putting the model in the loop is threefold: latency incompatible with fast control on edge hardware, hallucinations that become spatially grounded unsafe actions, and the reality gap between simulated training and the deployed world. An LLM planner over vetted skills sidesteps most of this by keeping the large model where seconds of latency are tolerable and its outputs can be checked. Whether a general intelligence would need a body of its own is a separate question, taken up in our piece on whether AGI would build its own body.
Embodied AI as a research agenda versus AI in robotics as an engineering practice
Embodied AI is a research programme aimed at general agents; AI in robotics as an applied AI engineering practice is the work of making a specific machine do a specific job at a stated reliability, integrated with the systems around it. The policy paper’s own recommendations show the gap: it calls for benchmarks of sim-to-real robustness, conformity with a stated operational domain and jailbreak resistance, and notes few such benchmarks exist yet. Hsu sees one plausible path as narrow deployments in constrained domains widening as reliability improves, with each deployment generating data for the next. That is the practice: ship the bounded version, measure it, widen the skill library.
A feasibility test before committing to an AI robotics deployment
Feasibility and measurable benefit should be established before any architecture is chosen, starting with whether the expected outcome is plausible at current capability levels. The checklist below is how we would run that test.
- Bounded task. Can the job be written as a finite sequence of known sub-tasks? If not, it is a research project, not a deployment.
- Reliability arithmetic. Multiply attempts per day by the expected failure rate to get daily interventions; at 95% success on 1,000 picks a day that is 50 a day.
- Skill coverage. Does every sub-task map to a skill with a measured success rate, preconditions and a refusal path?
- Latency budget. Is every model in the fast loop able to meet the control rate on the robot’s own hardware? Planner calls took several seconds in published experiments.
- Integration points. List the WMS, MES, fleet and monitoring interfaces the robot must speak to.
- Safety path. Which standard applies (ISO 10218-1 and -2 for industrial robots), and what guardrail checks plans?
- Baseline and payback. Measure the current process cost and set the payback threshold before the pilot, not after.
The See & Spray figures show what a payback case looks like. In the University of Arkansas trial, assuming a $25,000 See & Spray upgrade, the high-sensitivity setting saved $30.49 per acre, and used at early and mid post-emergence in one season the sprayer paid for itself after 819 acres, or 2,460 acres for a $75,000 upgrade. Deere prices the technology per acre ($1 per fallow acre, $5 per in-crop acre) so customers pay only when it delivers savings. Warehouse automation sits at a different scale: the 2024 AMR review cites $150-200 per square foot of initial investment for smart warehousing, recovered through long-term waste reduction. The See & Spray case is narrow: one perception task, one action, one measurable input saved.
Once an LLM planner is in the stack, its serving cost belongs in the same calculation; our article on LLM routing to cut cost covers one lever. When TechnoLynx takes on AI engineering for robots, drones and autonomous machines, this feasibility question is settled first: we focus on tasks that create value at realistic capability levels and say plainly when an outcome would need more than that.
The decision we would put to a team is not “LLM or not”. It is which sub-tasks are reliable enough to become skills today, and whether the remaining gap is small enough for a human to cover at an acceptable intervention rate. If that rate is computed honestly before the pilot, most stalls are predicted rather than discovered.
FAQ
Is robotic process automation the same as AI?
No. Robotic process automation is software that automates rule-based tasks in computer applications; it involves no physical robot and usually no learning.
How advanced are humanoid robots now?
According to the IFR (September 2026), humanoid pilots are impressive but most applications remain specialised and often rely on human teleoperation. Safety standards, high training and maintenance costs, and the lack of a strong business case still limit adoption.
Is ChatGPT a robot?
No. ChatGPT is a language model with no body, sensors or actuators, although models of that kind can serve as the planner that sequences a robot’s skills.
