Subscribe to our YouTube channel, or listen the interviews on Spotify / Apple

Right now, the biggest leap for AI isn’t a bigger model – it’s giving models and agents a way to act.

In this episode of Inference, I sit down with Alex Hancock – Senior Software Engineer at Block, core contributor to Goose (the open-source, multi-purpose AI agent), and a member of the Model Context Protocol (MCP) Steering Committee – to talk about the infrastructure that’s quietly powering the next wave of AI.

We cover:

Alex also shares his view on the next year of protocol development, why he thinks AGI will arrive incrementally, and how a runner’s mindset shapes his approach to building tools that last.

If you’re building agents, connecting models to the world, or just trying to understand the emerging “protocol layer” of AI, this conversation will give you a hint. Let’s find out how we’re teaching AI to act – and what’s still missing. Watch it now →

This transcript is edited by GPT-5. Let me know what you think. And – it’s always better to watch the full video) ⬇️

Ksenia Se: Hi Alex. Thanks for making time for this interview in the middle of summer.

Alex Hancock:
Yeah, nice to see you. Thanks for having me.

Ksenia: Quick intro → Alex is a Senior Software Engineer at Block. He’s been deeply involved with Goose, the open-source multi-purpose AI agent, and he serves on the MCP Steering Committee. Let’s start with the basics – what is MCP, and why has it become so important?

Alex:
MCP is a protocol that gives models access to context. At a high level, I attribute its success and rapid growth to the fact that it addresses a core need. In one of David Parra’s early presentations, he used the image of a really smart model as a brain in a jar – amazing, but cut off from the world around it. MCP removes the jar. It lets the model connect to nearby data sources and call tools to make changes in different systems. In short, it gives models arms and legs.

Ksenia: Early on, many developers didn’t immediately see the benefits. Why do you think that was?

Alex:
Good question. I can share our experience. We were building an agent and needed a flexible way to extend its capabilities – read resources, perform actions, edit files, change settings in other applications. When we read the MCP spec, it fit our needs, so we adopted it. It did the job we were looking for. Since then, the pickup has been strong. Adoption is accelerating globally, and for good reason.

Ksenia: Everyone’s talking about MCP at conferences, but the MCP Steering Committee still feels opaque. I couldn’t find much information. What is it?

Alex:
We’re working to change that. The Steering Committee is a group of people who have been involved with MCP in different ways – contributing to the open-source repos and the spec, building MCP clients or servers, and dedicating time to improving the protocol. The perception of secrecy is something we want to fix. A governance and stewardship framework went up on the website last week that explains how people can get involved and how protocol decisions are made. It’s a first step toward opening things up and inviting broader participation.

Ksenia: You mentioned that a lot has been happening recently on the MCP Steering Committee. What’s going on? Can you share some details?

Alex:
Most of it is happening directly in the spec repository – the Model Context Protocol GitHub repos, issues, and discussions. From my perspective, there’s a big push around spec compliance. MCP moves quickly: there was a new spec version in March and another in June. SDKs in different languages are now catching up, and we’re asking how to avoid this constant lag. The goal is to keep SDKs in sync with the latest spec so we can move fast, with great server and client support in any language.

There’s also an agents working group starting up, focused on topics relevant to people building agents and agentic projects – which matters to me because of my work on Goose. It’s exciting to see efforts both on consistent protocol implementation and on advancing the protocol itself.

Ksenia: Tell me more about that connection to agents. What are the bottlenecks and next goals for MCP in that area?

Alex:
Some of it comes down to fundamentals. If you’re building an agent in Swift for Mac, for example, you need a complete SDK in that language. That kind of foundational work benefits agentic projects and others.

Authentication is another big one. The recent adoption of OAuth 2.1 as MCP’s authentication standard makes it much easier to build agents that can automate tasks on platforms like Slack, Stripe, or Square. There are also early discussions around supporting long-running processes – where a tool call might take minutes or hours and the agent needs asynchronous access to results. All of these are highly relevant to agent development.

Ksenia: What about privacy and security in MCP?

Alex
OAuth 2.1 was a big step forward. Six months ago there was no authentication in MCP at all – just a transport protocol and message format between client and server. Now there’s a secure, industry-standard connection model that’s been battle-tested for years.

