Archive 30.09.2026

Reflecting on my time judging the recent HP Future of Work Accelerator Pitch Fest in New York, something kept gnawing at me. As I sat alongside my fellow judges—Antara Lahiri, Catherina Gioino, and HP’s Michele Malejki—we watched five remarkable organizations […]

The post Building the Ultimate AI-Defiant Workforce: The Future of Work Mega-Platform appeared first on Techspective: A Unique Perspective on Technology.

Your team has demonstrated that the AI prototype works. The agent handles the examples well, and the people watching can see where it belongs in the business. Yet months later, you’re showing the same demo to the same stakeholders, explaining the same caveats while the pre-production requirements list keeps growing.

You’re proud of what the team built and tired of explaining why nobody can use it yet. Now the CFO wants to know why something approved 12 to 18 months ago is still in testing. You can point to completed work at every review. What the team hasn’t produced is an owner.

The decision to build was sound

You had the engineering talent to build around your own business requirements. Owning the architecture gave you control over how the agent worked and the freedom to change individual components without committing the whole operation to a vendor’s pricing model. Open-source tools and public APIs also let you test the idea with a manageable initial investment.

Your team assembled the models, vector databases, and orchestration frameworks into something that performs a useful task. Consider a customer-support agent for billing disputes. In the pilot, it reads past tickets, checks the relevant policy, and drafts a resolution a support manager would approve. That’s evidence the approach works, and it gives you a reason to keep investing in it.

The prototype proved the team can build the capability. Running it inside a live business process raises questions the build never had to settle, starting with who owns it.

Three gaps the pilot kept hidden

The assembled stack is well suited to proving a concept. It is less suited to revealing what production requires. The pilot didn’t fail. It just wasn’t designed to surface what comes next. For the billing-dispute agent, moving from drafting a resolution to issuing a credit exposes three gaps: governance and compliance, operational ownership, and integration debt.

Governance and compliance

Your assembled stack didn’t need a governance layer to prove the concept. That’s part of why it moved fast. But once that billing-dispute agent needs to issue a real credit, that same absence becomes the problem. Finance needs a record of each credit, the reason for it, and who authorized it. Legal wants to know how customer data is handled. Before security signs off, someone has to decide whose permissions the agent uses and where a person must approve the action.

Each answer changes the workflow. A credit limit has to be enforced at the point money moves, and the record has to connect each action to its authorization. Adding those controls late means reopening steps that looked finished. If the agent never recorded why it issued a credit, the account balance won’t tell you. This is where the requirements list begins to grow, even while the agent keeps passing its original tests.

Operational ownership

Building the agent and owning it in production looked like the same job. During the pilot, they were: the builders ran the agent and decided how to fix it. That works when nothing real is at stake. 

It stops working when the agent needs to issue a real credit, because engineering cannot grant itself permission to move customer money. Finance owns that decision. Security owns the access that makes it possible. Support owns the customer outcome when something goes wrong.

Each of those teams can add a condition to the requirements list. That doesn’t mean any particular stakeholder was assigned to close it. The builders have done exactly what they were set up to do. What the assembled stack never set up was someone with the authority to bring those approvals together and ship. 

Integration debt

When you assemble your own stack, you own every connection between the components. The billing connection that handled a demo now has to cope with a busy system limiting requests or going offline. If a credit succeeds but the confirmation never arrives, the agent needs a way to establish what happened before trying again. Otherwise, a temporary connection failure can become a duplicate credit.

That obligation doesn’t end at go-live. Upstream components keep changing. Their maintainers support their own software; your team owns the connections between them. Every update requires attention to what still works across the whole service. That continuing obligation is integration debt, and the pilot’s budget and schedule rarely account for it. 

Other teams face the same production hurdles

Repeated delays make it easy to suspect that your team is taking longer than everyone else. The evidence shows otherwise. In the Unmet AI Needs Survey 2026, 94% of respondents reported operational failures after deployment. Not during the pilot. 

The gaps you’re coming up against — governance, ownership, integration — are structural. They show up regardless of how the stack was built. 

The same survey found that 72% had exceeded their expected operating budgets. The prototype budget that justified the build decision was never a reliable guide to what production would cost. That doesn’t make the decision wrong. It just means the real cost was always going to surface later. 

Every month in testing has a cost

“Almost there” has stopped giving finance enough information to plan around. Public API charges and compute costs continue throughout testing. Some of your strongest engineers stay occupied with maintaining the pilot, checking component changes, and preparing the next demonstration. That work consumes time you expected to put toward the next business problem. In support, people still handle the billing disputes the agent was meant to resolve.

