“People should be a little loony … That’s the best thing about them.”

Harry Domin says this to Helena in Karel Čapek’s R.U.R., the 1920 play that gave the world the word “robot”. In R.U.R. humans produce humanoids that are extraordinarily capable with great memories built to do jobs.

Domin meant it as a compliment to humans. A robot doesn’t need less of that loony. It needs someone to write it down. Because the environment it works in was built by humans, the environment full of specific, undocumented, sometimes irrational rule that only makes sense to someone experienced.

I found this unexpectedly relevant to what is happening today. A century later, companies are approaching a much more literal version of the same problem.

The question shifts from “What AI model should we use for a job?” to “What to do when AI has hands?”.

Humanoid and mobile robots are moving from demos into real operations. Accenture, SAP and Vodafone have piloted humanoids in a Duisburg warehouse. BMW is piloting Hexagon’s AEON at its Leipzig plant. Agility Robotics’ Digit is operating at GXO. These are no longer just conference demonstrations.

And the companies running these pilots are discovering something familiar from AI, only faster and more expensively:

The machine may be capable. It still does not know your business.

This chapter is about the part nobody sells you. Not how the robot walks – that is a difficult engineering problem, but it is primarily the vendor’s problem rather than yours. How the robot learns your company, what to do when it gets your company wrong, and how to make sure the second robot does not have to learn the same lesson again.

A note that the following guidance does not work on a robot straight out of the box. It needs the robot’s own operations layer, an SDK, or a systems integrator’s build to expose a way in. A showcase unit running predefined routines has nothing to build on. If you’re evaluating vendors, ask directly whether operational knowledge can be corrected without touching firmware. That’s the real product question, not the walking.

Why does a robot arrive knowing how to walk but not how you work?

Because every deployment has two very different layers.

The first is the body: balance, grasping, navigation, perception and physical control. The manufacturer is responsible for making those capabilities work reliably enough for the intended task.

The second is the job: what fragile means in your warehouse, which pallets go to which dock, which exception applies on a Friday, and what to do when something unexpected happens.

That second layer is where your company-specific knowledge lives.

What actually goes wrong, and which failures are yours to fix

The first useful thing you can do is stop treating “the robot got it wrong” as one problem. It is three, they have completely different owners, and mixing them up is the reason pilots stall.

1. A capability mistake (not yours to fix). The robot physically could not do the thing reliably. It cannot grip that surface, cannot read that label at that angle, cannot fit somewhere. It is a vendor ticket or a decision to take that task out of scope. No amount of company knowledge will teach the robot to have a firm grip on something it cannot hold.
2. A knowledge mistake. The robot did exactly what was told but based on out of date or wrong information. Slot 5 is not the returns slot anymore. A supplier changed their packaging note back in June. The site map has changed…
3. A rule mistake. The robot’s information was correct and it still did the wrong thing, because your business has a policy nobody wrote down. Anything over 20 kg goes to the manual lane. Anything from that one client gets photographed before it moves. The robot was never told, because everyone who works there known for years.

The second and third categories are yours. Once the initial capability issues are understood, they become a major part of the operational work.

Let me use one example from the real world:

→ A humanoid should sort incoming parcels by the branded box they arrive in. Sometimes gets it worng, because customers reuse boxes, a return in a printer box is not a printer. A human picker notices something unusual, mutters, sorts the return correctly and carries on.

The robot sorted exactly what it saw, it might look like a knowledge mistake but in fact it is a rule mistake. The label on the box is more important than the box. Since it is not writtent anywhere, robot doesn’t know.

Now the important part. The human picker who spotted it is not the person who should decide what the company’s rule is, and the moment they spotted it is not a moment when anyone can sit down and write it. Every process that follows exists to solve that one problem.

Step 1: Ground the robot in what your company actually knows

Goal: stop the robot inferring your business from what it can see.

Grounding a robot means connecting it to the places your knowledge already lives rather than migratingeverything into the robot vendor’s system.
In practice:
– Connect the sources that describe your operation. SOPs, site layouts, handling exceptions, client-specific rules and safety instructions.
– Define what the robot is for, and what it is not for. A scope that a supervisor can read and use torecognise when a task falls outside it.
– Decide what happens when it does not know. An agent that invents an answer wastes someone’stime. A robot that infers a rule moves physical objects. Configure the fallback explicitly: stop, ask,escalate or route to the manual lane.

Start with one cell, one shift, one task. The rules you discover in the first fortnight will be wrong ininteresting ways. That is the point.

The perfect R.U.R. worker will not be created on day one. Give the machine a small piece of the company and make sure it can learn that piece without inventing its own version of the truth.

Step 2: Govern what the robot is allowed to do

Goal: make robots something you can approve, not something you supervise personally.

Three layers are worth setting up before the first unit is commissioned:
– Roles. The human picker flags. A reviewer diagnoses. A tutor – someone with authority and knows how the business works – decides what becomes the rule. Keeping those roles separate prevents a shift supervisor’s personal preference becoming company policy.
– Guardrails, stop conditions and approval checkpoints. Define what the robot must always follow, where a human is required and what actions need approval.
– An audit trail. Record what the knowledge was given to robot, how it is used, how confident the robot was and which human was accountable.

There is also a regulatory reason to build this early.

