Schedule

My call: Machine-checkable ontologies are your data track's meaning layer: canonical definitions turned into enforceable contracts.

This talk echoes Pocock’s “shared understanding” and augments it -- turning that language into a machine-checkable model: typed entities, relationships, allowed states, and inference rules.

My call: Strong on your trust theme and a look at Claude Managed Agents, but it overlaps both morning talks in Room 1, which have more concrete evidence.

Agents can now work for hours, but most of us still approve every step or skip the prompts and hope. This session asks where we are on the curve for trusting agents, and what has to be true before we hand them much more work. It draws on decades of trust research, from how societies learned to trust strangers to how pilots learned to trust the autopilot. Then we use Claude Managed Agents as a reference implementation for building systems that are safe, secure and trustworthy by default.

My call: A Codex feature tour. Better read from the changelog than sat through.

Keeping up with the rapid changes in coding agents can be exhausting. Join Dominik Kundel for a practical tour of recent features and workflows to bring you up to speed, without all the noise. We'll cover with live demos and walkthroughs how you can make the most out of your ChatGPT subscription whether you are pair programming with Codex or having your dot manage your incidents.

My call: Teaches what you already do. You build harnesses with fingerprints and receipts every day.

Start with an agent that lies about finishing, and leave with a harness you'd trust with your repo. A bare agent loop ends when the model says it's done. In my AI Engineer Europe 2026 talk, that loop hit a login page and reported success anyway. The model wasn't the problem: nothing around it checked anything. In this workshop we fix that by hand, one layer at a time, in TypeScript. We build every part of an agent harness from scratch: - **The agent loop:** call the model, run the tools it asks for, feed the results back. - **Guardrails:** iteration and context limits the model can't talk its way past. - **Context management:** what stays in the window when a run gets long. - **Deterministic verification:** read the trace, run the linter and the tests, and let a failed check overrule the model's claim. - **Retries and secrets:** a loop around the loop, and credentials the model never sees. One rule for the whole session: the prompt never changes. Every fix is code. You'll leave with a working harness on your laptop and the habit of fixing the harness before the prompt. Starting repo: https://github.com/TejasQ/basically-ai-harness

My call: Verification built around intent, with invariants drawn from old review comments. This is a client-ready story of your verify layer.

Our team merges 4x more pull requests than we did a year ago. Almost all of that code is AI-generated, human assisted. We tried scaling code review to match — more reviewers, AI review tools, stricter checklists — and none of it worked. What worked was stopping the fight over diffs entirely and building a verification layer around *intent*. This is the story of how one engineering team replaced the PR review bottleneck with an intent-driven verification workflow: capturing what a change *should* do before a single line is generated, encoding team standards as reusable invariants, and letting deterministic checks — not tired reviewers — produce the evidence that a change is safe to ship. I'll walk through the specific practices that made the difference — especially how we turned years of recurring review comments into machine-enforceable invariants — and share the results, the failures, and what we'd do differently.

My call: No abstract published, and the Syntax audience skews web development. The Omnigent workshop is the better use of this hour.

After seeing the mental health effects of AI coding throughout the industry, Scott surveyed nearly 4000 developers about how agentic workflows are affecting their mental health. Hear what's happening and why.

My call: Good general advice aimed at teams earlier in adoption than you and your clients.

Software development lifecycles are full of slow processes you can automate. Let's fix those before we go pretend to be AI astronauts. We'll cover a range of easy-to-adopt techniques for that kind of automation, and for pushing back against the agent-supercharged entropy that keeps trying to make your codebase slop out of control. You'll leave with prompts, skills and workflows you can put to work the same afternoon.

My call: Specialist agents across models and harnesses with defined roles and permissions. The closest hands-on match to your Workbench coordination work.

Build a GitHub CI workflow that uses specialist agents to review pull requests, coordinate bounded repairs, and validate the resulting changes. In this hands-on workshop, you’ll connect agents across models and coding harnesses, define their roles and permissions, and test the pipeline while Omnigent handles session lifecycles, delegation, and messaging. We’ll draw on how Omnigent uses its own agents to manage incoming issues and contributions as an active open-source project, examining what it takes to turn review findings into tested changes ready for human approval. You’ll leave with version-controlled agent configurations and a runnable workflow you can adapt to your own projects.

My call: A useful delegation playbook, but it is built on Factory and clashes with the Omnigent workshop.

Most teams still use agents one task at a time: prompt, wait, review, repeat. In this hands-on workshop, you'll go further and hand an entire stream of work to agents with Factory. Bring your laptop. We'll take a real project from goal to merged PRs, setting up the scope, guardrails, and review checkpoints that make delegation safe. You'll leave with a workstream running and a playbook for deciding what to hand off next.

My call: A sharp technique for making migration progress measurable. It starts late in the Omnigent hour, so catch it only if you leave that early.

Coding agents struggle with large migrations. A migration produces thousands of diffs, agents apply the same fix five different ways, and nobody can reliably say how much work remains. I migrated a production codebase to Effect by pairing each change with an ast-grep rule that matches the old pattern and a temporary skill that tells an agent how to fix a match. The list of matches told agents what to work on and told me how much was left. It also divided the work across parallel agents without overlap. But agents could also make a match disappear without fixing it, so I had to write rules that were hard to evade. I’ll show how the rule and skill pair worked on a real migration and what I would change next time.

My call: Quantization and speculative decoding are serving-team problems, not yours.

Coding agents are a dominant use case for LLMs, but they tend to use generalized inference setups even at large scale. Like any optimization problem, in inference you can get better results with better constraints. This talk shares specific techniques that you can apply when building an inference service for exclusive use in coding agents, including targeted quantization and pruning schemes, domain-specific post-training, KV cache management around compaction events, subagent session affinity in a world of autoscaling and load balancing, and code-specific speculative decoding techniques across both common model-based approaches (DFlash, DSpark, EAGLE) and deterministic speculation using n-grams.

