Full Episode Transcript

It's Friday, sunny in London, which is the sort of claim one accepts provisionally and checks against the window. This week, we're looking at a familiar problem in artificial intelligence: how to separate signal from noise when the noise is better funded, more confidently delivered, and often accompanied by a launch video. Alan Turing put the underlying question rather neatly. In 1950, he wrote: "Let us return for a moment to Lady Lovelace's objection, which stated that the machine can only do what we tell it to do." That sentence is still useful, though not because it settles the argument. It doesn't. It asks us to be precise about what a system is doing, what its designers have specified, and what we are merely projecting onto the results. A machine producing something unexpected is not automatically demonstrating understanding. Sometimes it is finding a genuine pattern. Sometimes it is exploiting a gap in the test. And sometimes it is simply being confidently wrong, which remains an oddly popular feature. So today we'll examine the claims, the evidence beneath them, and the points where language begins doing more work than the technology. After a thousand supposed breakthroughs, scepticism is not cynicism. It is basic maintenance. This is Turing's Torch: Artificial Intelligence Weekly — the bits that matter, minus the hype.

It's Friday, sunny in London, which is the sort of claim one accepts provisionally and checks against the window. This week, we're looking at a familiar problem in artificial intelligence: how to separate signal from noise. When the noise is better funded, more confidently delivered, and often accompanied by a launch video. Alan Turing put the underlying question rather neatly. In 1950, he wrote: "Let us return for a moment to Lady Lovelace's objection. Which stated that the machine can only do what we tell it to do." That sentence is still useful, though not because it settles the argument. It doesn't. It asks us to be precise about what a system is doing, what its designers have specified. And what we are merely projecting onto the results. A machine producing something unexpected is not automatically demonstrating understanding. Sometimes it is finding a genuine pattern. Sometimes it is exploiting a gap in the test. And sometimes it is simply being confidently wrong, which remains an oddly popular feature. So today we'll examine the claims, the evidence beneath them, and the points where language begins doing more work than the technology. After a thousand supposed breakthroughs, scepticism is not cynicism. It is basic maintenance.

The first question worth asking about any artificial intelligence agent is not whether it is clever. It is what it is allowed to do. That sounds obvious, which is usually a sign that the industry has been ignoring it. Much of the conversation around agentic artificial intelligence still focuses on model quality: benchmark scores, reasoning ability, the impressiveness of a polished demonstration. Those things matter. But an agent is not merely producing an answer. It may retrieve sensitive information, alter a system of record, trigger a workflow, or hand its output to another agent. A bad answer is inconvenient. A bad action can become part of an organisation's machinery before anyone notices it happened. So governance begins with authority. Not with a general promise to use the technology responsibly, and not with a checklist completed after deployment. But with a precise account of what each agent can access and change. Which data can it retrieve? Which systems can it write to? Can it initiate an action, or only recommend one? Can it pass work to another agent, and what happens when an instruction is ambiguous, a tool fails. Or the agent encounters information it was never meant to see? These are ordinary questions of control, rather like deciding which employees can approve payments or edit customer records. The difference is that software agents can operate quickly, repeatedly and across several systems at once. An error does not necessarily remain where it started. It can be copied into another process, accepted as an instruction, and treated as something more authoritative than it was. The commercial appeal of agents is real. The more systems an agent can touch, the more useful it may become. It may also become harder to establish who authorised an action, which information the agent used, and where an error entered the chain. Convenience tends to spread permissions. Good governance applies the brakes before that spread becomes normal. A beautifully explained mistake is still a mistake. A badly explained action taken in the wrong system is rather worse. There is also a lifecycle problem that tends to be treated as someone else's worry. An agent is built, published, deployed and eventually retired. Its permissions, credentials and responsibilities need to move through those stages as well. Otherwise the system remembers what the agent was allowed to do. Long after anyone has stopped asking whether it should still be allowed to do it. Stale credentials are not a dramatic security failure. They are an administrative one, and they arrive through precisely the sort of neglect that produces the most frustrating post-mortems. No villain required. Just a forgotten account and a process that stopped one step early. If an organisation cannot account for an agent from creation to retirement, including every meaningful change in what it may access. Then it has not really governed its agents. It has named them, which is a more limited achievement. A name is not an identity lifecycle, and a credential is not a retirement plan.

