"Building agents isn't building models. It's orchestrating them, integrating them into business workflows, and operating them at scale": an interview with Yuriy Bezsonov

Before his session at AI Coding Summit, we sat down with Yuriy Bezsonov, Senior Solutions Architect at AWS, to talk about what it actually takes to move AI agents from demo to production, why Java is having a real moment in agentic AI, and much more. Read the entire interview below:

Q1: 25 years in tech, moving from developer to engineering manager to solutions architect, which role taught you the most?

The Solutions Architect role at AWS. As a developer, I learned how to build things. As a manager, I learned how to get things built through others. But as an SA at AWS, I learned how to think at the intersection of business problems and technical solutions at scale: doing architectural reviews, presenting at re:Invent, and running hackathons for 100+ people. No other role demanded that range.

Customer obsession changes how you architect: you stop designing for elegance and start designing for reality. Teaching across EMEA and at conferences forces you to find gaps in your own understanding. And mentoring new architects multiplies your impact beyond any code you could write.

Each role built on the last, but the SA role is where 25 years of compounding experience pays off.

Q2: How did you end up being both a practitioner and a content creator in the Agentic AI space?

It wasn't a deliberate pivot: it was a natural convergence. At AWS, the two sides feed each other. I deliver agentic AI enablements and workshops for partners and customers across EMEA, then turn those real-world patterns into talks at AWS Summits, JCon, Spring IO, and community events.

The moment that crystallized it was organizing a GenAI Hackathon with over 100 participants, resulting in 15+ teams building innovative solutions. You can't run that without both: hands-on depth to guide teams through real problems, and communication skills to inspire them to build. Every customer problem I solve becomes a pattern worth sharing. The two roles aren't separate tracks: they're a feedback loop.

Q3: Enterprise Java has carried a reputation for being slow to adapt. How has that perception held up, or not, in the age of AI?

That perception is outdated. Spring AI, Quarkus, and GraalVM native images have fundamentally changed the game. Modern Java is not the Java people remember from 2010. Enterprise AI workloads need reliable orchestration, strong typing, mature concurrency, and integration with existing systems. Java excels at all of that.

Where I see this play out directly: I work with partners and customers building cloud-native solutions leveraging containers, Kubernetes, Java, and AI technologies. These enterprises have millions of lines of Java. Meeting them where they are, with Java-native AI tooling like Spring AI and Amazon Bedrock SDKs, is what drives real adoption.

Q4: Agentic AI is moving extremely fast. What's the part of this space that you think is genuinely underestimated by most engineering teams right now?

The operational side. Everyone's focused on the model: which LLM, which prompt, which RAG strategy. But the hard part in production is everything around the model: how agents coordinate, how you trace decisions across multi-step workflows, how you handle failures, and how you maintain guardrails at scale.

From performing architectural reviews for PoC projects and supporting large-scale enterprise migrations, I see teams consistently underestimate operational complexity. A demo agent is easy. A production agent that handles edge cases, respects compliance, and can be debugged when it goes wrong, that's a different problem. Teams need proper developer platforms for AI workloads, not one-off setups.

Q5: Can open source frameworks realistically compete with managed cloud services at enterprise scale?

They're not competing: they're converging. And the agentic AI space is the best proof of that.

Amazon Bedrock AgentCore is a managed platform to build, deploy, and operate agents at scale, it handles runtime infrastructure, scalability, memory, observability, and security. But Java developers want to build agents using familiar Spring patterns, not custom infrastructure code. That's exactly why we recently released the Spring AI SDK for Amazon Bedrock AgentCore as an open source library. It brings AgentCore capabilities into Spring AI through annotations, auto-configuration, and composable advisors, you add a dependency, annotate a method, and the SDK handles the runtime contract automatically.

This is the model that works: managed services for the undifferentiated heavy lifting (scaling, security, pay-per-use compute) and open source frameworks like Spring AI for the developer experience and agent logic. The SDK is open source, the community contributes, and it runs on managed infrastructure. It's not either/or: it's open source frameworks running on managed platforms, each doing what they do best.

Q6: Java and Spring have been around for decades. What makes them the right choice for building AI agents, and is there a case where they're not?

What makes them right: enterprise integration (mature clients for every system), type safety (critical when agents make decisions and take actions), modern concurrency with virtual threads, and Spring AI's clean abstractions over model providers, tool calling, RAG, and memory management. It follows patterns Spring developers already know.

Where it's a different story is model training and fine-tuning: that's a specialized domain with its own toolchain. But building agents isn't building models. It's orchestrating them, integrating them into business workflows, and operating them at scale. That's where Java and Spring are at home.

Q7: What's your advice to software engineers who want to make the move into AI architecture without losing their technical credibility along the way?

Three things. First, keep building. The fastest way to lose credibility is to become the person who only draws diagrams. I use Kiro and spec-driven development daily: writing requirements, designing solutions, and letting the AI implement while I stay in control of the architecture. You can't advise on agentic workflows if you haven't built them yourself.

Second, go deep on one vertical, then expand. Don't learn "AI" broadly. Pick a specific intersection: mine was managed agentic platforms like Amazon Bedrock AgentCore combined with open source platform engineering on Kubernetes. An "AI architect" is vague. An architect who can deploy and operate AI agents at scale using AgentCore Runtime while building the developer platform with ArgoCD and GitOps, that's someone teams actually need.

Third, teach what you learn. Preparing talks for conferences or workshops for 100 people forces understanding at a level casual usage never requires. Teaching is the best way to stay sharp while building the communication skills architecture roles demand.