My call: Multiplayer agents on Vercel, a stack you already deploy to. Worth it if the Kent Dodds room is full.

What does it take to build an agent that works across users, tools, and shared environments? In this hands-on workshop, we’ll introduce eve, Vercel’s agent framework, and explore the fundamentals of building your own agent harness. We’ll walk through the architecture behind multiplayer agents and how Vercel’s infrastructure fits together: Workflows for durable execution, Sandbox for isolated code execution, and AI Gateway for model access. Then we’ll put these concepts into practice through a guided exercise you can adapt to your own use case. You’ll leave with a practical understanding of the pieces behind an agent harness and a starting point for building and running your own agents on Vercel. Bring your laptop for the hands-on portion.

My call: No title or abstract published, so there is no case for it over Kent Dodds.

A look at where local AI stands today and where it might be headed. Drawing on experiences with models, hardware, and the people building with them, this session explores what’s changing, what’s becoming possible, and how local AI fits into the broader AI landscape.

My call: Invariants, decision records and reviewing systems instead of code. It matches how you already run this repo, so expect sharper patterns to take back.

Agents can write code. That's not the hard part anymore. The hard part is trusting what they ship. In this hands-on workshop, I'll show you the loop I run every day: agents safely build, verify, and deploy the outcomes I want, and that loop is hooked up to signal (my own ideas, user feedback, bug reports, and friction) so it keeps itself going. I haven't read 1% of the code in my product, and agents author and merge most of the PRs. That only works because of the system around them. We'll start by running autopilot (npx kcd-skills@latest autopilot) on a real repo, yours if you want, and use the questions it asks to lay the foundation: invariants, decision records that say when it's OK to change them, a primitives catalog, and an AGENTS.md that's a router, not a novel. Then we'll get into verification. That means separate reviewer agents, PR templates that have you review systems instead of code, cloud agents with their own computers that show their work, and a control CLI your agents maintain for themselves. Finally, we'll limit the blast radius with feature flags, health checks, and backups you've actually restored, and wire up the loops that keep it all moving. Bring a laptop and a repo you own. What you'll walk away with: - An autopilot plan for your own repo, with each step your agents can take on next - A primitives catalog and invariants your agents actually follow - A PR template built around intent, one-way vs. two-way doors, and system diagrams, so you review systems instead of code - A verification setup: an AI reviewer, agents that test the running app, and a control CLI they maintain - A blast-radius checklist: flags with an owner, a metric, and a removal condition, health checks after deploy, and tested restores - The loops that keep it going: bug reports, user feedback, friction, and nightly cleanup Prerequisites: nothing to install ahead of time, but a good internet connection matters. To follow along on your own code, bring a laptop with a coding agent you already use (Cursor, Claude Code, Codex, etc.) signed in, plus a GitHub repo you own and can open pull requests on.

My call: No abstract published, and it clashes with the Kent Dodds workshop.

We’ve seen a shift in the architecture of bleeding edge agents, motivated by the design of popular personal agents like Muse and Instinct. The latest agents run in the background and make progress on much larger goals. These proactive agents use primitives like schedules and event triggers, async subagents, browser use, and integrations with Slack and other messaging channels. Perhaps most importantly, they all have robust memory systems, which I’ll argue are the key to hitting the Goldilocks standard for proactivity.

My call: Moving harnesses from code to knowledge work is your Org Age buyer's question. The abstract is thin, so treat it as a useful warm-up for the Fraser talk.

How harness evolved from code to Knowledge work

My call: No abstract published, and it means giving up two hours of an afternoon with better options.

You will move from local coding in Google Antigravity to building a sandboxed remote agent on Gemini Managed Agents with reusable skills, vaulted credentials, and remote MCP. From there, you will connect the Gemini Live API to trigger remote tasks and steer your agents by voice.

My call: A good taxonomy with real deployments in lagging industries. It is the honest alternative to staying in Room 1 for Composio and Fraser.

Agents in 2026 split into a bunch of distinct shapes like externalized context with RLMs, agents messaging each other, harnesses the agent rewrites itself, sandboxes, orchestrators with sub-agents, and brute-force recombination. This talk goes through what each one helps with, then looks at three real deployments in industries/domains generally lagging in AI adoption that reused some of these patterns. We finish on where this is heading in 2027 with models that edit their own context, tweak other networks, get trained for exploration earlier, and learn continuously from tasks they generate themselves.

My call: Self-hosted inference on a DGX Spark. Impressive, but not a problem your clients have.

Claude Code without Claude. Codex without an OpenAI model. We’ll put both harnesses to work on a real codebase with open-weight models running on a DGX Spark. They’ll inspect the repository, change code, and test their work. The terminal experience stays familiar. The entire stack runs on hardware you control. Drawing on our work building vLLM Agentic API, we’ll show how we’re bringing familiar coding harnesses to inference engines and distributed serving stacks including vLLM, SGLang, NVIDIA Dynamo, and llm-d. The goal is to make the harness, model, and serving infrastructure independent choices. With Codex Cloud, the coding harness itself runs remotely. Behind that harness, the Responses API adds another layer of agentic execution: the server can manage conversations, execute tools, and retrieve context. We’ll open up that machinery and explore how responsibility gets divided between the harness and the agentic server. Drawing on our work building vLLM Agentic API, we’ll dig into conversation state, memory through retrieval and file search, and compaction: what the agent remembers, how it finds what it needs, and what survives when its context fills up. As more of the agent runs on servers, owning your inference means understanding—and controlling—this execution stack. You’ll leave with the setup and verification steps to run your own coding agent backend—from a DGX Spark on your desk to a shared GPU cluster. Choose the model, choose the engine, and scale the infrastructure while keeping the coding tools you already use. Key takeaways - Run it locally: connect Codex and Claude Code to open-weight inference on an NVIDIA DGX Spark. - Take it to a cluster: connect the same agent-facing API layer to distributed serving with llm-d or NVIDIA Dynamo. - Make the whole session work: preserve conversation history, tool handoffs, and streaming across backends, then verify the result through a completed coding task.

