You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
<!--
Thanks for making a pull request!
Before submitting, please read our contributing guidelines:
https://github.com/graphql/graphql.github.io/blob/source/CONTRIBUTING.md
Have any questions?
Feel free to ask in this PR or you can also find us on the #website
channel on the GraphQL Slack (invite link available in CONTRIBUTING.md)
-->
Closes #<issue number>
## Description
<!-- Write a brief description of the changes introduced by this PR -->
"<p>In 2015, we promised GraphQL would be “easy to learn and use.” Ten years, and hundreds of billions of daily API calls later, we’ve learned that not all our hopes and promises turned out to be true.</p>\n",
"<p>After eleven years as an open source technology, GraphQL has never had a more favorable learning curve. Clearer mental models, better educational materials, and a deeper collective understanding of best practices have transformed the “wild west” of 2015 to a much more manageable landscape today.</p>\n<p>You and your team are unique, so rather than a one-size-fits-all blueprint, this talk presents a practical guide to teaching yourself GraphQL in 2026. We’ll examine how beginners typically build their first mental model of GraphQL, the most common misconceptions, and the key design questions they encounter early.</p>\n<p>Special attention will be paid to different modalities: schema-first vs. code-first, schema design principles, common pitfalls when considering enums, the proper use of fragments, and security and performance by default. Attendees will leave with a conceptual roadmap for self-study, a recipe book for context engineering in their agent, and an understanding of the major decision points along the journey ahead.</p>\n",
title: "GraphQL as the Execution Layer for AI Agents",
102
-
start: "2026-05-13T15:10:00-04:00",
103
-
end: "2026-05-13T15:35:00-04:00",
102
+
start: "2026-05-14T15:10:00-04:00",
103
+
end: "2026-05-14T15:35:00-04:00",
104
104
tags: ["AI Agents","Federation","Public Sector"],
105
105
description:
106
106
"<p>Your next million API consumers won’t be developers. They’ll be AI agents. And they don’t read documentation, parse hypermedia links, or guess which of your 200 REST endpoints returns the data they need.</p>\n<p>This talk examines what happens when autonomous AI agents become the primary consumers of your API layer. Drawing on real data from Singapore’s public government APIs, I’ll show how REST responses waste 30–60% of an agent’s token budget on structural overhead, and how a typed, self-describing schema changes the equation entirely.</p>\n<p>We’ll walk through the three properties that make an API truly agent-native: discoverability, precision, and composability. We’ll look at what it would take to unify API estates like Singapore’s 3,000+ government APIs across 75+ agencies into a single, self-describing surface. A pattern Gartner expects 30% of enterprises to adopt by 2027.</p>\n<p>You’ll leave with a framework for what makes an API truly agent-native, why GraphQL’s type system and federation model get you there, and how to start without a rewrite.</p>\n",
"<p>Coding agents are reshaping how we build software. Implementing features, refactoring systems, and shipping changes at a pace unthinkable 6 months ago. But to be successful with agents you need the right feedback loop. One that guides your agent to success, not into the spiral of death.</p>\n<p>Ask Claude to add a review system to your product API. Without knowing what’s in use, it might reshape your types, move fields, and break your deployed clients because it is missing a crucial feedback loop of what’s in use in your clients.</p>\n<p>GraphQL changes this. Every client operation explicitly declares the exact fields and types it needs. That gives you something rare: field-level usage data across your entire consumer base. Not endpoint hits, but actual demand, broken down to the individual field.</p>\n<p>When coding agents can access this data, they stop guessing. Evolve your schema grounded in reality, not assumptions.</p>\n<p>This talk shows how GraphQL’s inherent usage visibility and the rise of coding agents create a feedback loop that didn’t exist before. And why it matters for anyone building APIs that need to evolve fast.</p>\n",
"Voice AI for the Patients AI Left Behind: How GraphQL Federation Became Our Trust Layer",
160
-
start: "2026-05-13T16:30:00-04:00",
161
-
end: "2026-05-13T16:55:00-04:00",
160
+
start: "2026-05-14T16:30:00-04:00",
161
+
end: "2026-05-14T16:55:00-04:00",
162
162
tags: ["GraphQL"],
163
163
description:
164
164
"<p>Healthcare AI has a coverage problem. The 78-year-old Spanish-speaking grandmother with early dementia isn't downloading an app, typing into a chatbot, or navigating a patient portal. But she can answer a phone call, and she can have a conversation, if the system on the other end knows how to have one with her.</p>\n<p>At ClinicaMind, we build voice agents for exactly this population: chronic care patients across neurology, cardiology, and primary care, many of them bilingual, cognitively declining, or simply outside the demographic that healthcare software was designed for. To serve them, we needed real-time conversational AI that could resolve a patient's full longitudinal context: clinical history, cultural profile, consent state, caregiver relationships, prior call transcripts. All in under 30 milliseconds, across a federated backend, while staying HIPAA-compliant and auditable down to the field.</p>\n<p>Apollo Federation became the answer. Not as an API style, but as the architectural commitment that made the rest possible. This deep dive walks through how we modeled the Trust Engine, the five-layer system that sits between the LLM and the patient, as a set of federated subgraphs aligned to bounded contexts: Identity & Consent, Cultural & Social Fabric, Clinical Safety, Trust State, and Escalation & Handoff. We'll cover the practical decisions: why @key entity resolution became our PHI boundary, how DataLoader batching keeps voice-agent context retrieval under our latency budget, where we use domain events instead of cross-subgraph reads, and the pitfalls we hit reusing fragments across patient-facing voice flows and clinician-facing dashboards.\nYou'll leave with a concrete reference architecture for using GraphQL Federation as a trust and safety substrate, not just a data layer, in domains where the cost of getting it wrong is measured in human lives, not failed requests.</p>",
"<p>In my apidays Paris session last year, I introduced a “shift left” pattern for accessibility: attach accessibility metadata to GraphQL fields using lightweight directives, expose it through code generation, and let Android (Jetpack Compose), iOS (SwiftUI), and web clients map it into native accessibility semantics for consistent defaults.</p>\n<p>This follow-up, Part 2, focuses on the next problem teams hit in production: keeping that metadata accurate as the schema changes. We’ll walk through a practical, low-friction approach adding CI-friendly validation that catches common contract regressions before changes ship: missing required metadata, invalid values, and template drift.</p>\n<p>This approach standardizes the repeatable, high-leverage semantics (labels, roles, states, templated summaries) so clients can focus on the platform-specific work that truly belongs in the UI (complex interactions, focus order, and behavior). You’ll leave with schema examples you can adapt, a realistic enforcement blueprint that fits into pull requests and CI, and rollout patterns for introducing rules gradually without breaking existing clients.</p>\n",
0 commit comments