For privacy and security more broadly, using an MCP server is like using any other server or library – you need to trust the source. The protocol doesn’t yet say much about verifying server authenticity, but I expect projects will emerge to address that. That was missing at the start, and the original team took their time to make the right choice rather than rushing. The result – adopting modern OAuth 2.1 – is a solid improvement over having no authentication at all. I think it’s a great step, and there’s more to come.

Ksenia: Just to make the Steering Committee picture clearer – what are your goals, how often do you meet, and how do you involve members? I know there are people from Microsoft and OpenAI, maybe Anthropic too. How does it work?

Alex:
So far, communication has been fairly informal – mostly discussions in GitHub. In March, we had our first in-person meetup at the MCP Dev Summit in San Francisco. It was great to put faces to names, share a room, and talk about how to make MCP useful for everyone. I came away impressed by the dedication of the people involved. It feels like a special moment for this technology, and I’m grateful to be part of it.

Ksenia: What are the main topics you’re discussing now for the future?

Alex:
It’s becoming a bigger group with more working groups and projects. From my own involvement, the big one is a global registry of MCP servers – the idea I originally suggested that others have since driven forward. It would let clients discover servers that fit their needs and allow server authors to publish into a central directory.

Another major stream is SDK support – making sure all MCP features are implemented in any language people want to work in, and that spec compliance is consistent across those languages. The agents working group I mentioned earlier is just getting started. It will focus on how agentic projects use MCP and what changes the protocol might need to support the access patterns agents rely on. Those are the streams I’m most familiar with, though there’s always ongoing evolution in the spec itself.

Ksenia: How do you look at other protocols like A2A? Is there room for collaboration? Microsoft’s A2A registry, for example, might be useful for MCP.

Alex:
Absolutely. It’s still early for all of this. We’re all trying to figure out the best way to give models the information and tools they need to perform useful actions for users. When A2A was announced, I thought its framing made sense – it’s complementary to MCP.

MCP is great for connecting a model or AI-powered app to the right context and tools in isolated systems – Slack, Square, Cash App, whatever it may be. A2A operates at a higher level, where agents talk to each other in a less structured way – almost like English. There will likely be multiple approaches. In some cases, you might use A2A; in others, MCP is the better fit. Healthy competition and overlap are fine. Goose is model-neutral and protocol-neutral – we support MCP today, but we’d consider supporting A2A or others if they complement what we do.

Ksenia: You’ve said this is still the beginning – we’re connecting the “brain” to actual action and turning it into a doer. How do you see this space evolving in the next year?

Alex:
A year already feels like a long time. I’ve been working on this for six months, and the pace of change is staggering – both in model capabilities and in the tools around them. It’s hard to predict specifics, but one of the biggest challenges now is context.

The models are smart, but whether they succeed depends on whether we give them the right context. With the right context, they do great work; with the wrong context, they fail. That’s pushing us to build scalable ways to discover and manage context – context discovery algorithms, context management systems. That’s where a lot of our focus is right now.

Ksenia: From mine – human – perspective, working with models requires constant adjustment. A new model comes out, and suddenly you might need a different way to talk to it. Goose is model-agnostic, but how do you adjust for different models and still get tasks done?

Alex:
Goose has a top-level system prompt that applies regardless of the model – it defines Goose as an AI agent that helps the user. In theory, it shouldn’t need frequent changes, and in practice, it usually doesn’t.

That said, when new models come out, we test and sometimes tweak the prompt to improve performance. New models often surprise us – some behaviors improve, others change in unexpected ways. For example, recent models I’ve coded with now document their work extensively, producing markdown summaries of the code they’ve written. That’s a big productivity boost for engineers.

Our goal with Goose is to adapt easily without heavy rework. So far, it’s been able to take advantage of model improvements without major changes, which is exactly what we wanted.

Ksenia: If we get back to the connections and protocols – what’s still missing?

Alex:
The registry is a big one – getting it deployed and out in the world. The design is mostly done, the API is coming together, and implementation work is underway. There’s a GitHub issue tracking the release checklist. Once the registry is live, clients will be able to discover servers via search or API, which will be huge.