My call: "Provide context to AI" is your Intelligent Data track told by the CEO of Fivetran and dbt Labs. Watch how it gets pitched to the same buyer.

Business intelligence is dead; long live context! The new job of every data team is to provide context to AI, so that when your head of sales asks “give me your 3 best ideas for improving pipeline conversion”, it gives 3 great answers grounded in accurate, correct queries. The tools for providing this solution are the same tools you know and love: AI is just a new consumer of the data stack. Fivetran + dbt labs CEO George Fraser will take you through how real users solve this problem today, and demo live how to connect AI to real data.

My call: Netflix on overlapping MCP tools, routing evals and who owns the gates. This is the Workbench problem at scale. Don't miss it.

Two years ago, teams asked our platform team to connect their data to an AI assistant. Today they ship their own MCP servers in a week. That speed is a win, and it swaps one engineering problem for a harder one: how do you decide what gets through, what gets gated, and who owns the gates? This talk gives you a way to answer that — what stays team-owned, what becomes shared platform, and how to tell whether consolidating actually helped. At Netflix, bringing these tools together creates real value. Functions like Finance and Talent can now connect information that previously lived in separate systems. A business user can ask a question in one place instead of taking it to three teams. But that same reach creates ambiguity. Multiple tools expose different versions of the same entity, or claim to answer the same question. As the catalog grows, the assistant has more ways to choose incorrectly. Sometimes a data-owning team discovers that another team has built on its data only when an evaluation fails. How do you build a shared AI assistant that brings tools and data from across a company into one place? At Netflix, product teams increasingly build their own MCP integrations. Our challenge is making those capabilities work together so employees can get answers across teams through a single assistant. This talk covers the decisions and mechanisms behind that shift: connector certification, an internal benchmark built from real employee queries that we use to evaluate routing between overlapping tools, and how we classify actions to separate what an agent can do on its own from what needs a person first. We'll examine where our initial domain boundaries broke down, what required agreement between teams, and why better tool descriptions alone couldn't resolve the conflicts. We'll close on what we haven't solved: who owns the authoritative version of an entity, how to retire a connector other teams depend on, and when the benefits of a shared capability justify the coordination it requires.

My call: Part 2 of a session I'm already recommending you skip.

You will move from local coding in Google Antigravity to building a sandboxed remote agent on Gemini Managed Agents with reusable skills, vaulted credentials, and remote MCP. From there, you will connect the Gemini Live API to trigger remote tasks and steer your agents by voice.

My call: A product install walkthrough. Netflix and Monaco are the better use of this hour.

Gitar is Sonar’s AI code verification agent, complementing SonarQube with an understanding of each change’s context and intent. In this hands-on workshop, you’ll install Gitar as a GitHub App and use it across three pull request scenarios that show how verification goes beyond code review. Gitar verifies every change against your project's context and rules, catches problems, generates working fixes, and iterates until your CI pipeline passes. You'll leave knowing how to set up Gitar on your own repositories. You'll also see how it delivers ready-to-merge, green PRs with high signal and low noise, while your team keeps control.

My call: A personal agent built on one vendor's search API. You won't learn much you can use.

A personal agent gets asked everyday questions: where to eat near the office that's open late, whether it will rain on Saturday, how the Warriors did last night, what a stock did this week. Exa answers all of these through one search call. Places come back with addresses, hours and reviews; weather comes back as daily forecasts; sports come back as scores, standings and schedules. You don't need a separate API for each. In this session, Jakub Hojsan, forward deployed engineer at Exa you show you how to build a personal agent on Exa search that handles a day's worth of real requests, from finding dinner to planning around the weather. We will provide a repo to work out of as part of this workshop.

My call: Encoding per-rep expertise as agents on a custom platform, with an honest list of what's unsolved. A useful comparison for your vertical agent work.

Building a custom agents platform is one of the key pieces to unlocking AI for complex verticalized business workflows. Monte Carlo is the sales-specific system we've built to help scale Monaco's revenue: a platform where revenue teams encode their own playbooks as agents that run against everything we've ingested about their business, including pipeline, outbound, calls, and the CRM. Sales is a particularly complex vertical for the following reasons: no two revenue orgs look alike, the data is large and heterogeneous, and the expertise that matters lives in per-rep workflows nobody has written down. Over the last 2 years, we’ve built a custom harness and orchestration system to power our world-class GTM team. In this talk, I'll break down the components a verticalized agent platform needs in order to be fast and correct, including an execution plane, memory and curated implicit and explicit context, how expertise gets represented, and the evaluation loop, along with what is still unresolved.

Your whole team runs coding agents now, and they all land on one main. Continuous delivery wasn't built for that. This talk maps what breaks when a software factory goes multiplayer, and the patterns that fix it: one main for the agents, one board for the people.

My call: Real PRs, real failures and where agents overreached, shown live. Evidence you can quote, and rare at this kind of event.

PostHog Self-driving wrote 6,000+ pull requests in its first month that 600+ companies chose to merge. We showed the signal-to-PR pipeline at AI Engineer in London this April, and released it in late June. I'll show what happened since: where agents overreached, what we threw away, what's still science fiction, and the jump from fixing bugs to building features. The system now pitches features backed by your product data, builds them, and reviews them paranoidly, testing like a real customer. All open source. Real PRs, real reviews, real failures, shown live.

What is the future of post training in coding. What a modern research team looks like, and how Devin is part of it.

