← All speakers

Bio, Work & Ideas

Philipp Schmid

Conference affiliation: Google DeepMind · 2026

Philipp Schmid is a Staff Engineer at Google DeepMind building the organization’s AI developer-experience and developer-relations team. He helps developers turn Gemini, Gemma, and other advanced models into usable software, with particular attention to agent reliability, practical tooling, and evaluation.

At Hugging Face, Schmid became a technical lead overseeing strategic partnerships with AWS, Google Cloud, and Azure. His work helped bring open-source models into managed cloud environments: he authored an early guide to the Hugging Face–Amazon SageMaker partnership, introduced large-language-model inference containers, and contributed to deployment infrastructure supporting AWS Inferentia2 and Hugging Face Inference Endpoints.

He joined Google DeepMind in 2025. His current work encompasses Gemini and Gemma across cloud and on-device environments, combining developer education with the engineering questions involved in building useful agents: conversation state, multimodal inputs, tool integration, inference costs, and reliable execution.

  • Context is application state. Agents operate on user intent, preferences, previous decisions, and changing instructions that cannot always be reduced to predefined flags. Schmid argues that developers should specify goals and constraints while allowing models latitude in how they achieve them. His account of why experienced engineers struggle with agents emphasizes preserving semantic context and designing tools whose descriptions expose assumptions human programmers might leave implicit.
  • Reliability requires repeated evaluation. A single successful demonstration cannot establish whether a nondeterministic agent works consistently. Schmid favors repeated trials, execution traces, outcome-based grading, and human or model-assisted assessment. His analysis of multi-turn coding evaluation extends that concern to changing requirements and earlier architectural decisions that can compromise later work.
  • Skills need evals and an expiration date. Schmid distinguishes temporary capability skills, which compensate for current model limitations, from durable preference skills encoding organization-specific practices. He recommends precise triggering instructions, negative test cases, progressive disclosure of references, and with-and-without-skill ablation tests. His Gemini Interactions API evaluation example demonstrates how trace inspection and lightweight validators can establish whether specialized guidance improves performance or should be retired.
  • Errors are inputs, not dead ends. Failed tool calls should inform an agent’s next action instead of automatically restarting lengthy workflows and discarding accumulated context. Schmid also treats interoperability pragmatically: the Model Context Protocol can reduce duplicated integration work, but models still select tools through ordinary function calling. His public analysis of multi-agent handoffs similarly concentrates on explicit coordination and stateless interaction.

Schmid maintains practical open-source examples through deep-learning-pytorch-huggingface, gemini-samples, and mcp-cli, a lightweight interface for interacting with MCP servers.

Read the topics behind these talks

5 conference talks

Key ideas

Scroll to read ↓

A hands-on path through Gemini’s Python SDK, token accounting, document extraction, native tools and MCP, with the state, cost and execution boundaries made explicit.

  • What does it take to make the first request?
    0:31 ↗
  • Move an AI Studio experiment into Python
    4:52 ↗
  • Generate text, then account for all the tokens
    11:07 ↗
  • Control reasoning with a token budget
    16:20 ↗
  • Stream the answer and keep conversation state explicit
    20:12 ↗
  • Upload a book without confusing storage with context
    24:59 ↗
  • Ask a PDF a concrete question
    30:11 ↗
  • Test visual structure before building a preprocessing pipeline
    40:55 ↗
  • Turn document answers into typed data
    51:08 ↗
  • A function call is a request for the application to act
    57:09 ↗
  • Distinguish generated code from executed code
    1:03:37 ↗
  • Compose research and tool workflows
    1:10:10 ↗
  • Pass an MCP session to the SDK
    1:19:59 ↗
  • Manage what enters context
    1:27:20 ↗
  • Keep execution, authorization and attribution separate
    1:34:30 ↗
  • Preserve the prefix and inspect the evidence returned
    1:42:02 ↗

Key ideas

Scroll to read ↓