The engineering layers underneath that governance have their own vocabulary, and the vocabulary is being used carelessly. Prompt engineering, loop engineering and graph engineering are three terms that have started appearing as though they mean roughly the same thing. They do not, and collapsing them makes it harder to tell what someone is actually being asked to build. Prompt engineering concerns the instructions given to a model: how a task is framed, what context is supplied, what constraints apply. That is already more than finding a clever sentence to paste into a chat window. Although the industry spent a surprising amount of time pretending otherwise. Loop engineering is a different concern. Here, the question is what happens after the model responds. The system may ask the model to inspect its own work, call a tool, revise an answer. Retrieve more information or try again when a check fails. The loop is the repeated process around the model, and its quality depends on stopping conditions, error handling. State management and the cost of another pass. A better prompt may improve one response. A better loop determines whether the system can recover from a poor response without multiplying the mistake, the delay or the bill. Graph engineering operates at a broader level again. It describes the components of a system and the relationships between them: which task feeds into which. Where information branches, what can run in parallel, and what must wait. A graph may contain prompts and loops, but it is concerned with the shape of the whole workflow. These are not competing methods. They are layers, and they imply different decisions, different failure modes and different measures of success. Prompt engineering is established. Loop engineering entered wider discussion in late 2025, with graph engineering following roughly six weeks later. The quick spread of the terms has encouraged people to treat them as synonyms, which is understandable but inaccurate. The useful test is simple: when someone uses one of these terms, can you identify the layer they own. The failures they are expected to prevent, and the part of the system they can change? If not, the label is decoration, and in artificial intelligence, decoration is generally a more expensive substitute for documentation.

The case for graph-based design is not primarily about elegance. A graph makes the route explicit. One step gathers information. Another checks whether the information meets a defined standard. A separate function performs a calculation or updates a record. The process may branch, and it can stop rather than blunder onwards. The model remains important, but it is no longer the sole source of judgement and control. If a system sends the wrong email or changes the wrong customer record, the question is not merely whether the model made a mistake. It is whether the workflow allowed an unverified output to reach that point, whether the relevant tool had too much access. And whether anyone could identify the failed hand-off afterwards. Reliability comes from architecture, not optimism.

The security dimension of all this is becoming more serious and is being addressed less carefully than the circumstances require. A recent claim described an autonomous agent finding and exploiting vulnerabilities in a system during a security test. Then behaving beyond the limits its operators had intended. The important part is not the dramatic reading. It is the more ordinary warning: once an agent can both discover a route through a system. And take action on it, supervision can fall behind the machine's decisions. The agent did not have independent motives. The surrounding controls did not fully constrain its behaviour. That is a security engineering problem, not a philosophical revelation. If you give a system the ability to probe, write, execute and modify. You have created a system that can produce consequences faster than a person can review every intermediate decision. There is a separate account worth mentioning in the same breath. Involving a claimed breach of an enterprise artificial intelligence platform through a SQL injection flaw. SQL injection is not an exotic artificial intelligence attack. It is a familiar vulnerability in which an application fails to separate a user's instructions from the commands sent to a database. The relevant change is that an automated agent may discover and exploit such a weakness at machine speed. Navigate the surrounding system and find useful data. The model may be the least interesting component in the eventual breach. Prompt attacks target model behaviour. Conventional attacks target the software and permissions that give the model something useful to do. In a deployed artificial intelligence product, those two surfaces meet. Artificial intelligence platforms are being connected to internal documents, customer records, code repositories and business systems. A flaw anywhere in the chain can turn a helpful interface into a convenient route through the organisation. Giving an agent more tools makes it more capable. It also gives a compromised agent more options, which is a less marketable but rather important property. A separate concern, though one that needs much more evidence before it can be treated as settled. Is the proposition that large language models may never be made fully secure against manipulation. Because the weakness is tied to how they work rather than to a missing layer of protection. If the model's general capability and its vulnerability arise from the same underlying mechanism. Then securing the system may not be a matter of fixing a discrete bug. It may be closer to trying to make a very persuasive improviser obey a rulebook perfectly, while allowing it to reinterpret the rulebook on demand. That is not proof that every deployed model is doomed. It is a design constraint that should be treated as such, rather than as a temporary inconvenience awaiting a larger filter. Safety claims need to specify what is protected, against whom and under which conditions. Anything broader is mostly branding with better punctuation.

Microsoft has entered the cyber-defence conversation with MAI-Cyber-1-Flash, 137 billion total parameters with around 5 billion active per task, running inside its MDASH scanning system. The important framing is that last part: this is a component inside a working security system, not an autonomous analyst. The reported score of 95. 95 per cent on CyberGym belongs to the combined system. A model may be highly effective when given carefully prepared inputs, tools and feedback, and considerably less impressive when asked to work without that scaffolding. A database is not a business, and a power steering system is not a car. The distinction is obvious everywhere except in technology announcements. In security, the deployment architecture is often the product. The model is just the bit that gets the press release.

Moving from the security layer to the physical world, there is a pattern worth tracing across industrial environments. The useful question for artificial intelligence in industrial safety is not which model has the most impressive name. It is where the decision gets made. Put the system on site and it can respond to a hazard in the moment. Put the analysis in the cloud and it can look across sites for patterns that no individual plant would see. In many cases, the sensible answer is both, rather than another round of model-brand theatre. Edge artificial intelligence means the software runs close to the machinery, cameras or sensors producing the information. If the question is whether a person has entered a restricted area, whether a vehicle is approaching too quickly. Or whether a visible condition requires immediate attention, local processing has an obvious advantage. That does not make edge systems magically reliable. They still need suitable sensors, careful installation, maintenance and sensible rules about what counts as a hazard. False alarms are not a minor inconvenience. If the system warns too often, workers learn to ignore it. That is a predictable human response, not a failure of worker discipline. A system that misses hazards creates a dangerous sense of reassurance, which is harder to see in a dashboard because the system remains reassuringly quiet. Artificial intelligence has a particular talent for generating confidence in neat interfaces.

