AI in Production 2027 Call for Speakers: What Makes a Strong Talk

The call for speakers for AI in Production 2027 is open until 29 January 2027. The conference returns to The Catalyst in Newcastle on 10 and 11 June, with workshops on the Thursday and a full day of talks and lightning talks on the Friday.

When we announced the 2027 conference, the question we heard most was some version of “would my talk fit?” This post is our answer. It sets out what the programme committee looks for, what makes an abstract easy to say yes to, and what we are less likely to pick.

The short version

We want talks about AI and machine learning systems that exist and get used by someone other than the person who built them. Tell us what you built, what happened once it met its users and their data, and what you would do differently.

The test from the announcement still applies. Swap “AI” for any other kind of software system. If the talk still holds up, it is probably not for us. If it falls apart because the AI-specific parts are central to the story, that is what we are looking for.

Talks we want to hear

These are the areas we expect most of the programme to come from. They are a guide, not a checklist, and plenty of good talks will sit across two or three of them.

• Deployment. Getting a model or an LLM-backed feature from a notebook into something people rely on. Packaging, serving, rollouts, rollbacks, and the parts of the stack you ended up rebuilding.
• Monitoring and observability. How you know whether the system is working when ground truth arrives late, or never. Drift, feedback loops, and the dashboards you stopped looking at.
• Evaluation and guardrails. How you decide an output is good enough to ship, and how you stop it doing harm when it is not. Test sets, human review, red-teaming, and open source tooling you have used in anger.
• Retrieval and generative AI in practice. RAG pipelines, agents and assistants once the demo is over: chunking decisions, retrieval failures, prompt changes that broke things, and how you measured any of it.
• Cost and latency. The trade-offs that shape systems in production. Model choice, caching, batching, self-hosting versus APIs, and the moment the bill arrived.
• Incidents. Something went wrong in production. What happened, how you found out, how you fixed it, and what changed afterwards.
• Governance in daily practice. Not policy documents, but how responsible AI, regulation and liability affect what a team ships on a Tuesday.
• Teams and organisations. Who owns a model once it is live, how data scientists and engineers split the work, and what it takes to keep a system running after the person who built it moves on.

Last year’s programme is a good guide to the range. Nathan Bilton of Weightmans covered who carries the liability when a chatbot gives a customer the wrong answer. Grant Beasley of tombola, with our own Myles Mitchell, showed how deep learning can identify players at risk of gambling harm. Seb Ringrose of Doubleword walked through the failure modes of async agents in production and how to fix them. Each talk was about a specific system with consequences for the people using it, and each would have fallen apart if you took the AI out. Our summary of the 2026 conference covers every talk.

Mac Misiura of Red Hat’s talk on open source guardrails is a good example of the evaluation and guardrails theme, grounded in what it takes to secure LLM applications at scale:

All of the 2026 talks are on the AI in Production 2026 playlist if you want a feel for the level and tone before you write.

What makes an abstract stand out

We read every submission, and the ones that make it onto the programme tend to have a few things in common.

A specific system. “How we monitor a fraud model that scores two million transactions a day” tells us far more than “Best practices for model monitoring”. You do not need to name your employer or share anything confidential, but we need to know what the thing is and who uses it.

A decision or a turning point. The most useful talks are built around a choice you made, an assumption that turned out to be wrong, or a constraint that changed your design. That gives the talk a shape and gives the audience something to take back to their own work.

Openness about what went wrong. Polished success stories are less useful than they look. If something failed, broke or cost more than expected, say so in the abstract. It is often the most interesting part.

A clear takeaway. Tell us what someone in the room will be able to do differently afterwards. One concrete lesson beats five vague ones.

Evidence where you can share it. Numbers, before and after comparisons, or even a rough sense of scale help us judge the talk. Approximate is fine.

To make that concrete, here is the kind of opening that is hard to assess:

In this talk, I will discuss the challenges of deploying large language models in production and share best practices for success.

And here is one that tells us straight away what the talk is:

Our support assistant answered 40% of customer questions without a human, until a product update quietly broke retrieval for a third of them. This talk covers how we found out three weeks late, the evaluation suite we built so it would not happen again, and what it costs us to run.

The second one is invented, but it shows the pattern: a named system, something that went wrong, what changed, and a hint of what you will learn.

What we are less likely to accept

Some talks are good talks but a poor fit for this conference. We are less likely to select:

• Product pitches. Vendors are welcome to speak, and some of our best talks have come from tooling companies, but the talk needs to be about a problem and how it was solved, not a feature tour.
• Tutorials with no production story. “Getting started with library X” is better suited to a workshop or a blog post, unless it is anchored in using X on a live system.
• Benchmarks on their own. Model comparisons are useful when they drove a decision someone had to make. A leaderboard without that context is hard to place.
• Predictions about the future of AI. We would rather hear about what you shipped last quarter than what everyone will be doing in five years.

None of this rules out a talk on its own. If yours sits close to one of these lines, tell us in the abstract why it belongs at AI in Production.

Work in progress counts

You do not need a finished project or a big team. Internal tools count. Systems with a handful of users count. Partial successes and things you have since switched off count. If you are worried your work is not ready, our post on why submit to AI in Production addresses that directly.

First-time speakers are very welcome. Our beginner’s guide to conference abstracts walks through the writing step by step.

Standard talk or lightning talk?

• Standard talks are about 25 minutes: 20 minutes to speak and 5 for questions. They suit a story with a beginning, a turning point and a lesson.
• Lightning talks are six minutes, with slides that auto-advance every 20 seconds and one question at the end. They suit a single idea, a sharp lesson, or one surprising result. There is a prize for the best one, voted for by attendees.

The 2026 lightning talks give a good sense of how much fits into six minutes:

If you are unsure, pick the format you would most enjoy giving. A strong idea will find a slot.

How to submit

Send a title and an abstract of up to 300 words through the submission form by 29 January 2027. You will hear back at most two months after the deadline, and likely sooner.

Speakers giving a standard talk get a free conference ticket, and lightning talk speakers get a 30% discount.

If you are not sure whether your idea fits, email events@jumpingrivers.com before you write it up. We would much rather answer a quick question than miss a good talk.

Super early bird tickets are on sale until 8 January. Book your place.