Alex Kendall and the decision to test embodied AI in London

A complex city becomes a useful proving ground for autonomous-driving technology when it supplies varied, frequent interactions that can be tested within a controlled safety system. Difficulty alone is not evidence of readiness. The developer must define where and how the system operates, collect interpretable safety evidence, use trained human supervision where required and advance from testing to passenger service only through explicit gates.

That is the strategic value, and the risk, in Alex Kendall's decision to build and test Wayve from London. The city exposes a driving system to dense mixed traffic, irregular street layouts and continual negotiation with people. Those conditions can accelerate learning. They can also make a weak system dangerous and produce a misleading story in which a striking demonstration is mistaken for dependable commercial operation.

Embodied AI made the road part of product development

Wayve's current leadership page identifies Kendall as co-founder and chief executive. It says the company was founded in 2017 and describes its approach as embodied intelligence for autonomous driving. In plain terms, the software has to connect perception with action in the physical world. It does not only classify a picture. It must interpret a changing scene and support a safe driving response over time.

That requirement changes where development happens. Simulation and controlled tracks allow repeatable tests, including dangerous cases that should not be created on a public road. Public-road testing reveals interactions that a team did not know to model: a delivery vehicle blocking a lane, a cyclist filtering through traffic, temporary works or ambiguous gestures between road users. A serious programme needs all three environments, because none supplies complete evidence alone.

London's value is the density of such interactions. A short route can include buses, pedestrians, cycles, taxis, narrow streets and different junction designs. The system receives many opportunities to encounter uncertainty. The company can also recruit engineering and research staff around its headquarters and work near prospective transport partners.

The cost is that every public-road test is an operational safety activity. The organisation needs maintained vehicles, trained operators, route controls, incident escalation and high-quality records. Real-world data are not free raw material. They are created inside a safety and governance process.

A difficult city provides coverage, not universal proof

If a system handles a demanding London route, that can show progress within the tested conditions. It does not establish that it will handle every London road, another British city or a motorway in another country. The traffic rules, road markings, weather, vehicle fleet and behaviour of other road users change across locations.

The important technical idea is an operating boundary. A developer should state the roads, speeds, weather, times and supervision under which its evidence applies. It should also identify the situations that cause the system to seek human intervention or leave its intended domain. Without that definition, "tested in London" is a marketing phrase rather than a reproducible claim.

Complexity can create selection bias too. A company may publish its smoothest journey while learning from many interventions elsewhere. An independent reviewer needs totals: distance or operating time under defined conditions, interventions classified by cause, incidents, near misses, system versions and the exposure against which each event rate is calculated. A video is valuable for showing behaviour, but it cannot supply the denominator.

London should therefore be treated as one demanding evidence environment. Transfer to another city needs fresh validation, local mapping or other localisation where the system uses it, regulatory approval and operational preparation. Generalisation is something to test, not something to infer from the model architecture.

Testing, supervised rides and driverless service are different stages

Wayve and Uber announced supervised autonomous rides in London in September 2026. The word "supervised" is essential. A trained person who can intervene changes the risk-control system and the claim that the service supports. It is a meaningful move beyond an internal engineering run, but it is not the same as an unsupervised public service.

Four stages should be reported separately. Development testing asks whether the system is improving and where it fails. A supervised passenger pilot adds a real service journey while retaining human oversight. A driverless pilot removes that in-vehicle fallback within a defined operating domain. Commercial deployment then requires repeatable service, fleet availability, customer support, insurance, maintenance and viable economics.

Press releases often compress that ladder into "launch". Founders and journalists should attach a control description to every milestone: who is in the vehicle, who can intervene, which roads and times are included, and who carries operational responsibility. A passenger booking a ride cares about those facts more than the nominal automation level.

Wayve's 2026 funding announcement sets out its intended commercial direction, but investment and partner interest are inputs rather than proof of safe scaled operation. Capital can fund validation, vehicles and deployment teams. It cannot substitute for evidence at the next gate.

UK rules make the safety case an operating document

The UK government's 2026 code of practice for automated-vehicle trials sets expectations for public-road work, including a safety case, roadworthy and insured vehicles, competent supervision, data recording and engagement with relevant authorities. The code keeps responsibility with the trialling organisation even when technology suppliers and partners are involved.

That is a useful management blueprint. A safety case should link hazards to controls and evidence. It should change when the system, route or supervision model changes. An intervention is not merely an embarrassment to exclude from a demo. It is evidence about a hazard, a boundary or an operating procedure.

The Automated Vehicles Act 2024 creates a statutory framework for authorised self-driving vehicles and responsibility, but an enacted framework does not mean every trial vehicle is authorised for general driverless use. Detailed implementation and the facts of a particular service still matter. Government work on a statement of safety principles also makes clear that deployment will be judged against a human-driver safety benchmark rather than a promise of zero collisions.

For a founder, regulatory work therefore belongs beside model development. Evidence formats, responsibility between partners and post-incident data access should be agreed before a public pilot. Retrofitting them after a high-profile event is slower and less credible.

Commercial deployment is a system of partners

An AI driving model is only one component of a mobility service. Vehicles need compatible sensors and controls. A fleet operator needs maintenance and cleaning. A ride platform handles demand and support. Insurers and public authorities need intelligible risk information. Remote assistance, if used, requires staffing, connectivity and clear limits.

Wayve's partner-led route can potentially place its software into vehicles and services that already have manufacturing and customer channels. That may reduce the need to build every layer. It also creates interfaces at which responsibility can become unclear. If a vehicle, model, operator process and ride platform contribute to an event, the parties need agreed logs and escalation before assigning blame.

Commercial readiness also requires unit economics. Supervision is a cost as well as a safety control. Specialist hardware, cleaning, remote support and low vehicle utilisation can change the economics of a pilot that appears busy to passengers. The relevant commercial evidence includes service availability, paid utilisation, intervention staffing and maintenance, not just ride numbers.

What other embodied-AI founders should learn

Choose a test environment because it reveals the failure modes that matter, then state the limits of what it proves. Maintain an evidence matrix linking simulation, controlled testing and real-world operation to specific requirements. Publish enough denominator information for outsiders to interpret headline events.

Next, define progression gates before public attention arrives. A successful supervised pilot should lead to a pre-agreed review, not automatically to reduced supervision. Include the safety operator, deployment team and external authorities in that decision. Treat operating procedures as part of the product.

Kendall's London choice is compelling because the city resists simple driving rules. The durable company will not be the one that turns that complexity into the best film. It will be the one that turns it into documented evidence, improves the system and earns permission to operate at the next stage.

Limitations and questions for publication

This profile uses Wayve's leadership and deployment announcements together with UK government and legislative sources. It does not include interviews with Kendall, safety operators, passengers, Uber, vehicle manufacturers, insurers, regulators or independent road-safety researchers. Company statements establish announced activity and strategy, not independent measures of safety, system capability or commercial viability.

Before publication, Shoreditch Talk should confirm whether the described London service remains supervised, define its operating boundary and request exposure, intervention and incident data by system version. An independent specialist should review any comparison with human drivers. The article should also identify the legal entities responsible for the vehicle, driving system and passenger service. No statement that Wayve is driverless, safer than a human or commercially deployed at scale should be added without direct evidence.