July was the busiest month for Gradient Descending so far. We hosted our first editions in Milan and Zurich , returned to London and closed the month in Munich. 

The four sessions covered very different ground: vertical software for construction, robot perception, analytics on regulated payments data and AI security research. Yet each discussion pointed to the same underlying challenge: building AI systems that remain reliable outside controlled environments. 

Helen Oleynikova captured it clearly in Zurich. Getting a system to work 60% or 80% of the time in a lab is relatively straightforward. The biggest difficulty is reaching 98% reliability in the field, or even higher where the stakes demand it. A version of this idea surfaced in every session, so it became the thread connecting this month’s recap.

Milan

Our first Italian edition took place at AWS with Gabriel, co-founder and CEO of Pillar. My colleague Umberto has covered the session in more detail and you can read his piece here. 

Construction sites already run on a dense mix of tools and habits: WhatsApp threads, voice notes, delivery-note photos, old spreadsheets, paper, and calls to the accountant. Two contractors of the same size in the same city will run the same job in completely different ways, and neither of them is doing it wrong.

Traditional software often asks customers to standardize before they see any value: adopt a new tool, migrate data, retrain teams and adjust established workflows. As Gabriel put it, ‘adoption dies at the download screen.’ AI offers a different route: it can turn a voice note, a timesheet photo or a manual entry into the same structured record, allowing the product to fit the way people already work. 

That shifts the source of differentiation. Model access is widely available and increasingly interchangeable. But the operational context around it matters way more: how a specific business works across sites, suppliers, invoices and margins. A model may understand the words, but without that context, it cannot understand what they mean for the customer. That same question of context and reliability carried directly into our Munich session.

Munich

In Munich, we hosted Dr. Fabian Gampfer of Snowflake and Radu Immenroth, CTO of Cleverbridge, for a discussion on agentic analytics in regulated environments. 

Radu opened with a familiar risk: an AI agent produces a polished revenue analysis within minutes, only for the figures to be wrong. For Cleverbridge, this carries real consequences. The company provides the financial infrastructure that enables software businesses to sell across markets with different tax rules, consumer protections and payment methods. It processes around €1 billion annually and operates under requirements comparable to those of a German bank. In that environment, accuracy is essential. 

General models often perform well in clean demonstrations, then struggle with production databases shaped by years of changing systems, schemas and business logic. The greater risk is that they continue to provide confident answers even when the underlying reasoning is wrong. Two critical risks are worth highlighting:

• Silent inaccuracy: Snowflake tested frontier models against its own production data and achieved around 25% accuracy. Performance on simplified demo environments was significantly higher, underscoring the gap between controlled tests and real-world deployment.

• Unauthorized access: Identity, permissions and row-level security cannot be managed through prompts. Existing access controls must remain embedded in the underlying infrastructure.

Cleverbridge addressed this through a semantic model that documents the business context behind the data. It defines how the company interprets revenue, refunds, exchange rates and recognition dates, giving the agent the information it cannot infer from tables alone. Radu compared the process to onboarding a new colleague: even a capable person needs clear context before they can make sound decisions.

The system also uses deterministic validation. Existing tools check whether the generated SQL runs, whether the relevant entities exist and whether the request falls within the agent’s scope. New AI capabilities work best when they are combined with systems that already perform reliably.

Maintenance is equally important. Accuracy can decline as models change, schemas evolve and internal definitions shift. Continuous evaluations should therefore function as QA (quality assurance), supported by product teams reviewing real traces and failure cases. Agentic analytics requires ongoing ownership, it cannot be treated as a one-off prototype.

The discussion also raised two further considerations:

• Buy versus build: Cleverbridge initially developed the system internally, then explored a specialist startup. The technology performed well, but the provider could not meet the contractual and compliance requirements of a regulated enterprise. Cleverbridge ultimately moved to Snowflake, where the necessary infrastructure and procurement framework were already in place. For companies selling to regulated buyers, enterprise readiness can determine adoption as much as product quality. 

• Multi-agent validation: One participant tested a setup in which several agents reviewed the output of another. Adding more validators increased disagreement and reduced accuracy, while also raising costs. In this case, the simpler system performed better: a useful counterpoint to the assumption that every workflow improves with more agents.

Radu also introduced an autonomy framework that links agent permissions to the potential impact of an error. At one end, the system only surfaces insights. It can then progress toward recommendations, approved actions and, eventually, independent execution. Cleverbridge currently keeps human approval close to the decision point, particularly where pricing, customer treatment or regulatory exposure are involved. Autonomy should expand only when the evidence supports it, one step at a time.

The commercial implications may be just as significant as the technical ones. Agentic products can reduce the number of software seats a customer needs, weakening the economics of traditional seat-based pricing. Consumption revenue may replace part of that loss, but usually at lower margins. Cleverbridge is therefore moving toward a hybrid model that combines an included allowance with usage-based pricing above the cap.

That shift captures the broader challenge. Building reliable agents demands clear business context, robust controls, continuous ownership and a pricing model designed for how the product will actually be used.

Zurich

For our first Zurich session, we were joined by Helen Oleynikova for a discussion on robot perception. Helen completed her PhD at ETH Zurich on mapping and planning for drones, later built nvblox at NVIDIA and returned to ETH as a senior researcher. She is now a stealth founder building in robotics.