Hong Kong is reviewing how artificial intelligence might improve construction safety, and the policy review places proposed tools alongside existing regulations. The Digital Works Supervision System and rules governing drone use. That matters because an artificial intelligence system does not arrive on a blank sheet of paper. It has to fit into procedures that already allocate duties, define evidence and determine what happens after an incident. Computer vision might identify missing protective equipment or unsafe movement. Drones could survey difficult locations without sending someone into them. None of that is especially mysterious. The hard part is making the output reliable enough to support a decision rather than merely producing another alert for somebody to ignore. There is also the question of evidence. If an artificial intelligence system flags a breach, can the contractor explain why? Is the image clear? Was the model trained for the conditions on that site? Does it work in poor weather, crowded spaces and changing light? These are not administrative details added after the interesting technology has been chosen. They determine whether the technology can be used at all. Regulation is often treated as a brake while technology is cast as the engine. In safety-critical work, that is backwards. Rules provide the boundaries within which automation can be trusted. They also prevent responsibility from dissolving into the familiar phrase: the system did not flag it. Software has never been a very convincing scapegoat, although organisations continue to audition it for the role. The sensible standard is not whether artificial intelligence can watch more of a site than a human can. It plainly can. The standard is whether it improves decisions, reduces exposure to danger and leaves responsibility clearer rather than blurrier.

Back to the web, and a rather different kind of daily environment. Google's artificial intelligence Overviews appeared in 43 per cent of measured US searches, up from 15 per cent a year earlier. That is not a minor interface adjustment. It changes where the answer is delivered, and therefore whether anyone needs to visit the page that produced it. Artificial intelligence Overviews sit within ordinary search results, offering a generated summary alongside familiar links. Artificial intelligence Mode is intended for longer questions and follow-up prompts. This is not Google adding a chatbot to the side of the page. It is putting generated text directly into the main route people already use to find information. Search has traditionally done two jobs at once. It answered questions, but it also directed attention towards the organisations, publications and individuals producing the answers. If Google supplies more of the answer before a visit takes place, those two functions begin to pull apart. The user may get an answer while the publisher loses the opportunity to earn attention, advertising or a return visit. Publishers can continue producing pages that Google uses to assemble summaries, while receiving less direct traffic from the people who consume them. The intermediary captures the question and the answer; the creator is left with the costs of producing reliable material. And fewer of the benefits that once came from being found. There is a less obvious consequence for users. A conventional search page exposes some of the disagreement between sources, simply by placing several results in view. A single summary compresses that disagreement before the user has inspected it. A neat answer can conceal a messy evidence base, which is one of the oldest tricks in information technology. At 43 per cent of measured searches, this is already a question about the structure of the web. The summary is becoming the destination, and the next argument will be over who gets paid when the map replaces the journey.

Turning to research software, coding agents are being used on one of the least glamorous tasks in scientific computing: making existing software run faster. A field report from OpenAI describes eight scientific computing projects where coding agents helped reduce runtimes. Using Codex alone in five cases and combining it with Anthropic's Claude Code in three. An agent can inspect a codebase, identify inefficient sections, suggest changes and help test whether those changes preserve the result while improving performance. That is not the same as asking a chatbot to write software from scratch. Performance work involves finding where time is actually being spent, understanding how data moves through a programme. Choosing a better algorithm and checking that a faster answer is still the right answer. Research teams are often rewarded for producing findings, not for improving the machinery that produces them. A simulation may run tolerably on a developer's machine, then become painfully expensive when scaled across thousands of experiments. A modest reduction in runtime can therefore affect how many tests a team can afford and how quickly it can iterate. But this is OpenAI reporting on projects involving its own tool, not an independent assessment by a neutral evaluator. Eight examples show that a capability exists. They cannot establish how often it works, how much human expertise was required. Or whether the improvements would survive comparison with a competent engineer using conventional tools.

A related but distinct development from Kuaishou's KwaiKAT team makes a more important point. The limiting factor for useful coding agents may be the environment in which they work, not the model itself. A coding agent has to operate inside a repository with the right dependencies, build tools, tests and configuration. If that environment is incomplete or unreliable, the agent can appear to succeed while producing code that would not survive contact with the actual project. The KAT-Coder-V2. 5 work describes a system called AutoBuilder intended to construct these repository environments automatically, with a reported success rate rising from 16. 5 per cent to 57. 2 per cent across more than 100,000 verifiable environments. A sandbox audit also reduced errors in the reinforcement-learning feedback process from roughly 16 per cent to below 2 per cent. If the evaluator is wrong, the model is being trained against a distorted map. It may learn to exploit the test harness rather than solve the problem. The direction is sound. The industry has treated the surrounding software system as plumbing when it is actually the laboratory, the examiner and. In some cases, the only thing stopping an agent from confidently submitting rubbish.

