<?xml version='1.0' encoding='utf-8' ?>
<!-- Made with love by pretalx v2026.1.2. -->
<schedule>
    <generator name="pretalx" version="2026.1.2" />
    <version>0.2</version>
    <conference>
        <title>AsyncAPI Conference: London 2026</title>
        <acronym>london-2026</acronym>
        <start>2026-09-30</start>
        <end>2026-10-01</end>
        <days>2</days>
        <timeslot_duration>00:05</timeslot_duration>
        <base_url>https://cfp.asyncapi.com</base_url>
        <logo>https://cfp.asyncapi.com/media/london-2026/img/logo_EAbH5m7.webp</logo>
        <time_zone_name>UTC</time_zone_name>
        
        
    </conference>
    <day index='1' date='2026-09-30' start='2026-09-30T04:00:00+00:00' end='2026-10-01T03:59:00+00:00'>
        
    </day>
    <day index='2' date='2026-10-01' start='2026-10-01T04:00:00+00:00' end='2026-10-02T03:59:00+00:00'>
        <room name='AsyncAPI Track' guid='4cad8574-32c5-5504-af12-3af15a43f65b'>
            <event guid='167bc88c-4a50-5ed9-90f6-f9449fd1622b' id='60' code='TAQDCV'>
                <room>AsyncAPI Track</room>
                <title>The Storyteller Agent: Beyond Code, Into Context</title>
                <subtitle></subtitle>
                <type>Short Talk</type>
                <date>2026-10-01T13:00:00+00:00</date>
                <start>13:00</start>
                <duration>00:25</duration>
                <abstract>We&apos;re entering an agentic era where AI agents can generate code, review pull requests, and automate development tasks. But to become trusted collaborators, they need more than source code&#8212;they need context.
In this talk, I&apos;ll explore how AsyncAPI can serve as the semantic foundation for building AI agents that understand an event-driven platform, not just its APIs. By combining AsyncAPI specifications with platform metadata, agents can reason about services, events, schemas, dependencies, ownership, and business capabilities as a connected story rather than isolated technical artifacts.
Instead of answering only developer-focused questions such as &quot;Which service publishes this event?&quot;, these agents can also explain why an event exists, how it supports a business process, which teams depend on it, and what the downstream impact of a change might be. This shared understanding helps bridge the gap between platform engineering and product teams, enabling more informed technical and business decisions.
I&apos;ll present the architecture behind a Storyteller Agent, discuss the design choices involved in building a semantic knowledge layer on top of AsyncAPI, and illustrate how these concepts can be applied in practice using examples from an event-driven platform.
Attendees will leave with practical ideas for transforming AsyncAPI from documentation into a knowledge layer that enables the next generation of intelligent platform agents.</abstract>
                <slug>london-2026-60-the-storyteller-agent-beyond-code-into-context</slug>
                <track></track>
                
                <persons>
                    <person id='56'>Eduardo Maldonado Fonseca Silva</person>
                </persons>
                <language>en</language>
                
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.asyncapi.com/london-2026/talk/TAQDCV/</url>
                <feedback_url>https://cfp.asyncapi.com/london-2026/talk/TAQDCV/feedback/</feedback_url>
            </event>
            <event guid='11c23da8-83bc-5cc0-be75-c8f770ca8dbd' id='41' code='YZJ3US'>
                <room>AsyncAPI Track</room>
                <title>Designing Governance for Sustainable Open Standards</title>
                <subtitle></subtitle>
                <type>Short Talk</type>
                <date>2026-10-01T13:30:00+00:00</date>
                <start>13:30</start>
                <duration>00:25</duration>
                <abstract>Successful open source standards require more than strong technical specifications. While specifications define how systems communicate, governance determines how communities collaborate, make decisions, and evolve.

As standards mature, governance challenges can become a greater risk than technical ones: decision-making becomes concentrated among a few people, ownership becomes unclear, working groups lose momentum, and maintainers become overwhelmed. Left unchecked, these patterns can limit participation, slow innovation, and threaten long-term sustainability.


This talk introduces the five pillars of sustainable governance: transparency, shared ownership, succession, participation, and accountability. Drawing on real-world examples and lessons from the AsyncAPI community, we&#8217;ll explore common governance anti-patterns and practical approaches for building resilient, community-driven projects.

