Agents are harnesses, not intelligence
Guillaume Larcher is using Pi, OpenClaw’s backbone, as a thin execution layer wired to models like Opus or Codex. A deliberately minimal setup, limited to file read and write, bash, and grep. What matters is not intelligence inside Pi but its ability to orchestrate tools and extend itself dynamically. At Linkup, he shows this with x402 (open standard for internet native payments): the agent detects that an API implements the protocol, generates the client, loads the relevant skill, and executes a crypto transaction end to end. The model is interchangeable. The harness is not.
Sylvain Utard applies a similar approach with OpenClaw in a production setting at Altertable. His agent, Albert, has its own GitHub account, reads notifications, clones repositories, writes code, and opens pull requests across multiple SDKs. It has no privileged access and behaves like an open source maintainer. The setup is intentionally constrained but highly effective. Updating a dozen SDKs from a spec change becomes a single instruction. The workflow is spec driven: repositories define expected behavior, and the agent propagates changes consistently across languages and environments.
Agents are not defined by the model they use but by the permissions, tools, and execution structure around them. Much of the leverage comes more from how agents are wired into real systems, than which model is used.
Takeaways:
-
The model is interchangeable. The harness defines what the agent can actually do
-
Treating agents as external contributors creates a clean and enforceable security boundary
Developer cost explosion
The discussion surfaces a concrete shift in how companies experience developer cost. Several participants compare traditional salaries to the new reality of agent driven workflows. Cursor alone can reach 100 to a few hundred dollars per developer per month. One example mentioned a single developer burning thousands of dollars.
What emerges is not just a tooling expense but a new category of variable cost tied to autonomy. Agents do not consume resources linearly. They can trigger API calls, loop on tasks, or execute workflows without clear stopping conditions. Quentin Dubois and others note that this makes cost harder to predict than traditional infrastructure. Koutheir Cherni sees similar patterns on the data side, where agents interacting with enrichment APIs can burn through credits overnight if left unconstrained. At the same time, no one in the room is seriously considering going back. For Sylvain Utard, even at several hundred dollars per developer, the productivity gain is still worth it.
Takeaways:
-
Agent usage introduces a new variable cost layer on top of developer salaries
-
Costs can spike unpredictably when agents run unchecked
-
Teams accept higher tooling costs because of the perceived productivity gains
Evaluation without code ownership
Jules Pondard frames evaluation as the bottleneck, not generation. Teams can produce code faster than they can decide whether to keep it. Quentin Dubois makes it more blunt: “I don’t know how to scale a tech team anymore.” When code is generated, no single person fully understands it, yet someone still needs to take responsibility for it, especially under constraints like audits or SLAs.
This shows up in how teams configure their environments. Some allow agents to operate at full throttle in internal contexts, removing staging layers and letting systems iterate directly in production-like environments. The goal is to reduce friction and move faster, but this only holds under specific conditions. As soon as systems become customer-facing or subject to compliance, teams reintroduce layers of validation, review, and control. Evaluation is no longer just about correctness. It becomes a question of what can be trusted, and under which conditions, in systems no one fully wrote.
Takeaways:
-
Code generation has outpaced evaluation and ownership
-
Full throttle agent setups are viable mainly in controlled internal environments
-
Evaluation shifts toward trust and responsibility rather than correctness
-
Compliance and audits still impose theoretical human validation layers
Multi-model workflows as control
Quentin Dubois and others rely on switching between models as a practical way to get unstuck. Claude, Gemini, Codex, Cursor. Each provides a different angle on the same problem, and moving between them helps escape local minima when one model overfits on context.
Cursor is praised for speed and immediacy, often giving the impression it skips planning altogether. Claude, in contrast, is described as slower and more verbose, but often perceived as more reliable. This leads to workflows where developers combine tools depending on the task, not because one is strictly better, but because each behaves differently. There is also a growing suspicion that reasoning traces are partly performative. A recent paper shows that models can become confident in their final answer early, then continue generating reasoning tokens afterward without reflecting their actual internal state.
Takeaways:
-
Switching models is used as a practical way to get unstuck
-
Different tools are chosen based on behavior, not just capability
-
Speed versus perceived reliability drives tool selection
-
Reasoning traces may not reflect actual decision processes
Running models in constrained environments
Henri Mirande raises a practical question: should a startup run models on prem from day one. The answers lean operational rather than ideological. Quentin Dubois describes a deployment for Orange where models and infrastructure had to run entirely inside the client environment. The impact was immediate. No telemetry, limited visibility into failures, and much slower iteration cycles. What looks like a deployment choice quickly becomes a product constraint. You are no longer just shipping features, you are operating blind inside someone else’s infrastructure.
Glenn Sonna approaches this from Xybrid, where the focus is on running models locally across devices through a unified gateway. Whether it is a data center or a smartphone, the problem is the same: limited compute, limited memory, and no external fallback. The goal is to reduce fragmentation across model formats and runtimes, but the constraints remain. This forces tradeoffs on model size, performance, and even product design. In parallel, teams explore privacy preserving approaches like homomorphic encryption or MPC, but these remain too slow or too expensive for most production use cases.
Takeaways:
-
Running models on prem or on device turns infrastructure constraints into product constraints
-
Lack of telemetry and observability significantly slows iteration cycles
-
On prem and on device share the same core constraint class
-
Advanced privacy techniques remain impractical for most production workloads
Our guests:
-
Altertable The operational lakehouse for AI workloads
-
Guepard Instant database clones for teams and agents
-
H Company The future of autonomous, agentic AI
-
Linkup World’s best search for AI Apps
-
OSS Ventures Startup studio in manufacturing
-
Xybrid Hybrid on-device AI