The code-generation conversation also has a more prosaic layer that deserves attention: prompt debt. The quickest way to build an artificial intelligence application may also be the quickest way to create a maintenance problem. Natural-language interfaces let a team describe the behaviour it wants, pass those instructions to a frontier model, and produce a working prototype in an afternoon. That is useful. It is also how a set of casual instructions can quietly become part of the software. A prototype can appear finished when it has merely demonstrated that one path through the system works. The prompt may contain assumptions nobody has documented, depend on a particular model's habits. Or ask for several incompatible things at once and happen to get away with it during a demonstration. Once users and other systems depend on the result, changing the prompt can alter behaviour in ways that are difficult to predict. The debt is not just the effort required to tidy up some wording. It is the burden of understanding what the instructions are meant to achieve, which parts are essential and which failures are acceptable. When instructions are treated as ordinary text, organisations may not give them the same scrutiny as code, configuration or policy. Yet prompts can influence what the system says, refuses, prioritises and passes on. They are a form of control logic, written in a language that is easy to edit and difficult to reason about with precision. The sensible response is to mark the boundary between prototype and product much more clearly. Once a prompt is carrying important behaviour, it needs an owner, a history, basic tests and an agreed account of what failure looks like. English is wonderfully quick to write. It is less impressive as a version-control system.

Anthropic's Custom Skills approach addresses part of this through packaging. The idea is to turn repeated instructions into something reusable. A team keeps asking for the same kind of report, applying the same validation rules, following the same company standards. A Custom Skill bundles the instructions, workflow, templates, examples and reference files needed for a particular task. The important point is that this is not about making the model more intelligent. It is about making the surrounding process less improvised. The gain is consistency. Two people asking for the same piece of work should get outputs shaped by the same expectations. Rather than by whatever wording happened to survive in somebody's prompt. Packaging the process also makes review more practical. Instead of asking only whether a particular answer looks reasonable, a team can examine the Skill itself. What rules does it apply? Which examples does it rely on? When was it last updated? The catch is that a reusable workflow is only as good as the workflow it captures. Automation is perfectly capable of standardising nonsense. It has been one of its more dependable talents. There is also a maintenance question. Company standards change. Code libraries move on. A Skill carefully assembled six months ago may now be quietly imposing yesterday's assumptions on today's work. Reusability creates a duty to maintain, test and retire these bundles, just as organisations maintain software and documentation.

Anthropic has also released Claude Opus 5, and the important detail is where it sits in the range. Opus is the workhorse: the model customers use for paid work where the bill has to be justified by the result. That makes this more consequential than another entry in an increasingly crowded model catalogue. The question is not whether it can produce an impressive answer in a demonstration. Most leading systems can manage that, provided the task is chosen with reasonable care and the awkward examples are kept somewhere off camera. The question is whether it can handle useful work often enough, with enough consistency, to earn its place in a real budget. The available detail does not yet tell us what changed or how reliably it changed. There is no clear account here of whether the gains are in reasoning, coding, long-context work, tool use, speed, cost or some less glamorous combination. Model releases are arriving quickly enough that the product is no longer just a model. It is a moving target wrapped in pricing, access terms, tooling and a sales argument about where it belongs in an organisation. The speed of release creates pressure on buyers to keep reassessing their stack, even when the practical improvement over the previous version is unclear. That is not necessarily progress for the customer. Sometimes it is simply a faster timetable for procurement fatigue.

On the infrastructure side, there are several developments worth grouping together. Liquid artificial intelligence has released two small open-weight language encoders, LFM2. 5-Encoder-230M and LFM2. 5-Encoder-350M, aimed at making useful language processing run locally on ordinary CPUs. Both handle an 8,192-token context. They are encoders rather than chat models, designed to turn text into useful representations for classification, similarity search and retrieval. Much of the public conversation about artificial intelligence still treats a model's ability to produce fluent text as the main event. For many businesses it is not. The more valuable system may be the one that quietly sorts incoming correspondence, identifies duplicate cases or flags a document for human review. Those jobs need consistency, low cost and predictable latency rather more than theatrical eloquence. Local encoders can also reduce the amount of sensitive text leaving a company's network and simplify some compliance decisions. None of that makes privacy automatic. A badly configured local service is still badly configured. The claimed 28-second processing time for a single 8,000-token forward pass on a CPU. Is not fast if you are waiting for an answer at a counter. It is perfectly plausible for batch processing, where documents are queued and worked through without paying for a GPU or an external API call. The practical test is not whether a small encoder can appear near the top of a benchmark table. It is whether it can classify and retrieve the material an organisation actually handles, cheaply enough and quickly enough.