The delay also changes what finance is evaluating. At first, the question is when this agent will ship. Eventually, it becomes whether the organization should have built its own stack at all. A sound architecture decision becomes harder to defend when every status update leaves the business waiting. 

Name the owner before go-live

The build worked. The agent works. What’s missing is the person who owns getting it live and keeping it there. Name that person before anything else.

If your pilots are working but production hasn’t started, read DataRobot’s Agentic AI deployment for enterprises, a practical look at what most assembled stacks are missing.

The post You assembled the stack. Who owns go-live? appeared first on DataRobot.

In-home assistive robots could clean and organize a home while the owner is away, but without enhanced memory capabilities, they could cause more problems than they solve. They could, for example, cause a major inconvenience if they move important objects like wallets and keys but are unable to tell the owner where they put them.

An octopus can bend one part of an arm around an obstacle while another reaches into a small crevice to grab an object. Reproducing that local control in a soft robot requires multiple actuators—components that turn energy into movement—together with their mounting hardware and connections.

For a service robot moving through an office, recognizing "furniture" is useful. When the robot has to plan a route or interact with objects, it also needs finer detail, such as whether that furniture is a chair, table or bookcase, and whether an opening is a door or a window. These distinctions can affect how a machine moves, avoids obstacles and decides what it can safely interact with.

Proof of concept for watermarking AI-generated proteins while preserving biological function.

We are used to seeing images of humanoid robots clumsily walking, stumbling over objects and awkwardly freezing in place. Struggling with real-world movement is one of the biggest drawbacks of current robotics. But now a team of researchers has come up with a new system to make them move and react far more reliably, and they worked everything out on a bunch of soccer-playing robots.

A quick search of humanoid robot videos will deliver demonstrations of two-legged robots playing soccer, dancing, jumping several feet in the air, even competing in kickboxing matches. It is all dazzling, certainly. But roboticist Aaron Ames, the Booth-Kresa Leadership Chair and director of Caltech's Center for Autonomous Systems and Technologies (CAST) and a leader in the field of robotic safety, has deep concerns. What is crucially missing before humanoids can play a larger role in our lives and society, Ames says, is safety.

This article first examines the basic requirements of underwater robot power systems, then analyzes the key challenges encountered in practical design and the corresponding solutions, before introducing underwater thruster solutions for different applications.

I realize I am dating myself to some extent, but my first cell phone plan came with a fixed number of minutes and a small allotment of text messages, and anything beyond that was billed one at a time. You […]

The post The Real Cost of AI Hasn’t Shown Up Yet appeared first on Techspective: A Unique Perspective on Technology.

By Emmet Cole

“Robotics and automation” is a pairing heard often around these parts. It puts the “RA” in IEEE RAS, after all.

The familiar combination shows up in conference titles, funding calls, and program descriptions. But what is actually meant by the two words? Is robotics a subdomain of automation? Does the distinction matter?

As a recent IEEE RAS Communications Board meeting drew to a close, IEEE experts informally reflected on these questions and their significance for the RAS community and beyond.

The excerpts below have been lightly edited for clarity.

---

Sabine Hauert: We often use the phrase “robotics and automation,” including in the name of IEEE RAS. But what do we actually mean by those two words? Why is there a distinction, and does it accurately capture our fields?

Mariateresa Pedone: My feeling is that automation is almost invisible in everyday life. Its role is mainly to make processes repeatable, efficient, scalable and predictable. Robotics becomes relevant when automation needs a physical presence.

Sabine Hauert: That gives us a useful starting point with automation as the process, and robotics as its physical presence. David, do you see it that way?

David Garzon Ramos: My feeling is that automation has focused on supporting other activities. We automate a process because we want to make it more efficient or effective. Robotics, meanwhile, has also developed on its own grounds. We develop robots partly because we want to understand principles of intelligence, control and embodiment. That is how the history of the two fields has played out.

Sabine Hauert: Would that make robotics a subcategory of automation?

David Garzon Ramos: I don’t think anybody necessarily wants to say that one is broader than the other. We see a similar question now with physical AI: is physical AI broader than robotics? Maybe, maybe not. These descriptions help people identify with a particular community. They can also help to manage expectations about the kind of work being done.