Spec compliance is another gap. Many SDKs aren’t yet up to date with the June spec. For example, “elicitation,” a great feature from that release, isn’t supported in most SDKs. Getting every language’s SDK aligned with the latest spec is essential.

Ksenia: I’m thinking ahead six months – ideally, agents should be working consistently together, finding all these protocols and connecting to them.

Alex:
Exactly – a bit of blue-sky thinking. If everything goes well, context discovery and context management are the biggest pieces. Give a model the right context and it can do great work; give it the wrong context and it fails.

Right now, only a small percentage of people really understand what context a model needs for a given task. The goal is to democratize that – to build algorithms that let agentic systems proactively discover the right context on their own. We’re not there yet, but that’s the work ahead: creating systems where anyone can give an agent a goal and get results as good as – or better than – what the most skilled AI users can get today.

Ksenia: Because there are still so many software developers not fully involved with AI and agentic systems. How did you get involved?

Alex:
I started working on Goose at Block last November. I joined to help with a specific workstream, saw how powerful the project was, and knew I wanted to work on it full-time. So I made that happen.

Ksenia: I see a lot of developers following the news and trying to understand what these terms mean and how to get in. It’s such a huge force moving into AI.

Alex:
It is. This is a fundamental shift in how we create software – not just an incremental improvement or a new developer tool. It’s a new way of working, and it will transform not only software development but any kind of work done on a computer. I’m grateful to be part of it.

Ksenia: How much more empowered do you feel?

Alex:
Hard to measure precisely, but I’d say it’s the single biggest productivity jump in my 15-year career as a software engineer. The difference is dramatic.

Ksenia: My husband’s a developer – he says he can work on four completely different projects in parallel now, letting one model or agent run while switching to another. At least four times the speed.

Alex:
Exactly. Code that used to take hours of focused effort can now be generated in minutes. The challenge then becomes how we interact with that output – how we design interfaces for these models. If you have multiple agents running and one needs your input urgently, you need a clear way to surface that, while letting the others run in the background. Classic interface design principles still apply – we just need to adapt them to this new capability.

Ksenia: You’ve said that if a model gets the right context, it succeeds, and if not, it fails. In that bigger-picture view – what about AGI?

Alex:
That’s a bit above my pay grade, but I do see these systems getting more capable week by week. My hunch is that will continue – more data, more modes of interaction, more relevant context, all driving rapid improvement in what agents like Goose can accomplish.

On AGI itself, I like the view that it’s not a “before and after” moment. It’s a continuous process of capability growth. At some point – arguably already – you’ll look at these systems and realize they’re incredibly powerful and intelligent.

Ksenia: That’s close to Yann LeCun’s point – it’s incremental. No one wakes up one day to find AGI has “arrived.” But I hear when you saying about context, I hear that there is always human in the loop in this scenario.

Alex:
Right. And there’s still a tremendous amount of human expertise involved. You can have two people sit down with a given task and an agentic system like Goose, and the person who really knows the project can drive it to a great result right away. Someone who’s never worked on that project might not know which files to point the model to or which ones are important to look at. So there’s still a lot of human expertise needed to get good results from these tools.

Ksenia: I believe it will stay that way. Wrapping up our interview, I always ask this question about a book that shaped you. It can be related to your professional life or completely unrelated.

Alex:
A book that shaped me – not necessarily related to technology – I’d have to go to another big part of my life, which is competitive distance running. I run track and field, cross country, and road races. I’ll call out the book Once a Runner.
If you ask anyone who runs track and field, they’ll know this book. It’s a seminal book about running, and one I constantly go back to for inspiration when I’m building up to a big race.

Ksenia: Give me a little detail – what are the main lessons?

Alex:
It’s about going all in. The protagonist – based loosely on the author John Parker, who was a sub-four-minute miler – is chasing the goal of running a mile under four minutes. What I like is how it shows exactly what it takes if you want to be excellent at something, not just good. It’s about picking something that matters to you and structuring your life around it so you can achieve greatness.

Ksenia: That’s awesome. I love this question about books – it opens people up from a very different perspective.