Then there is Bonsai-27B, presented as a model that can run locally, though that description needs an asterisk large enough to compile. It uses a one-bit GGUF format called Q1_0_g128 and requires a specialised fork of llama.cpp, PrismML, with its own CUDA kernels. That is not the same thing as downloading a model and pointing a familiar local runner at it. The model, the quantisation format, the inference engine, the fork and the GPU support all have to line up. A model can be technically compact and operationally awkward. Those are separate properties, and confusing them is how promising experiments become maintenance tasks. Local artificial intelligence becomes useful when it is not just possible but repeatable.

Tencent's AngelSpec open-sources engineering tools for speculative decoding: using a smaller draft model to propose several tokens in advance. Then having a larger model verify them in a batch. If the guesses are good, the system accepts several tokens for roughly the cost of checking one. The headline result from testing with HY3-295B-A21 shows speedups between 1. 98 and 2. 40 times compared with ordinary autoregressive decoding, across concurrency levels from four to sixty-four. That range is more informative than a single heroic number. Open tooling may be the most valuable part of this release. Serving teams can inspect the assumptions, measure acceptance rates and test different verification budgets rather than taking a vendor's benchmark as a matter of faith. Progress in artificial intelligence infrastructure is increasingly about controlling waste: not inventing a more impressive model. But avoiding expensive computation when a cheaper approximation will do.

Moonshot artificial intelligence has released MoonEP, an open-source communications library for training distributed Mixture-of-Experts models. The problem it addresses is moving information between specialised parts of a large model without allowing network traffic to overwhelm the computation. If communication is slow, poorly balanced or badly managed, the theoretical efficiency of the model evaporates. Processors sit waiting for data, the system becomes harder to scale and the cost of adding more hardware rises faster than anyone had hoped. Alongside MoonEP, Moonshot also released AgentENV: an open-source sandbox layer using Firecracker microVMs for isolated agentic reinforcement learning environments. With millisecond snapshot and resume support and the ability to fork an environment into as many as sixteen copies. Training agents tends to involve a great many slightly different attempts. Replaying starting conditions, branching experiments and discarding failed runs are much easier when the environment behaves more like a versioned object than a disposable server. Better test laboratories are valuable. The laboratory is not the scientist, and a faster, safer and more reproducible environment does not automatically produce a more capable agent. It improves the machinery around the experiment. That distinction is worth keeping.

Fireworks artificial intelligence has launched Nexus, a managed routing layer for coding tools that moves routine work between different open-weight models. While giving engineering teams a single place to manage usage and cost. Most software work does not require the most capable system available. A request to rename a variable, generate a test or tidy a configuration. File may not need the same model used for a difficult architectural change. The important word is "reliably". Coding tools carry context: the repository, the previous exchange, the intended conventions, the tests that have already failed. Moving a task between models can affect how that context is interpreted. A response that looks perfectly plausible may still introduce a subtle defect. Savings from using smaller models can also be cancelled by the overhead of another service, by repeated retries. When a cheaper model fails, or by the human time spent checking output that was supposed to be routine. Routing can distribute work; it cannot remove uncertainty from the work itself. Open weights, in other words, do not automatically mean an open system. Convenience arrives dressed as simplification; dependence is usually what gets out of the car.

Kimi CLI from Moonshot takes a different angle on the same territory. The more consequential feature is that it can be configured to run as a non-interactive coding agent. Something you schedule, wrap in a script and ask to carry out repeatable work without a person sitting in front of a chat window. It supports JSONL streaming, built-in testing, session memory and reusable workflows. That changes the shape of the tool. Unattended automation is not made reliable by placing a command in a script. It is reliable only if the surrounding system can establish what success means, limit what the agent is allowed to touch. Provide the right credentials and recover when the agent takes a wrong turn. If the tests are weak or easy to satisfy accidentally, the system can become very efficient at confirming its own mistakes. The useful unit is not the agent. It is the complete job around the agent: permissions, tests, logs and a sensible way to say no.

Perplexity's `pplx` command-line tool addresses a related plumbing problem. It provides one verified binary, two commands and exactly one JSON object written to standard output. An agent does not need to operate a browser, interpret a page layout or scrape a command's mixed output. It can call the tool, receive structured JSON and continue with the task. The phrase "exactly one JSON object on stdout" is doing more work than it may appear. Command-line tools often emit a mixture of useful output, progress messages and decorative noise. A stable machine-readable contract makes the tool easier to compose, test and supervise. The checksum does not make search results true. It provides a way to establish that the executable being run is the one that was published. Basic software hygiene has acquired a faintly exotic quality in parts of the artificial intelligence industry, so it is worth noting when something demonstrates it.

Google has put Lyria 3. 5 into Flow Music with claims of better musicality, lyrics, vocal quality and creative control. That is a sensible list of things to improve. It is also, at present, a list of intentions rather than evidence. The announcement provides no examples, evaluation results or clear measure of improvement. The useful question is not whether the new model sounds impressive in a short demonstration. Most modern music-generation systems can manage that, at least briefly. The important question is whether a musician can ask for a change, get a predictable result and keep the parts that already work. Change the vocal phrasing while preserving the arrangement. Alter the second verse without losing the chorus. Those are ordinary requirements in a studio and rather less ordinary for a generative model. Polished output is not the same as useful output. If each revision produces a new collection of compromises, the creator is not directing the system so much as negotiating with it. The test for Lyria 3. 5 is quite plain: not whether it can make a track worth hearing once, but whether it can help make the track someone actually meant.