My call: An introductory build on one vendor's tool, aimed at people who haven't run an unattended agent yet.

Most people meet AI agents as a chat bot. In this hands-on workshop you will build one that works while you are not watching. Starting from an empty directory, you will install Kiro Crew, an open-source orchestration layer for coding agents, and ship a working app: an agent that reads your repository’s open issues, finds the duplicates, explains why it thinks so, and posts its findings on a schedule. Along the way you will give the agent persistent memory so it stops re-reading what it already knows, fan the work out across background subagents so a thousand issues do not take a thousand turns, and set the boundary that decides what it may and may not touch. Bring a laptop and a GitHub repository you care about. You will leave with the app running, and with a clear picture of what separates a demo from something you would actually let run unattended.

AI coding agents can turn a small feature request into a substantial code change and a pull request description that reads like a short novel. Yet the decisions, failed experiments, and human interventions that shaped the result remain buried in agent sessions. Reviewers reconstruct the history, question unsupported claims, and send the PR back for another costly round. Compressing the context into fewer tokens still leaves them searching for the missing connections. TraceToon uses that history to create better PR descriptions and comics grounded in the work behind the diff. With Relate, an embedded, in-memory graph database, TraceToon connects prompts and decisions to code changes and verification runs. It retrieves the evidence neighborhood around each change and turns it into a focused brief for drafting and review. The comic makes the wrong turns and corrections visible, while the technical description explains the behavior, rationale, and checks that support the result. Following a real pull request from Claude Code, Codex, or Antigravity sessions to a finished PR and comic, we’ll show how the graph keeps the story honest: connecting sessions to branch changes, distinguishing an earlier passing test from validation of the submitted code, and preserving uncertainty when evidence is incomplete. We’ll also show how connected evidence, a tuned brief, and cost-effective reviewers work together to improve PR quality and lower total drafting cost in our benchmarks. Attendees will leave with an open source workflow and practical patterns for using graph context and visual storytelling to make agent work easier to understand and review.

My call: Latency changes which products are possible, but it's a vendor talk. Fine if you're already in your seat.

Many AI product decisions are influenced by how long someone will wait for an answer. Do you give an agent another pass to check its answer, or make it respond faster? Can your voice assistant finish reasoning before the pause gets awkward? Faster inference gives developers the option to build smarter, more responsive user experiences. We’ll look at what faster inference lets you build, from more responsive voice applications to agents that can try, test, and update within a few seconds. We’ll discuss when speed is worth paying for, when other parts of your application become the bottleneck, and how to use higher responsiveness. Along the way, we’ll share how Gimlet combines GPUs and specialized accelerators to make inference faster, and what that means for the developers using that speed.

My call: What to delete from your Claude Code setup for the 5.5 models. You'll act on this one the same day.

The models have gotten really good, and most of what we've added to our Claude Code setups over the past year is now holding them back. In this talk I'll go through what Claude Code best practices look like for the Claude 5.5 models, what's still worth keeping, and what you no longer need to think about.

My call: An interesting signal about infrastructure companies training models. Not much to act on.

we trained some new system one models (clef, clairic). they fit perfectly within our decade-old primitives like workers, our edge latency hypothesis for workers ai, and our ambition to be the agent cloud.

My call: Hundreds of PRs a day nobody reads, and quality still rises. Your clients will ask how that can be true.

The Grok Bot team at SpaceXAI lands hundreds of PRs a day. Nobody reads them all, yet quality goes up anyway. In this talk, we'll find out how the Grok Bot team turns slop into gold at an incredible pace.

My call: The only session in this slot. The repo changes may be useful, though the 7,000 PR claim comes from a vendor.

More coding agents mostly means more tabs to watch. In the past year, one of our engineers went from about 20 merged pull requests a month to nearly 7,000. I'll show what we changed in our repos so an agent can take one small feature from prompt to merge on its own.

My call: Deleting tools until only Bash remains, with benchmarks to back it. It tests your assumptions about how much harness you need.

Alt Title: Why Models Are Superhuman with Bash (Where Humans Fail) --- I spent my day to day building a agents with custom tools for everything. Every few month I decide to delete everything and see what is not needed anymore. I stripped out every dedicated tool until only Bash remained. I cut the prompt to 300 tokens and made the execution loop asynchronous. Benchmark scores jumped. Experience went up. Rich Sutton called this the Bitter Lesson: building human heuristics into AI always loses to general methods backed by compute. Models are now superhuman with the bash. A frontier model can synthesize an ad-hoc 15-line pipeline combining Python AST parsing, ripgrep, git diffs, and subshells in 200ms to make progress on a users task, there is no need for dedicated edits, search or grep tools anymore. Learn how to delete your code.

My call: The outer loop of codebase quality is a good idea, but it runs against the Schmid talk.

Your coding agents run in loops: plan, implement, test, repeat. This inner loop focuses on completing a task, and it tends to get all the attention. But there’s an outer loop, too. Each agent builds on the codebase the last one left behind, inheriting its patterns, abstractions, and shortcuts. Those patterns can make the codebase easier to understand, maintain, and extend, or compound complexity and make future changes riskier. In this talk, I’ll show you how to build an outer loop that reinforces code quality and counteracts decay. Drawing on classic software design and refactoring techniques, we’ll equip an agent with skills to identify code smells, reason about coupling and module boundaries, and recommend refactors that make future changes easier. We’ll wire that analysis into the development lifecycle, running on PRs and across the codebase, weighing each recommendation’s benefit against its cost and risk. You’ll learn when to refactor, when to leave working code alone, and how to make refactoring part of your development workflow, so your coding agents leave behind codebases that are better, not just bigger.

My call: A reasonable survey of agent infrastructure, but less specific than Splunk's evidence.