The exact legal requirements vary by jurisdiction and by the robot’s intended use. A humanoid may fall under several overlapping regimes governing machinery, workplace safety, product safety, AI, data and sector-specific obligations. But the direction is increasingly consistent: organisations need appropriate risk controls, human oversight, traceability and clear accountability for consequential automated behaviour.

I would suggest not design the governance system around today’s legal minimum because what the robot knew, what it did, why it did it, and who could intervene are typically questions asked by an insurer, a client, a regulator or a worker.

Step 3: Compound what the robot learns

Goal: make every correction and every discovery permanent, and shared.

This is the step almost nobody does, and with robots the cost of skipping this is very visible. You can watch four machines make the same mistake on the same afternoon.

Two things are worth capturing, corrections and discoveries.

1 – Corrections: fix the cause, not the incident

The hard part is not the fix. It is the capture. Nobody on a floor is sitting at a keyboard, and the moment a mistake happens is the worst possiblemoment to ask someone to write a considered account of it.

So separate the two.
The flag happens on the floor, in seconds. The correction happens later, at a desk, by someone qualified to make it.

Flags should cost almost nothing:
– A verbal or handheld flag. The human picker says or taps “that was wrong” and moves on. The systemcaptures the context: task, location, time, instructions, decision and reasoning.
– The robot’s own escalations. Every time it stops and asks a human, that exchange is a candidate for correction. The human already supplied the answer, it just went into the air instead of into theknowledge base.
– The end-of-shift exceptions list.
The decisions the robot itself was least confident about, reviewedby a supervisor rather than watched live.
Then a reviewer diagnoses which of the three mistakes it was and fixes the cause → Capability goes to the vendor → Knowledge means correcting the source: the site map, SOP or handling note.

2 – Discoveries: the things that go right and vanish

Corrections get attention because they hurt. Discoveries are worth more and get none.

Someone works out that approaching a pallet from the left never jams and from the right jams constantly. Someone finds a handoff sequence that removes a bottleneck. Someone notices that one supplier’s labels fail in the cold store.

None of this is necessarily a mistake. None of it may be in an SOP. And all of it can disappear at the end of the shift.

Elevating a discovery should be one action available to anyone.

The hierarchy

An elevated insight should move up one level from where it was found – from robot to cell, cell to site, siteto company, so the person who found it never has to work out who else needs to know.

And your elevated knowledge should not belong to one vendor. A mid-sized operation may soon run a humanoid from one manufacturer, mobile robots from another, and software agents in the back office. If the returns rule lives in the humanoid vendor’s cloud, the othersystems do not have it.

Follow the returns example all the way up.
A picker flags an improvement → A reviewer establishes that it is a rule → A tutor writes the rule once.

That same fact now improves the humanoid, the mobile fleet, the returns SOP and the support agent answering customers.

Why does this compound rather than just accumulate?

Because Step 3 feeds back into Step 1.

Every elevated rule becomes grounding knowledge. The next mistake is subtler. The next insight is worth more.

You are narrowing the gap between what your company knows and what its machines know. That gap is where much of the operational cost of deploying AI into the physical world actually sits.

Fleet management platforms such as InOrbit, NVIDIA Fleet Command, MiR Fleet and others tell you where robots are, whether they are running, how they are utilised and what errored. That is real and necessary.

But telemetry is not knowledge. This is the practical consequence:

The second robot should be dramatically cheaper to commission than the first.

If it is not, ask what the first robot taught you that the second one inherited.

If the answer is “nothing”, you built a pilot.

You did not build organizational memory.

So what can be done before the first robot arrives?

Before commissioning, write down the ten rules everyone already knows. Not the process. The unwritten ones. The exceptions, client-specific handling, and “we never do that on a Friday.”

Ask two experienced people to list them and let them disagree. The disagreements are valuable.

Week 1: decide who flags, who diagnoses and who decides. Three names. Confirm the audit trail captures what you would need to reconstruct a consequential decision.

Week 2: close the loop once, deliberately. Take one real mistake from floor flag to diagnosis to correction to shared knowledge.

Do it with content. The loop becomes obvious once you have seen it work.

Week 3 to 4: review the escalations, not just the incidents. Every question the robot asked a human is a gap in what it was given. That list is your roadmap.

After that, the discipline is simple: a weekly pass by someone with judgement, reviewing what was flagged and what was elevated.

That habit is the difference between a fleet that gets easier to run every month and one that is in permanent.

And there is a useful side effect. The rules you write for a robot are rules your software agents, new starters and SOPs need anyway.

The humanoid simply makes the absence of that knowledge system impossible to ignore.

The R.U.R. lesson

There is a final irony in Čapek’s play.

We started here because R.U.R. imagined artificial workers becoming increasingly like people. Its robots eventually acquire something resembling a collective will, and the humans discover that creating workers is not the same thing as controlling them.

But perhaps that is not the lesson companies should take from the play.

Your humanoid does not need consciousness, emotions, to become human.

It needs to know that the printer box isn’t necessarily a printer, which pallet goes where on Friday, what slot is right and wrong.

And when someone teaches it something important, the next machine needs to know it too.

The first robot is a worker. The second robot is a test of whether you remembered what the first one learned. The tenth robot tells you whether you built company memory.

The humans simply have to stop forgetting what they taught the robots.

---

Augela is an AI governance and knowledge platform for small and mid-sized businesses. It is EU-based and GDPR by design, works with Gemini, Claude, GPT, Perplexity or a local model, and charges one flat monthly price for your whole team rather than per seat or per token.