Tag: Enterprise AI

  • Agentic AI Is About to Leave the Screen

    Agentic AI Is About to Leave the Screen

    Why robotics may become the next operating layer for AI, and what changes when the physical world becomes programmable.

    Andreas's view

    My read: robotics is still being framed as hardware, when the more important shift is that AI is becoming an operating layer for physical work.

    The market tends to split into two shallow stories. One treats robots as factory equipment. The other treats humanoids as spectacle: impressive demos, big forecasts, uncertain timelines.

    I don't think either framing is enough. The more interesting story is that agentic AI gives robotics a new operating layer. Robots are not only getting better bodies. They are starting to get better ways to interpret context, plan actions and coordinate with digital systems.

    That changes the question. It is no longer only: what can AI answer? It becomes: what can AI do when it can perceive, decide and move?

    For leaders, the implication is practical: start mapping where physical work could become programmable. The strategic question is not "Should we buy robots?" It is where sensing, decision-making, workflow automation and safe machine execution could change cost, throughput, resilience or customer outcomes.

    From chatbot to operator

    The first wave of generative AI lived in a text box. It wrote, summarized, translated, coded and made knowledge work faster.

    The second wave is more ambitious. Agentic AI plans, checks, books, routes, escalates and triggers workflows. It turns AI from an interface into an operator.

    Robotics is where the operator model starts to touch the real world.

    If chatbots made AI visible, and agents make AI operational, robotics makes AI physical.

    This is a much bigger jump than the interface suggests. A chatbot operates in language. A software agent operates in digital systems. A robot operates in environments where physics, safety, maintenance, regulation and human trust all matter at the same time.

    That is why I would not start this discussion with humanoids. Humanoids are one form factor. The bigger story is physical AI: models, sensors, actuators, chips, batteries, simulation, edge computing, fleet software and enterprise workflows coming together.

    Robotics is not one market

    Robotics market stack showing industrial, service, medical, defense, consumer, and humanoid robot segments
    Robotics is not one market. It is a connected stack of industrial, service, medical, defense, consumer, and general-purpose systems.

    Robotics is already a real market, and it is much broader than the humanoid headlines.

    Industrial robots remain the established core: welding, assembly, painting, material handling, electronics, automotive and semiconductor manufacturing. Professional service robots cover logistics, warehouse automation, inspection, cleaning, hospitality, agriculture, construction and security. Medical and care robots include surgical systems, rehabilitation devices and hospital logistics.

    Defense and security robotics adds unmanned aerial, ground, surface and underwater systems, counter-drone capabilities, explosive ordnance disposal, reconnaissance, logistics and infrastructure protection. Consumer robots cover domestic devices such as vacuums and lawn robots. Humanoid and general-purpose robots sit on top of this stack as an early-stage category for environments built around human bodies.

    The data matters because it grounds the story. The International Federation of Robotics reported 542,000 industrial robot installations in 2024 and a global operational stock of 4.664 million units. Asia accounted for 74% of new deployments. China alone represented 54%.

    Service robotics is smaller and more fragmented, but it is moving. IFR's World Robotics 2025 service robot summary reported that worldwide sales of professional service robots grew 9% in 2024 to more than 199,000 units. Medical robots grew 91% to nearly 16,700 units.

    Market forecasts point in the same direction, even if the exact numbers should be treated carefully. Goldman Sachs sees the humanoid robot market reaching $38 billion by 2035. Morgan Stanley outlines a much larger long-term scenario: a potential $5 trillion humanoid market by 2050, including supply chains, repair, maintenance and support.

    Defense is one of the clearest signals that robotics is becoming a strategic technology segment, not only an automation category. Fortune Business Insights estimates the military robots market at $19.82 billion in 2025 and projects it to reach $42.90 billion by 2034. The exact number matters less than the direction: militaries are shifting from isolated unmanned platforms toward fleets, autonomy, sensing, secure communications and human-machine teaming.

    The point is not to believe every forecast. The point is that robotics is starting to look less like a hardware niche and more like a debate about who controls the operating layer of physical work.

    Why the cycle feels different now

    Robotics has had false dawns before. What makes this cycle worth watching is that several constraints are shifting at once.

    AI models are becoming more useful for perception, planning and adaptation. Google DeepMind describes Gemini Robotics as bringing AI agents into the physical world; Google's later Gemini Robotics-ER 1.6 work focuses on spatial logic, multi-view understanding, task planning and success detection.

    Simulation is improving too. Robots need data, but the physical world is expensive and slow. Synthetic environments, world models and simulation frameworks can compress training cycles. That is why NVIDIA's physical AI announcement matters: Jensen Huang called this a "ChatGPT moment for robotics" and framed physical AI as models that understand the real world, reason and plan actions.

    Enterprise demand is also clearer than before. Labor scarcity, warehouse complexity, aging populations, healthcare capacity, nearshoring and infrastructure build-out all create demand for automation that can work beyond perfectly structured factory cells.

    The market is not waiting for household humanoids. It is starting with work.

    It is also starting with security. The U.S. Department of Defense's Replicator initiative is built around all-domain attritable autonomous systems: lower-cost systems that can be fielded, updated and replaced faster than traditional platforms. NATO's DIANA Rapid Adoption Service recently awarded an R&D contract for undersea robotics and describes its role as helping Allies "move faster from identified capability need to real-world solutions." That is the defense version of the same physical AI thesis.

    Operator overseeing autonomous drone, ground, and undersea robotics systems for defense and security missions
    Defense robotics is shifting from isolated platforms toward autonomous fleets, sensing, secure communications, and human-machine teaming.

    Humanoids are the headline, not the whole story

    Humanoids matter because the world is built for people. Door handles, stairs, shelves, tools, kitchens, hospital rooms and factory aisles assume a human body.

    If robots can operate in those environments, the cost of automation changes. Companies may not need to redesign every workflow around a fixed machine. The machine could adapt to the workflow.

    That is the promise. It is also where the hype gets dangerous.

    Most useful robotics deployments will start where the economics are precise: structured tasks, high labor scarcity, safety risk, repetitive physical work, expensive downtime or environments where human work is hard to scale.

    Amazon is a useful case because it shows the less cinematic version of the future. The company says it has deployed its one millionth robot and introduced DeepFleet, a generative AI foundation model designed to coordinate robot movement across fulfillment centers. The stated goal is a 10% improvement in robot fleet travel efficiency.

    That is how physical AI will often arrive: not as a robot that looks like a person, but as a system-level improvement in throughput, cost, safety or resilience.

    The recent signal: capital is moving toward physical AI

    The last few weeks made the theme harder to dismiss.

    Germany's NEURA Robotics announced a Series C round of up to $1.4 billion in June 2026, backed by investors including NVIDIA, Amazon, Qualcomm, Bosch, Schaeffler, the European Investment Bank and Tether. NEURA founder David Reger put the strategic point plainly: "The future of AI will not only live on screens."

    OpenAI is also leaning into the theme. Sam Altman's 2026 roadmap says 2027 may bring robots that can do tasks in the real world. Separate reporting on OpenAI Robotics hiring is best read as a secondary signal, not the core proof point.

    This is more than a robotics startup cycle. It is a convergence of AI labs, cloud-scale compute, semiconductor platforms, industrial companies and capital markets.

    That matters for Europe. If physical AI becomes an industrial operating layer, Europe is not limited to being a regulator of someone else's platform. Its manufacturing base, robotics suppliers, automotive sector, industrial software, safety know-how and Mittelstand process expertise could become part of the stack, provided capital, compute, talent and adoption speed match the ambition.

    The operating model question

    The real question is not whether to buy robots. That is too narrow.

    The better question is: which parts of the operating model become programmable when AI can act in both digital and physical environments?

    In logistics, software agents may forecast demand, rebalance inventory and dispatch autonomous mobile robots. In healthcare, AI may coordinate patient logistics while robots move supplies or support clinical workflows. In manufacturing, physical AI may help factories adapt faster to product variation, quality issues or labor constraints.

    In defense, the question is even sharper. Autonomous systems can extend sensing, logistics, surveillance, electronic warfare and force protection into environments where human presence is dangerous or too slow. This does not remove the need for human judgment. It raises the standard for command, control, accountability, cyber resilience and rules of engagement.

    The value is not the robot in isolation. The value is the loop: sense the environment, interpret the situation, decide what should happen next, act safely, learn from the outcome.

    That loop is what makes robotics strategically interesting.

    It also makes it risky.

    Governance moves into the physical world

    Executives reviewing governance controls for supervised robotics and physical AI in an automated operations environment
    Physical AI will require governance models that cover permissions, audit trails, human override, safety, and accountable operations.

    Enterprises are still learning how to govern text-generating AI. Physical AI raises the bar.

    A weak chatbot answer can mislead a user. A poorly governed software agent can execute the wrong digital workflow. A poorly governed robot can damage equipment, block a line or create a safety incident in a regulated environment.

    That means physical AI needs a governance model before it scales.

    Who owns the robot's actions? What permissions does it have? What tasks require human approval? How are decisions logged? How is an incident reconstructed? Who updates the model? Who certifies safety after the model changes?

    These are not IT questions only. They are operating model questions.

    My expectation is that the companies that do this well will not describe the work as a robot deployment. They will describe it as a redesign of work: human judgment where ambiguity is high, machine execution where repetition and safety allow, and clear escalation when the system reaches its boundary.

    What I'm watching

    Four things will tell me whether this thesis is right.

    First, whether robotics deployments move from isolated machines to fleet-level operating systems.

    Second, whether AI labs and industrial companies build repeatable safety and governance patterns, not only better demos.

    Third, whether customers buy measurable outcomes rather than robots: lower downtime, faster fulfillment, safer operations, more resilient logistics or higher asset utilization.

    Fourth, whether the market starts valuing robotics companies as platform ecosystems rather than hardware manufacturers.

    AI is moving from language to action. From action to coordination. From coordination to physical work.

    The first wave lived on screens. The next one will increasingly show up in the world those screens were designed to manage. Physical AI is not just a device transition. It is an operating model transition.

    Sources and further reading

  • Model Dependency Is the New AI Business Continuity Risk

    Model Dependency Is the New AI Business Continuity Risk

    Claude Fable 5, model dependency risk, and why AI sovereignty is no longer only about where data lives.

    Andreas's view

    I would have liked more time with Claude Fable 5.

    Not because a new benchmark table matters by itself. It does not. But because frontier models are now becoming operating infrastructure. When access disappears, the issue is no longer product disappointment. It is continuity risk.

    The early description sounded like a model that pushed several practical boundaries at once: longer autonomous work, stronger coding, better vision, better long-context memory, more capable scientific reasoning. That is exactly the kind of model you want to test yourself. Not in a demo. In messy work. In a real harness. In the kind of workflow where you can feel whether the model changes what is possible.

    Unfortunately, that window closed almost immediately.

    Anthropic announced Claude Fable 5 and Claude Mythos 5 on June 9, 2026. The launch framed Fable 5 as a generally available Mythos-class model with safeguards, and Mythos 5 as the same underlying model with some safeguards lifted for trusted cyber and biology use cases.

    Three days later, Anthropic added an update: access to Fable 5 and Mythos 5 was unavailable.

    The follow-up statement is the more important business story. Anthropic said the US government had issued an export-control directive requiring it to suspend all access to Fable 5 and Mythos 5 by any foreign national, whether inside or outside the United States. To comply, Anthropic said it had to abruptly disable both models for all customers. Other Anthropic models were not affected.

    Based on Anthropic's public account, the directive was triggered by national-security concerns around model misuse; as of this writing, the government's full rationale has not been publicly detailed.

    This is where the story stops being about one model release.

    It becomes a preview of a much larger question: what happens when an enterprise builds critical workflows around a model that can disappear, degrade, fall back, become restricted, change policy, or become unavailable for reasons outside the enterprise's control?

    The model is becoming part of the process

    Enterprise workflows converging into a central AI model dependency
    As AI moves into real workflows, the model becomes part of the operating process rather than a standalone tool.

    Most companies still talk about AI models as if they were tools. You pick one, connect it to a use case, monitor cost and quality, and move on.

    That framing is becoming too simple.

    In real deployments, the model is increasingly part of the operating process. It sits inside support flows, developer environments, research workflows, compliance review, sales operations, procurement analysis, risk triage, security workflows, and internal knowledge systems.

    The more capable the model, the more tempting it becomes to build around its specific behavior.

    That is where the dependency starts.

    A company does not only depend on the model name. It depends on latency, context length, tool use, refusal behavior, reasoning style, pricing, data-retention policy, regional availability, safety fallbacks, API contracts, rate limits, and the model's ability to work inside a specific harness.

    The harness matters. A workflow may depend on prompt structure, tool calls, memory files, evaluation thresholds, orchestration logic, fallback assumptions, and human review steps. If the underlying model changes, the process can change with it.

    Sometimes that is manageable. Sometimes it breaks the economics. Sometimes it changes the risk profile. Sometimes it simply means the workflow no longer works.

    Fable 5 is a case study in availability risk

    The Fable 5 launch itself was ambitious. Anthropic described strong performance in software engineering, knowledge work, vision, scientific research, long-context memory, and life sciences. It also described safeguards that would route some sensitive requests to Claude Opus 4.8 instead of allowing Fable 5 to answer directly.

    That already shows the new shape of frontier AI products. The "model" is no longer a single stable object. It is a capability layer plus policy logic, classifiers, routing, monitoring, data-retention rules, trusted-access programs, and usage conditions.

    Then came the suspension.

    Anthropic said the government directive was based on national-security authorities and that it had to remove access for all users. It also said it disagreed with the action and believed that applying this standard across the industry could halt new frontier model deployments.

    Whether Anthropic or the government is right is not the central issue for enterprise leaders.

    The customer was not in control. Even a short-lived availability window is enough to expose the broader risk: pilots, evaluations, procurement decisions, and roadmap assumptions can all form around capabilities that may not remain available.

    The sharper lesson is that access to frontier capability has become a business continuity variable.

    The hidden risk: model concentration

    Model concentration is becoming a real operational risk.

    The risk is not that one provider has an outage. Enterprises already understand cloud outages. The risk is that AI capability is becoming more specific and less interchangeable.

    If two models both answer emails, switching is easy.

    If one model can run a long-horizon code migration, interpret screenshots, manage tool calls, maintain working memory, and reason through edge cases in a particular way, switching becomes harder. The replacement may be available, but the workflow may need to be redesigned.

    That is a different kind of lock-in.

    It is not only commercial lock-in. It is cognitive and procedural lock-in. Over time, the organization's workflows, prompts, review habits, and escalation paths start to conform to the model's strengths and weaknesses.

    This will matter most in high-value use cases: engineering modernization, cyber defense, regulated research, legal work, finance analysis, industrial design, life sciences, and autonomous operations.

    The more strategic the use case, the less acceptable it is to rely on a single model path with no tested fallback.

    What enterprise architecture needs to change

    AI continuity architecture with a primary model unavailable and fallback paths active
    A model continuity plan needs tested fallback paths, evaluations and escalation logic, not just a procurement preference.

    The practical answer is not to avoid frontier models. That would be the wrong lesson.

    The answer is to treat model dependency as architecture, not procurement.

    Companies need a model continuity plan.

    For every important AI workflow, leaders should know which assumptions are model-specific. What breaks if the model is removed? What happens if it falls back to a weaker model? What if data-retention rules change? What if the API remains available in the US but not in Europe? What if a safety classifier suddenly routes part of the work elsewhere?

    This is not theoretical governance paperwork. It is operational design.

    The risks are different, and they need to be named differently. An outage is not the same as a policy withdrawal. A safety-routing change is not the same as capability degradation. A regional access restriction is not the same as a pricing change. But all of them can alter a workflow that the business has started to rely on.

    The better pattern is a portfolio:

    • a primary frontier model for maximum capability
    • a tested fallback model for continuity
    • evaluations that measure task quality across model options
    • abstraction layers that keep prompts, tools, memory and workflow logic portable where possible
    • logs that show when fallbacks happen and why
    • contracts that address availability, regional access, data policy and notice periods
    • human escalation when model behavior changes materially

    The important word is tested. A fallback that has never been used under realistic workload is not a fallback. It is a slide in an architecture deck.

    The board-level questions are practical:

    • Which AI workflows would stop if the primary model disappeared?
    • Which fallbacks have been tested under real workload?
    • Which model-specific assumptions are embedded in prompts, tools, policies and contracts?
    • Who owns model continuity: procurement, architecture, risk or the business unit?

    Why this becomes a sovereignty issue

    European enterprise connected to AI capability nodes with one external path interrupted
    AI sovereignty increasingly means asking who can interrupt a capability, not only where data is stored.

    For Europe, this is where the story becomes uncomfortable.

    AI sovereignty is often discussed as data residency, cloud location, compliance, or whether a model is hosted in Europe. Those questions matter. But they are no longer enough.

    The Fable 5 episode shows another layer: model availability can be shaped by decisions outside the customer's jurisdiction.

    A European company may comply with European law, host data in Europe, and still depend on an AI capability that can be changed or removed because of a US policy decision, provider safety decision, capacity constraint, licensing change, or export-control interpretation.

    That does not mean every company needs to train its own frontier model. That would be unrealistic for most. It is also not an argument for isolationism or for purely national AI stacks.

    It does mean Europe needs to think about sovereignty at the level of operating capability.

    Can critical public-sector, industrial, defense, healthcare, financial and infrastructure workflows continue if a non-European model is restricted? Are there European or allied alternatives? Are there open-weight or locally deployable fallbacks for lower-risk parts of the workflow? Are procurement teams asking for exit paths? Are regulators looking at operational resilience, not only privacy?

    The sovereignty question is shifting from "Where is the data?" to "Who can interrupt the capability?"

    That is a much harder question.

    The strategic lesson

    I still would have liked to play with Fable 5.

    That is partly curiosity. Frontier models are easiest to understand when you test them against real work. You learn more from one serious workflow than from a benchmark chart.

    But the more important lesson is the one created by not being able to use it.

    The future of enterprise AI will not be decided only by who has the strongest model. It will also be decided by who can build resilient operating models around unstable capability layers.

    Models will improve. Policies will change. Access rules will shift. Providers will make safety decisions. Governments will intervene. Capacity will be constrained. Prices will move.

    For CIOs, CTOs and risk leaders, the question is no longer whether to use frontier models. It is whether every critical AI workflow has a tested continuity path.

    The companies that win will not be the ones that pretend this volatility does not exist. They will be the ones that treat model volatility as a design constraint from the beginning.

    Sources and further reading