The next generation of agents won't just answer questions. They'll work autonomously, collaborate with other agents, and learn from experience. As we move from interactive chatbots to persistent agent workforces, the infrastructure powering them needs to fundamentally evolve. In this talk, we'll explore the emerging architecture of agentic systems, from stateful sandboxes and persistent memory to agent communication and orchestration. We'll examine why today's agent platforms aren't built for this future, and what it will take to power a world where teams of agents can tackle complex, long-running work together.

My call: Green evals, failing users, and finding failures across sessions at millions a day. This goes straight into your verify layer.

Your evals are green, and users are still hitting failures. The evals aren't wrong. They test what you anticipated, and production at millions of sessions a day keeps inventing failures nobody wrote a test for, many visible only as a pattern across sessions. Detecting those failures continuously is a hard problem in its own right. Every agent fails differently, the failures that matter are rare, and a detector that flags everything is as useless as one that flags nothing. We've been working on this with customers running agents at scale and by running it on our own agents, learning which failures are worth surfacing and which are just noise. Along the way, three engineering problems kept coming up: Economics: you can't afford to run a reasoning model over every session, so what do you screen with, and what earns a closer look? Noise: a thousand flagged sessions are usually a handful of root causes. How do you collapse them and decide which to fix first? Trust: when a coding agent proposes the fix as a pull request, what has to be true before you merge it? How do you verify each fix and expand to cover every failure you find so it stays caught? You'll leave with the tradeoffs that matter when you move from grading agents to healing them, drawn from teams doing it today

My call: Layered verification is on theme, but it's Sonar's view of its own category.

Coding agents have made code cheap to write, and teams are shipping 10× more changes than they did two years ago. Human review was built for human speed, so the industry is moving from reviewed PRs to automated software factories. At Gitar and Sonar, we are learning how to build a safe software factory, with layers of verification across the system. We'll share what we've been learned so far, and where we think this trend is headed.

My call: Organizational context scattered across Slack, Drive and code is what your data engagements run into first.

The biggest bottleneck to building powerful internal agents is giving them the right organizational context. When agents can reliably find that context, they can answer questions, review code, investigate incidents, and automate workflows across the company. But company knowledge is scattered across Slack, email, Google Drive, code repositories, Linear, internal documentation, and multiple versions of the same information. Putting everything into the model’s context is expensive, risky, and often reduces answer quality. Connecting every source through separate MCP servers creates another bottleneck: the agent must make numerous tool calls while inheriting each service’s latency, rate limits, and uneven search quality. This talk shows how to separate retrieval from reasoning by giving internal agents a unified search layer for company knowledge. We’ll explore how a search subagent breaks down complex tasks, combines semantic and exact retrieval across systems, preserves source permissions, verifies freshness and versions, and returns compact, cited evidence to the acting agent. Through realistic internal workflows, we’ll demonstrate how better retrieval makes agents more accurate, traceable, and useful while reducing tool calls, latency, and cost.

My call: Why a single-person orchestrator broke and what team-owned context needed instead. That is your cooperation track with customer evidence.

Seven months ago, Factory introduced Missions, an orchestrator that ran worker agents through a full project with validation at every milestone. Real customer projects showed its limits. It only handled code, it was built for older models, and its context belonged to one person instead of the team. Luke Alvoeiro explains how Factory rebuilt it. A more token-efficient Droid made running many agents affordable. Environments let agents scale out inside a customer's own VPC. The new Missions gives each project a long-lived home with one orchestrator, shared context, and more autonomy as validation earns trust. When a project moves into maintenance, its mission graduates into a workstream: agents that turn bug reports, alerts, and ideas into validated, shipped software.

My call: It argues a factory shouldn't need forward-deployed engineers. That challenges your consulting model, so it may be worth hearing.

Working alone with Claude feels like a superpower. You open a session, give it the right context, and watch it ship. Scaling that to a whole engineering org is where it breaks. One agent with more context, more tools and more responsibility starts drifting, costs climb, and nobody can tell which part failed. So most "AI software factories" quietly ship with a team of forward-deployed engineers who wire up every customer by hand. We built Overcut so a factory doesn't need them. Instead of one big agent, it uses small agents with clear jobs: triage, root-cause analysis, implementation, code review and verification. Each one has its own context, model and memory, so it can be measured and improved on its own. Orchestration connects them. Workflows react to events in GitHub, Jira and Slack, run in parallel, and stop at human approval gates where it matters. Because every piece is a reusable building block, teams assemble their factory from ready-made parts instead of waiting for someone to build it for them. Then we'll prove it live. Starting from an empty project, we'll build the factory on stage: a production alert in Slack becomes a Jira ticket with a root-cause analysis, the ticket becomes a pull request, and the PR is reviewed and fixed until it's ready to merge. No FDEs, no hand-wiring. You'll leave with architecture patterns you can apply tomorrow , whether you're one developer or rolling out agents across a whole company.

My call: No abstract published, and Ivan Leo has real evidence at the same time.

Let's talk about the state of AI, how something like jev stayed under the radar for years, how we made it, and most importantly: what comes next! I've been told that this crowd is the absolute best of any conference for building the future, so let's jam about sci-fi and finally build some sick smart software.

My call: Fifty coding benchmarks audited trace by trace, with the failure modes that turned up. It's hard-won evidence for anyone who runs evals.

Coding agents are remarkably capable one minute and burning 50,000 tokens in a broken loop the next. Over the past few months at Google DeepMind, I've worked with Kaggle to audit over 50 coding benchmarks trace by trace and build a platform to evaluate frontier agents at scale. In this short 18-minute talk, we'll cover the weird failure modes we caught in the wild, the lessons we learned building air-gapped sandboxes, and how to take those same lessons to design better harnesses, verifiers, and coding environments for your own agents.

My call: Bounded decisions like routing and citation checks without a full LLM call. It could change how you cost and design the Workbench.