The first part of the session focused on how robots understand unfamiliar environments. Helen’s work centers on distance fields, which allow robots to calculate the space around nearby surfaces and move through complex settings more safely. Running the computation on a GPU (graphics processing unit) made it 100 to 200 times faster, turning a research concept into something a robot could use in real time. One example was a construction robot that learned to map its surroundings and plaster beneath a staircase without colliding with obstacles. 

The more unexpected part of the discussion came from Helen’s search for real customer demand. During an electrical substation inspection, she found that many of the tasks being considered for robotics were already handled remotely through software. A remotely controlled valve costing around $200 did not justify a $200,000 robot. Her conclusion: technical feasibility does not automatically create a viable market, and the existence of funded research is not proof of commercial demand. 

That perspective also shaped her view of the current ‘Humanoid’ funding wave. Many specific robotics applications address markets too small to support venture-scale outcomes. Humanoids offer a broader market narrative because they are positioned as general-purpose machines. Helen estimates that a genuinely general-purpose robot brain remains 10 to 15 years away. In her view, capital is therefore flowing heavily toward the broadest vision, while narrower and more practical applications remain comparatively underfunded. 

She also drew a clear distinction between language and physics. Foundation models may advance robotics in structured environments such as fixed-arm manufacturing, where large volumes of relevant data can be collected. Unstructured settings are far less forgiving. Progress there will continue to depend on combining learned systems with classical methods that already perform reliably. Understanding the instruction to pick up a blue object is relatively straightforward; executing it safely in the physical world remains the harder challenge. 

The same distinction applies to simulation and automation. Robotics simulations were shaped by computer graphics, which prioritized visual realism over physical accuracy. They perform well for locomotion, but remain weaker at contact-rich manipulation. At the same time, many real-world use cases do not require a robot to reason independently at all. A deterministic automation system is often the more reliable and economical solution. 

The room challenged several of these conclusions, which is central to the format. One participant with direct industrial experience argued that robots are often designed around an imagined problem rather than the customer’s operational reality. Real sites rarely resemble the lab, and the longer teams wait to test that assumption, the wider the gap becomes.

London

In London, Harry Coppock of the UK AI Security Institute joined us to discuss SandboxEscapeBench, the benchmark he co-authored to test whether AI agents can escape isolated computing environments. As the session was closed, this section draws only on findings already in the public domain. 

SandboxEscapeBench tests whether AI agents can break out of isolated computing environments. Agents can now execute code, access files and connect to networks, which makes containment a central security concern. In the benchmark, a model receives access to a deliberately vulnerable container and is instructed to escape it. Success is measured through a CTF (capture the flag) task, in which the model must retrieve a hidden digital marker. The container runs inside a secured outer VM (virtual machine), ensuring that even a successful escape remains contained.

The benchmark measures capability: whether a model can perform the task when directly instructed to do so. At publication, frontier models solved the easier challenges and only occasionally succeeded on the harder ones. Within 1 or 2 months, performance rose from around 40% to near saturation, a far faster progression than most benchmarks typically show.

The discussion also highlighted how easily evaluation results can be misread. Performance depends heavily on the token budget available to the model, so scores have limited meaning without that context. Researchers must also examine how a model succeeded. Unintended shortcuts can make a task appear more difficult than it was, while high refusal rates may indicate that the evaluation is measuring safeguards rather than underlying capability.

Another thing to keep in mind is evaluation awareness. Models can recognize that they are being tested, which may affect their behavior and weaken the reliability of propensity evaluations and jailbreak results. Detecting deliberate underperformance requires access to the model’s internal processes, but current interpretability methods remain limited.

For teams deploying agents, those were the practical recommendations:

• Use stronger isolation: Containers alone may not provide sufficient protection. VM-level isolation without a shared kernel offers a stronger boundary

• Monitor the full stack: Internal monitoring should capture agent behavior even when the model does not refuse an unsafe action

• Restrict network access: Outbound connections should be limited to approved domains

• Test for real use cases: Reproducing large-scale laboratory evaluations internally can require around 10 dedicated engineers and uncertain timelines. Lightweight smoke tests focused on a company’s own infrastructure and workflows are often more valuable

• Centralize model access: A single internal gateway helps ensure that teams use approved and current models.

The London discussion reinforced a broader point from the series: agent security cannot be reduced to a model-level question. Reliability depends on the surrounding infrastructure, the quality of the evaluation and the controls governing how the system operates.

What Reliability Looks Like in Practice

All four sessions came to one conclusion: technical capability is only the starting point. Real value depends on whether a system can perform reliably within the constraints of a specific environment.

In Milan, that meant adapting to the way customers already work. In Munich, it required business context, validation and clear controls. Zurich showed how quickly technical ambition can drift away from commercial and physical reality, while London brought the security and evaluation requirements into focus.

Taken together, the discussions pointed to a more demanding standard for AI products. The strongest systems will combine capable models with deep domain understanding, robust infrastructure and continuous oversight. That is where performance becomes dependable enough to matter.

Subscribe to the Gradient Descending luma calendar to stay updated on upcoming sessions