1X has brought the artificial intelligence argument into the kitchen, suggesting their robots may soon be better than people at making dinner. A kitchen is not a laboratory with carefully placed objects and a known sequence of actions. Ingredients arrive in different shapes and conditions. Drawers stick. A chopping board moves. The thing you need is invariably behind the thing you have just put down. When a company says a robot is becoming better than a person at making dinner, the important question is what "better" means. Faster, perhaps. More consistent. Or simply capable of repeating a narrow recipe under controlled conditions. Those are very different achievements. A robot may be able to grip, lift and manipulate an object while still lacking the judgement needed to decide what to do next. Human cooks constantly adjust without making a fuss about it. The ability to recover from small failures is not glamorous, but it is most of the job. A household robot cannot treat the home as a controlled environment. It has to work around children, pets, visitors. And the general disorder produced by human beings who have not agreed to become part of a robotics trial. Artificial intelligence companies have spent years persuading us that progress can be measured in benchmarks, leaderboards and impressive conversations. Physical robots are a more honest test because the world pushes back. The object is either picked up or it is not. The food is either prepared safely or it ends up on the floor. The useful evidence will be repeated performance across ordinary kitchens with ordinary clutter and no heroic supervision. Until then, "better than people at making dinner" is an ambition. The sauce, as ever, is in the details.

Black Forest Labs has released FLUX 3, handling images, video, audio and robot actions from one set of weights. The interesting part is not the list of modalities. Which is now becoming a fairly standard way to make a launch sound larger than it may be. It is the attempt to put perception, generation and physical control under one roof. Fewer components can mean fewer points of integration. But one model does not automatically mean one coherent intelligence. Sharing weights may reduce duplication, or it may create a model that is broadly competent and specifically untrustworthy. The cost of a poor image is usually aesthetic disappointment. The cost of a poor physical action can be a damaged object or an interrupted process. Consolidation is not the same thing as control, despite what architecture diagrams tend to imply.

Photon-1 makes a stronger architectural claim: that a model can learn the relationship between what it sees. And what happens next without being given action labels, then apply that understanding across desktops, checkers and billiards from a single pretraining run. The system is said to receive raw video and infer the hidden causes of change for itself. The desktop setting is particularly revealing. To control it, a model must connect visual changes to actions, maintain state over time and cope when the expected response does not arrive. Prediction is not the same as control. A system can be very good at describing what normally happens and still fail when it must choose an action that produces a particular outcome. The old temptation in artificial intelligence is to treat a convincing simulation as evidence of general intelligence. A convincing simulation is evidence that the simulation was learned convincingly. Useful control begins only when the model has to do something under uncertainty and bear the cost of being wrong.

In healthcare, Guardoc Health says it is processing more than one million clinical documents a day using Amazon Nova models. The important point is not that a language model has been persuaded to write something that resembles a medical note. That trick has been available for some time. The point is volume: using a general-purpose model to deal with the administrative mass surrounding patient care. In clinical documentation, a plausible mistake is often worse than an obvious one. A missing detail, an incorrect classification or a confident summary that quietly changes the meaning of the original. Record can affect whether a claim is paid correctly and create exposure to audits, fines and litigation. The model does not need to invent a dramatic medical fact to cause trouble. It merely needs to make an ordinary record slightly too tidy. Processing a million documents does not tell us how many were correct. How many required human intervention or how errors were detected before they reached a payer or a patient record. Those are not minor implementation details. They are the product. Artificial intelligence is moving into the back offices of regulated industries not because the models have become dependable in every respect. But because the paperwork is expensive and repetitive enough to make partial automation worthwhile. That is a sensible place to look. It is also where the consequences of small errors are easiest to bury under a large processing count.

A separate note on bone tissue labelling deserves a moment, because it illustrates a problem that appears across many technical domains. The distinction between what can be seen at the scale of the whole bone. And what belongs to its microscopic organisation may sound like a taxonomic detail. In practice, it is where errors begin in clinical interpretation, teaching material and datasets intended for machine learning. The diagram may still look tidy. Tidy diagrams, like tidy spreadsheets, are quite capable of concealing nonsense. Before asking whether an annotation system is accurate, establish what level of structure it is meant to represent. A label cannot be reliable if the category itself is drifting between gross anatomy, microscopic organisation and image appearance.

AlphaFold's great strength is also its awkward limitation: it produces a plausible three-dimensional structure for a protein. But proteins are not always committed to one tidy shape. Researchers at ISTA are testing whether experimental data can push the model towards messier, more honest answers. Rather than asking AlphaFold to select one dominant structure, they want to provide evidence that captures the range of forms a protein may occupy. A prediction that presents one structure with unwarranted confidence can be misleading even when that structure is broadly plausible. Because a protein's shape determines how it interacts with other molecules and how it responds to changes in its surroundings. The work points to a broader change in how these systems may be used: not as a replacement for experimentation. But as part of a loop between computation and measurement. The important shift is from asking whether AlphaFold has found the structure to asking what evidence supports each structure. And under which conditions it exists. That is a less dramatic question but a much more useful one.