Not every step in an AI product needs a full generative LLM call. Many are bounded decisions, like understanding what a user is asking for, picking the best suggestion to show, checking whether an answer's citations hold up, routing to the right tool or model, or deciding if a request needs a guardrail. In this session, I'll walk through how Glean has been exploring Jev across these decisions, what we learned about where fast, confidence-scored decisions shine, and how we evaluate these models before they reach users.

My call: Application security checks are well covered elsewhere and aren't your track.

More security checks should mean more confidence, not more alerts to ignore. As AI accelerates code production, how do we add independent verification without turning development into an obstacle course? This session explores two dimensions of application security: using complementary analysis methods and placing checks at useful points throughout the software development lifecycle. We’ll examine where deterministic analysis provides repeatable checks, where probabilistic, AI-powered review can add context-sensitive reasoning, and why simply stacking tools can create more noise than assurance. We’ll start with a vendor-neutral framework for choosing checks, prioritizing findings, and keeping review actionable. Then, a live demo will bring three complementary approaches together: static application security testing (SAST), software composition analysis (SCA), and AI-powered analysis of logic-level vulnerabilities. You’ll leave with a practical way to evaluate layered verification: what each check contributes, where it belongs, and how to turn its findings into manageable work rather than another queue of alerts.

My call: An enterprise automation view of the same decision-model idea. Stay if the Glean talk lands.

Enterprise automation gets hard to maintain when a single agent is responsible for understanding a request, finding evidence, and deciding what happens next. Drawing on two decades of experience automating business processes, we'll show how to break that work into steps a team can understand, test, and change. We'll explore when a focused judgment is enough, when a generative model should investigate, and when a person should step in. We'll share what we learned about accuracy, speed, and cost so you can make those choices in your own workflows.

My call: How oracles let agents build real database infrastructure. A great verification story, and you use Neon, but the Jev series is closer to your work.

Live SQL is the holy grail of realtime. Subscribe to any SQL query, with joins, aggregates and ordering, and the result stays live as your data changes. It’s easy to describe but very hard to build. At Electric, we spent years chasing it. Then we joined Neon and built it in weeks with coding agents, inside Postgres. Live queries are database infrastructure. This isn’t code you hand to an agent and hope for the best. So we used Postgres’s own query engine as an oracle. Once the agents had the ability to verify their own work, they could go super fast and burn down through the featue requirements. In this talk, I’ll cover what we built, how we built it and how oracles let us have both truth and dare: to get it right and ship fast with agents.

My call: Their model grader passed work that never happened. If your evals use LLM judges, you need to hear this.

Every step an agent takes in ZoomInfo's Agent Teams is graded by another model. Then we ran Jev beside it and found the grader was passing work that never happened. This talk is about what we found, what we replaced, and why "did the agent do a good job?" is the wrong question to ask a model.

My call: No abstract published, and CVE remediation is a narrow product demo.

My call: No abstract published. Workday is the kind of enterprise your clients look like, so it's worth a chance if you're nearby.

Search guesses your next word. Workday's Sana guesses your next task. Millions of people use Workday to check their pay, book time off and find their team, and most of those requests are too simple to wait on a full LLM turn. I'll show how we use Jev as a System One model from the UI to the DB: picking the right action card while you type, and running inside DuckDB as a SQL filter.

My call: The Bun port as a study of why verification loops matter. Good idea, but it's from a vendor selling cloud dev environments.

Why is it that Anthropic can port Bun from Zig to Rust in 11 days, while most teams still struggle to make sweeping changes to production software? Bun is complex, but it turns out its verification loop is actually quite clear: there's a well-defined TypeScript spec, and a huge battery of tests the agent can iterate against. This talk will explore techniques to build agent-native dev environments in the cloud that allow for these kinds of tight verification loops for software that's traditionally much harder to verify: tax accounting, vertical AI agents, robotics control systems, etc. We'll discuss how to manage stateful dependencies (databases, queues, caches), third-party services, and seed data so you can focus on architecture & product while your agents handle implementation & testing in the cloud.

My call: Forkable computers and durable agent communication, from a team with real scale. Stay in your seat if you came early for Ramp.

Models keep getting better and the systems we build around them need to keep up. This talk goes inside Lovable’s engineering: forkable computers that give agents room to experiment, persistent histories that let them continue longer work, and durable communication that lets them coordinate. We’ll explore what it takes to give agents more independence, and how these foundations could help them build, ship, learn from feedback, and keep improving a product.

My call: How an in-house agent reshaped engineering culture at Ramp. That's the Org Age thesis as a case study.

Ramp built its own coding agent, Inspect, which writes ~75% of merged PRs. At the start of 2026, the technology was the novel part, but today, it's commonplace. In this talk, Zach will talk about how Inspect has evolved this year, and re-shaped the culture of engineering at Ramp around agent-driven development.

My call: No abstract published, but it's Steve Yegge, and you already use Beads. Expect ideas that spark argument.

My call: No abstract published, but Simon Willison is reliably careful and specific about what is actually true right now.

2026 has been a wild year for LLMs. Simon will recap everything that's happened since last November's coding agent inflection point: January's OpenClaw craze, the rise and fall of tokenmaxxing, US export controls on frontier AI, open weights that can compete with the best, cyberattacks by rogue agents, Fable-class models, and the recent wave of 3D modeling and vibe-coded games. And the year's not over yet!

My call: No abstract published. Jason Liu is a clear teacher on structured output and evals, and now works on developer experience at OpenAI.

My call: No abstract published, but Armin Ronacher tends to report candidly from hands-on work.

On the way to the software factory, let's build an atelier first. Drawing on the last year of working with and on Pi, this talk argues for using our new tools to craft better software, not just more of it.

My call: Factories that improve with every run and where human judgment stays. Direct input to your software track.