Build a small coding agent, give a conversational model tools and vision, and follow the deployment and reliability tradeoffs exposed by the live demonstrations.

  • Start with a key—and a device that can use it
    1:43 ↗
  • One interaction surface for models and agents
    8:39 ↗
  • Keep history on the server without surrendering context control
    11:24 ↗
  • The loop connects reasoning to action
    14:31 ↗
  • Give the coding agent documentation it can use
    17:29 ↗
  • Build the smallest stateful agent
    25:09 ↗
  • Add file tools, then close the execution loop
    30:11 ↗
  • Use conversation to expose missing instructions
    35:01 ↗
  • Branch history, but account for expiry and context limits
    42:55 ↗
  • A live DJ with a music-generation tool
    49:02 ↗
  • What travels over the Live connection
    54:49 ↗
  • Prompt the voice, then test its access to facts
    59:24 ↗
  • Choose a generated app or a working example
    1:04:00 ↗
  • Route browser media through a Python server
    1:07:28 ↗
  • Connect directly using an ephemeral token
    1:14:09 ↗
  • Separate successful actions from unresolved failures
    1:19:49 ↗
  • Longer sessions require a policy for forgetting
    1:25:07 ↗
  • Choose conversational flow and control deliberately
    1:26:57 ↗
  • Recognizing speech is not authorizing its speaker
    1:33:22 ↗
  • Personalization, evaluation, and storage have separate boundaries
    1:39:23 ↗
  • Return to the failed weather answers
    1:45:16 ↗

Key ideas

Scroll to read ↓

A skill is useful only if it changes an agent’s behavior for the better. Small, repeatable evaluations reveal missed triggers, regressions, wasted context and when a skill can retire.

  • Everyone uses skills. Who tests them?
    0:16 ↗
  • A skill has layers—and a lifetime
    2:27 ↗
  • Make discovery precise and context selective
    5:34 ↗
  • Give the agent useful freedom, then test the boundaries
    9:03 ↗
  • A small harness for a newly released API
    12:35 ↗
  • Use cheap checks for concrete requirements
    14:32 ↗
  • Put evaluations beside the skill
    15:45 ↗
  • Measure outcomes without prescribing a path
    17:22 ↗
  • Test cleanly, repeat, and keep the eval
    18:46 ↗
  • Start with the skill you use most
    20:18 ↗

Key ideas

Scroll to read ↓

Building reliable agents means preserving intent, letting plans change, recovering from failures, and evaluating outcomes instead of prescribing every step.

  • From prescribed steps to delegated goals
    0:15 ↗
  • Text as state
    2:05 ↗
  • Let intent change during the conversation
    3:42 ↗
  • Return errors to the agent
    4:53 ↗
  • Trace the route, grade the outcome
    6:13 ↗
  • Make the tool contract carry the meaning
    7:47 ↗
  • Choose what reliability must mean before release
    9:04 ↗
  • Build to delete
    9:53 ↗

Key ideas

Scroll to read ↓

Philipp Schmid rebuilds a GitHub pull request reviewer three times, moving from a handwritten Python loop to a hosted agent with Bash, files, and search. The progression shows which code can disappear, where execution moves, and why instructions and evaluations remain your responsibility.

  • Frameworks can remove handwritten loops and schemas while leaving the developer responsible for tool implementations and hosting.
    5:40 ↗
  • The remote reviewer uses Bash, a filesystem, and the GitHub CLI to discover and satisfy an execution prerequisite before continuing its task.
    10:11 ↗
  • A network proxy injects credentials outside the sandbox. Keeping the token hidden and limiting authenticated actions are distinct concerns.
    8:40 ↗
  • Managed execution moves loops, routing, session state, and compaction server side; instructions, capabilities, evaluations, and outcome verification remain product work.
    13:10 ↗
  • Skills and saved files can extend capabilities or carry preferences and handoffs. Improved models should create opportunities to delete orchestration that no longer earns its place.
    14:41 ↗

References