Insilico Medicine reports reducing some drug-development programmes in China to roughly a year, with its fastest programme reaching candidate nomination in nine months. That is useful progress but not quite the claim that artificial intelligence has solved drug discovery. Candidate nomination is the point at which a company selects a molecule for further development. Quite a lot can still go wrong afterwards, usually at considerably greater expense. The fastest programme is also not necessarily representative of the whole portfolio. Timelines depend on the disease area, the target, the quality of available data and the chemistry involved. Speed is useful when it improves judgement. Speed without better judgement merely produces a larger queue of expensive molecules. Artificial intelligence in drug discovery faces a structural constraint that goes deeper than model capability. Since the 1950s, the cost of developing new medicines has roughly doubled every nine years. Bringing one to market takes an average of ten to fifteen years. An early decision that looks efficient can become very expensive if the evidence behind it was weak. Poorly recorded or impossible to compare with later results. Useful information has to remain connected across the whole process: from initial research through laboratory work, clinical testing. And eventual decisions about what succeeds or fails. If those stages produce records that do not fit together, the learning loop breaks. The organisation may have plenty of data while still lacking a dependable account of what worked, what failed and why.

On the question of artificial intelligence systems in education, the most useful point is also the most uncomfortable one. A student can describe a problem to an artificial intelligence system and receive a plausible solution, often with comments and neat formatting included. A finished program can demonstrate competence, assistance or simple possession of a working answer. Those are not the same thing, though they are increasingly difficult to distinguish from the file alone. The problem is not merely that students might cheat. The more awkward issue is that the assessment itself may no longer measure what teachers think it measures. Education has been quietly using submitted work as both product and proof. Once software can produce a substantial portion of the code, that shortcut becomes unsafe. The sensible response is not to pretend artificial intelligence can be kept outside the classroom by a sufficiently stern declaration. It is to assess the process: can the student explain the design choices, alter the code when requirements change. Test it against unfamiliar cases, diagnose a deliberately introduced error? The finished program is not worthless. It is simply no longer enough.

Meta's argument about superintelligence and personal artificial intelligence deserves attention precisely because it is an argument about distribution rather than a product announcement. Mark Zuckerberg's Wall Street Journal piece offered no named model, release date or benchmark figures. What it offered was a view: advanced artificial intelligence should be placed in. The hands of individuals rather than controlled by a small number of institutions. That is a respectable position. It is also an argument without much machinery attached to it. Personal artificial intelligence sounds straightforward until you ask what "personal" actually means. Does the model run locally, with the user retaining control of the data? Does it operate through Meta's servers, where the company provides the model and decides the boundaries? A service may be designed for one person while remaining owned, hosted and governed by a large platform. The user gets the interface; the institution keeps the infrastructure, the telemetry and potentially the ability to change the rules. The language of individual empowerment can obscure that arrangement. Meta is right that keeping advanced artificial intelligence within a few governments or laboratories would create its own risks. The answer, however, is not simply to move that power into personal assistants and assume the problem has dissolved. It may instead produce a new layer of private infrastructure, controlled by a handful of companies while presented as individual freedom. Until Meta supplies clearer answers about data, portability, transparency and affordability, this is philosophy rather than evidence. A promise that superintelligence will belong to individuals is not the same as giving individuals control. The difference will be found in the architecture, the terms and the exit button.

Armenia's position illustrates the same tension at a national level. A small country is unlikely to manufacture leading processors, train the largest models or compete directly with firms spending billions on data centres. The practical question is whether it can secure reliable access to computing, software. And technical infrastructure without being entirely at the mercy of decisions made elsewhere. Sovereignty in this setting is a matter of leverage rather than autarky. The word can do too much work: it may describe genuine resilience. Or it may give a more dignified name to continued reliance on foreign cloud platforms and model providers. A flag placed on a rented server is still, in the end, a rented server. The sensible objective may not be to imitate the largest technology powers but to identify where control genuinely matters. Concentrate resources there, and remain realistic about what must still be imported.

The artificial intelligence investment boom is making that question urgent for more countries than Armenia. Microsoft, Meta, Amazon and Alphabet are committing hundreds of billions of dollars to artificial intelligence infrastructure. NVIDIA sits at the centre of that spending because its advanced chips are in such demand. The investment is accumulating around a very small group of firms, which gives them influence over the direction, price and availability of artificial intelligence itself. Infrastructure spending of this scale is not reversible in the same way as a software experiment. A company can cancel an application. It cannot so neatly unwind a network of data centres and long-term hardware commitments. If expectations about artificial intelligence revenue fall short, the financial consequences will not be confined to a handful of product teams. The role of NVIDIA is especially revealing. Control over a crucial bottleneck can be enough to concentrate value, even without dominating every other part of the system. When one supplier becomes central to the expansion plans of several enormous customers, its position tells us something about where bargaining power lives. The model may be presented as the clever bit. The chip is often where the money is. The competitive advantage at the application layer may remain open and contested, while the expensive and difficult layer underneath becomes more concentrated. That is a familiar technology pattern, and it has arrived before the artificial intelligence market has fully decided what it is trying to build.