Warp founder and CEO Zach Lloyd explores the rise of software factories: systems that coordinate AI agents across the entire development lifecycle, from triage and specification to implementation, review, and monitoring. He’ll explain how engineering teams can build factories that improve with every run, where human judgment remains essential, and why the next frontier of software engineering may be less about writing code and more about engineering the systems that build it.

My call: No abstract published, and ArtCraft is further from your work. A good moment for coffee.

From open-source alternatives to Adobe Photoshop and Microsoft Office to the SaaSpocalypse, it’s clear that software’s moats aren’t where they used to be. Take a look inside ArtCraft, a project aiming to become the Wikipedia of open source by recreating every category of software in modern, high-quality Rust. We’re building open-source applications and infrastructure to make every platform open - tearing down moats by turning platforms into protocols. We’ll tour fully agentic software factories and the engineering behind them - pushing the limits of Git and GitHub, tackling Rust build and CI bottlenecks, automating triage and testing, and building high-quality shared libraries and UI/UX components for the interfaces and user experiences of today and tomorrow, and beyond.

My call: No abstract published. Cognition has argued publicly about how multi-agent systems should work, so hear this against your standards approach.

Skip the basics and go straight to the frontier. Walden Yan, cofounder and CPO of Cognition, dives into the most advanced ways teams are using AI today, with bleeding-edge techniques from real company use cases.

My call: Context that lived in a Slack incident thread is a good framing for the meaning layer. Close second to Walden Yan.

Our goal is to drive business outcomes and increase shareholder value. We do it through code. Increasingly agents are writing more, if not all, of our code and running more of the SDLC through software factories. Unfortunately they keep getting things wrong, are misaligned, or hallucinate facts leading to wasted human and agent cycles. It doesn't have to be this way. By connecting agents to the reality of your business through a context engine you can improve every step of your factory. This drastically increases the quality of agent outputs which compounds into driving the business outcomes and value we dream of. In this talk I'll show: how to accomplish this, why context != context, and 3 lessons we learned delivering a context engine at scale in case you want to build your own. Whether you believe one agent can run it all or a bespoke software factory is the right approach, you'll discover that ambient context is what your system is missing.

My call: A clever data set on what agents search for. Interesting, but Auth0 is more useful to you.

An agent only searches when it doesn’t know something. In other words, every search is a confession, and Exa has been collecting them from thousands of agents for two years. Read together, those searches form a map of how AI agents like to work, and where their knowledge ends. There’s clear evidence of growing expertise. Coding agents used to search for examples and tutorials, now they go straight to the source, searching for code repos, issues and API references. Searches for mature frameworks like React, Next.js, and the rest of the “vibe code stack” are fading, not because they’re falling out of use, but because models already know them cold. Instead agents are searching for their own tools: MCPs, skills, agent instruction files and the latest models. But even as their knowledge and capability grows, agents still need to search. Models still take months to train, but the coding frontier now turns over every quarter, and AI is speeding that up. This knowledge cutoff won’t be fixed by the next big model release. In this keynote, Jeff Pinner, CTO of Exa, shares what we’ve learned from agents telling us what they don’t know, what it means for anyone who maintains a library, ships an agent or relies on one, and why search is an Agent’s best gateway to the present.

My call: Matching human-in-the-loop patterns to the level of consequence. That's the design behind your Workbench inbox.

AI agents are getting good at taking action. The hard part isn't making them capable, it's knowing when to make them stop. In this talk we'll walk through the full spectrum of human-in-the-loop patterns, from lightweight inline confirmations to out-of-band permission gates to handing your agent a wallet with real money in it and more. Each pattern fits a different level of consequence, and knowing which to reach for is what separates demo agents from production ones. We'll cover the honest tradeoffs of latency, user experience, and trust so you can make the right call for your specific use case. The entire talk is built around various live demos that escalate in stakes with every step. You'll leave with a mental model and working reference architecture you can apply the same day.

My call: Team-of-one habits on a vendor tool. You already work this way.

Coding has gotten cheaper, but shipping hasn't. See how one engineer built a build, review, and ship loop with Kiro Crew, and learn the traps that cost hours along the way (reviews that never end, agent loops that balloon a ten-line fix into a whole subsystem, saying yes to everything because code felt free). You'll leave with five concrete habits to try Monday morning with the tools you already use.

My call: Agents that explore across services and know when they have enough evidence. That's your First Answer rung in practice.

Abstract: Give an agent a pile of APIs. Can it figure out what to query, connect the dots, and check its own answers? I’ll share practical lessons on building agents that explore data across services—from discovering tools and navigating schemas to following leads and knowing when they have enough evidence.

My call: No abstract published. Lance Martin is known for clear thinking on context engineering, now from inside Anthropic.

In this talk, we explore Claude’s frontier capabilities in memory and multi-agent coordination.

My call: Enterprise-scale review from Atlassian, and a good alternative if Lance Martin's room is packed.

While authoring code has become virtually instantaneous, reviewing and verifying that code in an enterprise environment remains constrained by human cognitive capacity. At scale, this becomes a painful bottleneck: pull request volume and size are growing rapidly, review latency is increasing, and 10,000-line diffs can all too easily burn through finite reserves of human attention. How do engineering organizations scale trust and quality at the speed of AI generation? I won’t pretend we’ve fully slain this dragon, but in this session I’ll walk through a few different approaches we’re taking and what we’ve learned within Atlassian: Inner Loop: Building confidence through automated local AI review and skills for catching anti-patterns and contract violations before code ever reaches a human teammate. Outer Loop: How tools like Taro spin up live environments, simulate user interactions, and provide tangible evidence (narrated videos) directly to reviewers. A New Lens on Code: Aggregating quality signals like CI, agentic evaluations, and risk scoring to allow reviewers to “zoom out” and reason about the value and implications of a change without having to read the diff line-by-line. Rethinking the Unit of Change: Why the traditional single-ticket micro-PR is an artifact of human typing limits, and how we can shift human expertise to where it matters most. Attendees will leave with concrete architectural patterns, lessons learned from real-world rollouts, and a blueprint for evolving their team’s code review practices for the AI era.

