Claire chatted to Michelle Lu from Vsim Technology about using simulation and artificial intelligence to teach robots new skills.
Michelle Lu is co-founder and CEO of Vsim Technology. She was previously a Director of Simulation Technology at NVIDIA, where she and her co-founder created the world’s first end-to-end GPU-accelerated reinforcement learning (RL) framework, Isaac Gym, which set the template for how modern GPU-accelerated simulation-based RL is performed in robotics. In 2022, Michelle and her co-founder left NVIDIA to create Vsim, driven to solve the limitations that plague simulation-based robotics AI: efficiency, scalability and the sim-to-real gap.
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.
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.
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.
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.
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.
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.
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.
“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.
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.