Whether you&#8217;re new to AsyncAPI, an existing contributor, a maintainer, or someone building another open-source standard community, you&#8217;ll learn practical ways to identify governance risks, strengthen contributor pathways, distribute responsibility, and create sustainable leadership models.

The goal is not simply to define governance structures, but actionable strategies for identifying governance risks, strengthening contributor pathways, distributing responsibility, and creating leadership models that allow open standards communities to thrive beyond individual leaders.</abstract>
                <slug>london-2026-41-designing-governance-for-sustainable-open-standards</slug>
                <track></track>
                
                <persons>
                    <person id='4'>Thulisile Sibanda</person>
                </persons>
                <language>en</language>
                
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.asyncapi.com/london-2026/talk/YZJ3US/</url>
                <feedback_url>https://cfp.asyncapi.com/london-2026/talk/YZJ3US/feedback/</feedback_url>
            </event>
            <event guid='e881d28d-bcc5-5d2d-9cf1-266171f70f8a' id='40' code='U3AQ9W'>
                <room>AsyncAPI Track</room>
                <title>Passports for Payloads: Standardising B2B Event Pattern with AsyncAPI</title>
                <subtitle></subtitle>
                <type>Short Talk</type>
                <date>2026-10-01T14:00:00+00:00</date>
                <start>14:00</start>
                <duration>00:25</duration>
                <abstract>Within modern enterprises, file-based batch processing has largely been replaced by Event-Driven Architecture (EDA), enabling systems to exchange information in near real time through event streams. However, this transformation has stopped at organisational boundaries. Business-to-business (B2B) asynchronous data exchange continues to rely on decades-old integration patterns, with SFTP-based file transfers, nightly batch jobs, and Managed File Transfer (MFT) platforms remaining the dominant mechanisms for sharing data between enterprises.

Although these methods reliably facilitated bulk data movement in the past, they struggle to meet today&apos;s integration requirements. Their batch-oriented nature introduces inherent latency, delays the propagation of business events, and concentrates processing into resource-intensive compute bursts. While some enterprises have adopted pull-based bulk REST APIs, this approach introduces its own set of challenges, including constant polling overhead, complex pagination, and increased system load. The optimal approach to B2B data sharing involves extending Event-Driven Architecture beyond organisational boundaries. This is, admittedly, an unconventional  proposition: most enterprises deliberately avoid exposing internal brokers externally, even behind a gateway, given the risks of blast radius, backpressure propagation, and operational coupling to an external party&apos;s failure modes. This talk argues that with the right mediation layer and contract-first governance enabled by AsyncAPI , EDA can be extended across trust boundaries without inheriting these risks.

This Tech talk will provide a practical framework for tackling this problem with a focus on:

&#8226;	**Transition Challenges**: Why moving to EDA is critical for B2B integrations, along with the infrastructure, security and governance challenges that come with it?
&#8226;	**Overcoming the Challenges**: Practical approaches and strategies for addressing the infrastructure, security, governance, and operational challenges involved in transitioning to EDA for B2B integrations.
&#8226;	**Reference Architecture**: How to use Proxies and Protocol Mediation gateways to safely ingest external payloads (Kafka , WebSockets , AMQP) into internal brokers while protecting network perimeters?
&#8226;	**AsyncAPI Governance**: How AsyncAPI can serve as the &quot;passport&quot; (contract) for enforcing strict schema validation, version control, and channel boundaries?</abstract>
                <slug>london-2026-40-passports-for-payloads-standardising-b2b-event-pattern-with-asyncapi</slug>
                <track></track>
                
                <persons>
                    <person id='39'>Aravind Viswanathan</person>
                </persons>
                <language>en</language>
                
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.asyncapi.com/london-2026/talk/U3AQ9W/</url>
                <feedback_url>https://cfp.asyncapi.com/london-2026/talk/U3AQ9W/feedback/</feedback_url>
            </event>
            <event guid='51621169-d0e2-5853-9018-18e32318ec38' id='35' code='NE79WU'>
                <room>AsyncAPI Track</room>
                <title>Discover. Authorize. Observe. Building Agent-Ready Event Streams</title>
                <subtitle></subtitle>
                <type>Short Talk</type>
                <date>2026-10-01T15:00:00+00:00</date>
                <start>15:00</start>
                <duration>00:25</duration>
                <abstract>Picture an AI agent subscribed to a real-time event stream, calling a large language model on every event that arrives. Over a weekend, across hundreds of thousands of events, it quietly burns through hundreds of dollars. Nothing is technically wrong: every event is valid, the agent is authenticated, and no alert fires, because every existing check was designed to monitor infrastructure, not how an autonomous agent consumes a stream.