My call: No abstract published, but it's the longest slot of the day, and the Bun port already appears in another speaker's abstract as the example to learn from.

My call: Turning agent use into what it returned is your ROI argument. A very close second to Sumner, so pick this if clients matter more than craft that day.

Most companies have turned coding agents on. Few can say what those agents do or what they return. At Cognition, Devin wrote 92% of merged PRs in September, and 9 out of 10 Devin sessions start without a human. Theodor Marcu shows how we got there: cloud agents working in parallel, automations that run every night, and how engineering and research use Devin to autonomously drive feature development. He then turns that into a playbook for your teams: govern what agents can reach, route work across models to cut cost, and follow every session to a merged PR so ROI is measured instead of guessed.

My call: A vendor benchmark, and it conflicts with the longest talk of the day.

Decision models only read. They never generate a token, which is why they cost roughly 240x less per token read than a frontier LLM — and why they are only as good as the state you hand them. For most judgments worth making, that state lives on the live web, not in your database. This talk re-costs the stack with measured numbers. On PWS-Decisions, our open 300-question benchmark, the question is 104 tokens and the evidence needed to answer it is 4,777. Two years ago the model was 86% of the bill for a grounded answer; today it is 17%. Intelligence stopped being the bottleneck. Context became it. We will cover what that inversion changes architecturally, a live demo that grounds 18 typed questions against 4,270 businesses in a single call, and the entity-resolution failure that quietly breaks grounded decisions in production. You will leave able to run the benchmark against your own model.

My call: No abstract published. Antigravity is worth knowing, but a good slot for the expo if nothing pulls you.

If agents can build anything, what's left? Building Antigravity, we work at the frontier of AI, ship products at the scale of Google, and iterate quickly to harness new model capabilities. This talk dives into that feedback loop, and what that taught us about building with agents while keeping human judgement at the center.

My call: Real traces of where tokens go. Useful for your cost layer, but a vendor's solution comes with it.

Every agent that searches the web pays twice: once for the search call, and again for the tokens that search puts into the model's context. The answer is usually a few sentences. The agent pays for the whole page, and in a multi-step loop it pays for it again on every turn. We'll show real production traces of where the tokens go and why retrieval, not generation, is the biggest line on most agent bills. Then we'll show what we changed: return the passages a query needs instead of whole pages, tune extraction to the question, and cap how much context the agent can take. We tested this across 12 frontier models and 11,000 blind-graded answers. Token spend fell by more than 90% while accuracy went up. You get a metric (cost per correct answer, not cost per request), an open calculator to run the numbers on your own traffic, and a five-point checklist for finding token waste in your pipeline.

My call: Your clients are all brownfield. This argues legacy systems are actually the best place for factories, which is a pitch you can use.

Brownfield applications are clearly ideal for Software Factories! Brownfield applications provide all the specification and telemetry you need to build validation harnesses and loops. Make a lump sum payment on your technical debt, reduce costs, increase performance, and purge vulnerabilities once and for all. Rewrite that boat anchor to Rust, Elixir or BF today!

My call: Another Kiro Crew session. Brownfield Factories fits your clients far better.

My coding agents are fast, but speed isn't the whole story. The real question is where they run: the CLI, the IDE, or something else entirely? In this session, I'll break down which tool fits which job and why that choice makes or breaks your workflow. I'll show you how I organize skills and custom agents so they're reusable instead of one-off, then close with a demo of a persistent agent setup in Kiro Crew — one that keeps grinding away long after I've logged off. Walk away knowing how to match the right agent to the right environment and build setups that work while you sleep.

My call: How long-horizon coding tasks are trained for is interesting context, but you won't apply it directly.

Real software engineering tasks are not asking a model to write a function, but long tasks (o(hours) reading unfamiliar code, running tools, recovering from wrong turns, and knowing when the job is actually done. In this keynote, Melvin Johnson (VP, Google DeepMind) covers how we post-trained for long-horizon agentic coding: - Hard tasks. Popular benchmarks saturate, so we built internal realistic, multi-step software tasks. - Graders that can't be gamed. When agents learn to satisfy unit tests without solving the problem, you need graders that check the work the way a reviewer would. - Model behavior. An agent that says "fixed it" when it didn't is worse than no agent. We reward models for reporting accurately what they did and didn't do. - Efficiency over long horizons. Finishing more of the task with fewer tokens and stable behavior across very long contexts. - Shipping weekly. Modular improvements and dogfooding with Google engineers let us release in weeks instead of quarters.

My call: No abstract published, but Quinn Slack has strong, tested opinions about where coding agents are going.

You might know Amp as one of the agent products, but we're really a 21-cofounder team figuring out how to build our entire company around the agent. We don't have traditional roles, everyone pushes to main, we have one meeting per week, we're very profitable and above $100M ARR, and we haven't hired anyone (yet). See how we use the agent to do everything, with high quality, and what relics of the old tech company world we ditched.

My call: Principles across many factories, with a case for open, composable primitives. That sits directly beside your standards argument.

Every AI lab is building full stack cloud agents. Every enterprise is building their own software factory. We've worked with a lot of teams adopting all flavors in every combination. In this talk we'll distill out the core principles and design patterns we've seen across factories, and make a case for why the AI-native forge will be composable and built on open primitives.

My call: No abstract published. This talk closes the summit, and Thariq Shihipar's Claude Code work is worth hearing out.

To close Code Summit 2026, swyx invites everyone to celebrate together: three days of talks, workshops, hallway conversations and the AI engineers who made them happen. Stay for the finale and celebrate with us.