October took Gradient Descending to Turin, Berlin, Zurich and London, with conversations about securing agents, building commercial teams, getting robots into production and understanding what inference actually costs. Across those discussions, we kept coming back to the decisions that become harder to ignore as a company grows: what a system can access, how a process gets repeated, who maintains what you build and whether the economics still work.

Turin on securing AI agents

In Turin, Luca Palmieri, CTO and co-founder of a company building in agent security, joined us to discuss what changes when AI systems can take action.

Luca described two ways an agent can get into trouble. It can pursue a legitimate goal through an unacceptable route or it can be redirected by malicious instructions in something it reads. The second problem becomes particularly consequential when the same agent can consume untrusted material, access sensitive data and act on other systems.

The practical discussion focused on how to set useful boundaries. You may not know every step an agent will take to complete a task, but you can often define the resources it should need. An agent assessing an insurance claim might require the customer’s records and the relevant policy. That does not give it a reason to access the company’s entire accounting system.

Permissions, isolation and approval points therefore need to be designed around the job. Sandboxing is part of that, alongside controls where the agent connects to external tools and data. Those connections are where much of its usefulness comes from, and where consequential actions need to be checked.

One distinction was especially useful: running a model locally changes where the data goes, but does not by itself resolve prompt injection. Teams still need to control how an agent responds to what it reads and what it is allowed to do next.

Berlin on building GTM in the AI era

For our first Gradient Descending session in Berlin, we were joined by Elmar Schaaf, GTM Lead at Langdock, who previously spent four years helping scale Parloa.

His starting point was refreshingly familiar - know who you are selling to, understand the problem they need to solve and establish how your sales process works. That gives you something useful to automate.

At Langdock, the sales handbook is written for both people and agents. That makes the quality of its instructions more consequential. An unclear process can become a repeated mistake across the workflows that follow it. Keeping the handbook accurate becomes part of running the commercial organisation.

The same discipline applies to the tools around it. Elmar described an approach borrowed from engineering: define the scope, review the work, document it and give someone responsibility for maintaining it. Being able to build a new tool quickly does not remove the work of keeping it useful. Every addition creates another ongoing commitment.

Throughout the discussion, the purpose of that automation remained clear: give sellers more time with customers. Understanding a buyer’s internal priorities, earning their trust and finding the detail that helps a deal move forward still takes a conversation.

It was a practical view of what AI can do for a commercial team. The opportunity is to create more time for the work that depends on relationships, while making the repeatable parts of the process easier to run.

Zurich on taking robotics into production

In Zurich, we teamed up with Pluto for a session with Marcin Dymczyk, co-founder of Sevensense Robotics, now part of ABB Robotics.

Marcin traced much of Sevensense’s progress back to its first paying customer, a manufacturer of cleaning machines. That relationship gave the team deadlines, a reason to prioritise particular features and a demanding test of whether its autonomy technology could become a dependable product. It also helped prepare the company for deployments in busy industrial environments.

Some of the most useful lessons concerned work that can seem premature when a company is small. Early engineers pushed for infrastructure to collect field data and evaluate performance, even when there were relatively few deployments. Looking back, Marcin saw that investment as central to the reliability the product would later need.

Other lessons came from integration. Specifications had sometimes been too loose, with insufficient clarity about what each partner would deliver and how the systems would connect. Resolving that ambiguity mattered as much as improving the technology.

He also made a case for paid pilots. In his experience, putting a budget behind a project helped establish whether the customer cared enough about the outcome to stay involved.

As deployments became more repeatable, the team’s concerns changed again. Sourcing cameras and computers, managing production and delivering on time became increasingly important. Scaling a robotics company brings a substantial amount of operational work alongside the research.

London on what inference actually costs

In London, Povilas Nagrockas, CTO and co-founder of Condense, challenged several assumptions about the economics of running open models in production.

The useful unit of comparison is the cost of completing a task at the quality you need. A model with a lower token price can still produce a more expensive workflow if it takes more turns, makes more tool calls or generates work that has to be redone.

That becomes particularly important as agents work through longer tasks. The context grows, earlier material gets read again and the cost of managing that history becomes harder to ignore.

Caching was one of the clearest examples. Its effectiveness depends on how the context is assembled and what changes between calls. Alongside the timestamp example, changing tool definitions can disrupt reuse. Even when caching works, repeatedly reading a growing history still costs money.

Routing between models needs similar scrutiny. Switching to a cheaper model can introduce the cost of establishing context again. One approach discussed was to give specialist subagents a defined task and have them return a concise result, with the model and context kept consistent within each subtask.

For teams choosing their stack, the implication was practical: test on the work your product actually needs to do, inspect where the spend goes and compare the full cost of reaching a useful result. A model’s rate card only tells you part of the story.

Also in October

October also included our founder matching event with Foundamet, while The Founders Padel Club brought founders and the Earlybird team together in London with our friends at Airwallex for games, drinks and a chance to catch up.

Thank you to everyone who joined us, shared what they are building and brought their perspectives to the table.