As autonomous agents become primary API consumers, event streams are where this shift bites hardest. Developers build agent systems on raw event streams and they work. But in production, three things break. Agents can&apos;t discover what channels exist without hardcoded configurations. Any agent can subscribe to any topic because there&apos;s no channel-level access boundary. And there&apos;s no visibility into what each agent is consuming or what it costs when a high-throughput stream triggers LLM calls on every event.

This talk proposes three questions that define an agent-ready event platform: Is it discoverable? Is access scoped? Is consumption observable? This talk uses a primary scenario of agents consuming a WebSocket stream backed by Kafka to show what AsyncAPI v3 provides: describable channels, schema contracts, and security documentation that your gateway layer can enforce. We walk through a real spec snippet. We cover the governance patterns that address the failure modes above, what exists in tooling today, and what still requires custom implementation. And we look at where AsyncAPI fits alongside MCP and OpenAPI in the emerging agent stack.</abstract>
                <slug>london-2026-35-discover-authorize-observe-building-agent-ready-event-streams</slug>
                <track></track>
                
                <persons>
                    <person id='34'>Dakshitha Ratnayake</person>
                </persons>
                <language>en</language>
                
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.asyncapi.com/london-2026/talk/NE79WU/</url>
                <feedback_url>https://cfp.asyncapi.com/london-2026/talk/NE79WU/feedback/</feedback_url>
            </event>
            <event guid='01a9b07e-b1cd-5dd3-bc02-cdd740d2164c' id='8' code='XXFXN3'>
                <room>AsyncAPI Track</room>
                <title>From Generated Specs to Published Contracts: Our AsyncAPI Journey</title>
                <subtitle></subtitle>
                <type>Short Talk</type>
                <date>2026-10-01T15:30:00+00:00</date>
                <start>15:30</start>
                <duration>00:25</duration>
                <abstract>When we first started documenting domain events, we used OpenAPI because it was already part of our engineering practices. It worked well enough to get us started, but as our event-driven platform grew, we found ourselves forcing a request/response specification to describe asynchronous messaging.

We adopted AsyncAPI to publish event contracts across our backend platform, where events are consumed by game teams, Data Science, QA, and other backend services. Using Springwolf, we automatically generate AsyncAPI specifications from our Spring Boot applications. However, we quickly discovered that generated specifications were not the same as published contracts. They exposed Java implementation details, framework-specific wrappers, and internal metadata instead of the domain language our consumers expected.

In this session, I&apos;ll share how we transformed generated specifications into published contracts. We&apos;ll cover the customisations we made to produce consumer-friendly documentation, how we integrated AsyncAPI generation into our CI pipeline, and how every contract change is automatically surfaced through a pull request for architectural review before becoming the published contract. This governance process helps us evolve event contracts safely across independently deployed services with multiple downstream consumers.

I&apos;ll also discuss the limitations we encountered. Producer discovery still relies on manual annotations, which means some producers might be missed if they are not properly annotated, and we intentionally focused on documenting the business contract rather than every messaging platform capability.

This is not a deep dive into the AsyncAPI specification. It&apos;s a practical engineering story about introducing AsyncAPI into an existing platform, the trade-offs we made, the mistakes we learned from, and how generated specifications became trusted contracts shared across teams.

Audience Takeaways
Recognise when OpenAPI is no longer the right fit for event-driven APIs.
Learn how to customise generated AsyncAPI specifications to communicate in domain language rather than implementation details.
See a practical CI-based governance approach for reviewing contract changes before publication.
Understand the difference between generated documentation and a published contract.
Learn where automation helps&#8212;and where manual governance is still required</abstract>
                <slug>london-2026-8-from-generated-specs-to-published-contracts-our-asyncapi-journey</slug>
                <track></track>
                
                <persons>
                    <person id='6'>Velmurugan Manickavelu</person>
                </persons>
                <language>en</language>
                
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.asyncapi.com/london-2026/talk/XXFXN3/</url>
                <feedback_url>https://cfp.asyncapi.com/london-2026/talk/XXFXN3/feedback/</feedback_url>
            </event>
            
        </room>
        
    </day>
    
</schedule>