Claudio Pacchierotti: I would add that not all robots are automated. You can have robots that are fully teleoperated by humans, so there is little or no automation involved. A robot is a machine that physically interacts with the environment, while an automation process does not have to involve a robot. Not all automation involves robots, and not all robots are autonomous.

Sabine Hauert: That complicates the picture. Automation might not require a robot at all; it could be carried out entirely through software. And a robot could be controlled by a person rather than operating autonomously.

Ellen Rumley: The definition of robotics can become hazy too. Imagine a large factory with a computer-controlled conveyor system that interacts with the physical world and sorts packages. Do we consider the whole system a robot if it isn’t an individual unit that moves around or appears somewhat lifelike?

Claudio Pacchierotti: I introduce this question when I teach robotics to elementary school children. The first activity is simply: “Is this a robot?” A washing machine washes your clothes in a very physical way. In one sense, it could be seen as a robot. It is also highly automated. Yet most people would say it is not a robot. Once you start testing the definition against familiar objects, the boundary becomes interesting.

Ellen Rumley: These questions have practical consequences. I do a lot of comparisons of industrial and service robotics between countries, and the categories are not always consistent. Robot vacuum cleaners, for example, may be counted differently in different countries. China can appear to produce millions more service robots partly because of what is included in the category. Definitions affect the international comparisons and the story the numbers appear to tell.

Sabine Hauert: So, this is not only a philosophical or linguistic question. What counts as a robot can affect statistics, national comparisons and perceptions of technological strength.

Amy Eguchi: It also affects education. My background is in education, and robotics was an addition to my work. Whenever I return to Japan, I see more everyday appliances with automated functions. A washing machine can dispense its own detergent and softener, remember your preferred settings and complete the process after you press one button. I have also seen products advertised as having an “AI microwave.” Is that a robot, or is it simply automation?

Sabine Hauert: So, the answer may depend partly on what people encounter in everyday life.

Amy Eguchi: Exactly. A definition may seem clear when you read it, but the categories overlap in practice. Children in different countries are familiar with different devices. That changes the examples educators can use and perhaps what children intuitively understand as robotics, automation or AI.

Sabine Hauert: We are also discussing two English words. Other languages and cultures may not separate the concepts in quite the same way. And once a technology becomes familiar, it can disappear into the category of the appliance. A robot vacuum eventually becomes simply a vacuum.

David Garzon Ramos: The language also changes with research trends. Now that I write proposals, I use terms such as “physical AI” and “embodiment,” although I still describe myself as a roboticist when I talk to friends. The same has happened with terms such as intelligent systems, AI and machine learning. Concepts become entangled because the language helps attract attention and communicate with particular audiences.

Sabine Hauert: From a communications perspective, that can be difficult. Every new project seems to require all the relevant words—robotics, automation and now sometimes physical AI. It raises the question of what the differences are, where the fields overlap and why they cannot simply sit under one recognizable term.

David Garzon Ramos: I think it depends on the purpose. If you are speaking to children, “robot” may immediately create interest, while “automation process” may not. “Physical AI” may confuse them again. We need to be flexible and use language in ways that are useful to the audience. If we fix a definition today, the terminology may shift when a new model or research trend appears.

Sabine Hauert: I think there is a historical element too. Conference names and the names of professional communities preserve something of the way the fields developed. Sometimes a new word takes over, and sometimes another is added. But all these areas are closely linked. We may not have settled the definitions, but we have shown why these overlaps are worth discussing.

---

Are you a roboticist who dabbles in automation? Or an automation specialist who occasionally ventures into robotics territory? Is the distinction important and/or meaningful? Drop us a line and we may share your insights in a future feature article.

Swimming can take a lot of muscle. But as MIT engineers have found, even a single layer of muscle cells can power through water if designed right. In a paper published Sept. 28 in the journal Advanced Functional Materials, the team presents a design for a thin, muscle-powered swimming robot. The "skeleton" of the aquabot is made from a film of gel about the length and width of a stick of gum. The two halves of the gel form the bot's "fins." Each fin is covered with a layer of live muscle cells much thinner than a single strand of hair. The cells are genetically engineered to twitch in response to light.

A Venus flytrap closes its leaves to trap prey when it senses a stimulus. Taking inspiration from this plant, KAIST researchers have combined the roles of skin that senses approaching objects and muscle that grasps them in a single soft material. When an electrically charged object comes near, ions inside the material move and produce an electrical signal.

The HaiPick Climb system was designed around a practical question: How can warehouses gain the storage density and throughput associated with AS/RS while making the solution easier to implement, operate, maintain and expand?