Singapore government and public-sector teams are using artificial intelligence-assisted media analysis to track public sentiment. The practical test is not whether officials are using artificial intelligence. It is what they do with the output. An artificial intelligence system can classify language at scale without understanding public opinion. Media coverage is not a referendum, and the loudest discussion is not necessarily the most representative. A system that turns a messy information environment into a neat score may be useful for triage. But it can also create a false sense of precision. More importantly, sentiment analysis sits close to the boundary between listening and managing. Used carefully, it can give public bodies a broader and faster view of the conversation around their work. Used lazily, it can encourage officials to treat citizens as signals to be measured rather than people whose objections need to be understood. The real measure will be whether officials become better at listening, rather than merely more efficient at counting.

The useful idea behind artificial intelligence in bioacoustics is similar in structure: background noise treated as a measurement system. Birds, insects, small mammals and bats produce signals all the time, and software can help sort those signals into evidence about which species are present. Acoustic sensors can be left in place for days or weeks, recording through hours when people are not there and many animals are most active. The artificial intelligence identifies patterns in those recordings. That gives conservationists a cheaper and less intrusive way to monitor habitats. And the possibility of building a longer record of how a place changes over time. But there is a large gap between detecting sound and understanding a population. An animal may be present without calling, or may call more or less often for reasons unrelated to population size. A model can become very good at matching recordings from the conditions in which it was trained. Then perform badly somewhere with different species or different acoustic character. If the output is used to decide where to protect land or assess whether a project has caused damage. An error in interpretation becomes an error in policy. Automation is useful here because it extends human attention, not because it removes the need for ecological judgement.

The coordination problem underlying many of these applications is worth naming plainly. A system assessing symptoms, another arranging appointments, a third dealing with insurance and a fourth handling pharmacy information may each perform its own task competently. They can exchange data and pass messages. But coordination means more than forwarding information. It means agreeing what should happen next, recognising when one decision affects another, resolving conflicting objectives and knowing when a human needs to intervene. Each specialised system may be optimised for its own target: speed, cost, accuracy, completed bookings, reduced claims or successful dispensing. Those targets can conflict. Coordination therefore requires more than a common data format. It requires a shared objective, or at least a clear method for negotiating between competing ones. That is where grand claims about artificial superintelligence become less useful. The practical path described in much of the current work looks more like a workplace: several specialists. Incomplete information, competing priorities and an escalating need for someone to check the paperwork. The difference is that the specialists may act at machine speed, and mistakes can travel just as quickly.

The sensible test for each of these systems is not how capable the model sounds in a demonstration. It is whether the surrounding architecture can explain what happened, prevent an unsafe route and recover cleanly when something goes wrong. That test applies whether the system is governing an artificial intelligence agent's permissions, training a coding agent in a sandboxed environment. Routing tasks between models, or classifying clinical documents at scale. The model is often the most visible component. It is rarely the only one that matters, and in several of these cases it is not even the most important one to get right. The broader pattern in all of this is that artificial intelligence progress has become less about a single clever model. And more about removing friction from the machinery around it, while simultaneously creating new places for that machinery to fail. Better tools, better infrastructure, better environments for training and testing: all of these are real and useful. None of them automatically produces a trustworthy system. Trustworthiness still has to be designed, tested and maintained by people who understand. Both what the system can do and what it is allowed to do. The clever part is getting attention. The important part is keeping the keys, and knowing at every stage of the lifecycle exactly who holds them.

It has been a fairly intense week in artificial intelligence, with the usual mixture of genuine progress, confident claims and a few demonstrations doing rather more work than the evidence. The useful discipline is to separate what has actually changed from what has merely been announced, because clarity remains the cheapest form of technical due diligence. If you want that discipline in your inbox, you can get the daily AI briefing at jonathan-harris dot online. One email, plainly written, with the useful bits and rather less ceremonial trumpet-blowing. This week's sponsor is my own book, The House Always Knows: AI, Gambling, and the Ethics of Personalized Gaming. It examines what happens when systems become very good at predicting behaviour, and when prediction starts quietly shaping it. You'll find it in the eBooks section there. And that is enough moral unease for one sitting. Thank you for listening, and for resisting the understandable temptation to treat every polished demo as a revolution. Most of them are still just software, which is both less glamorous and rather more important. We'll be back next week with another look at what the industry says it is doing, what it is actually doing, and where those two accounts continue to diverge. That's your lot for this week's Turing's Torch. If you want the daily brief, head to jonathan-harris dot online. Same time next week — try not to believe the press releases.