A recent comment on one of my dev.to posts asked a simple but insightful question:
What specifically was breaking before MCP: context loss between agents, or tool-call inconsistency?
At first, I thought the answer would be straightforward.
But after reflecting on my Tokyo Transit project, I realized the real issue wasn't either of those things.
The project has gone through three major iterations over the past year, and each version reflects a different stage in my understanding of AI agents, orchestration, and system architecture.
Looking back, the project became a timeline of how the AI ecosystem itself has evolved.
Version 1: SmolAgents and the "Big System Prompt" Era
The first version was built with SmolAgents.
Like many developers experimenting with agents at the time, I believed that if I wrote a sufficiently detailed system prompt, the agent would behave consistently.
As the project grew, the prompt grew with it.
More instructions.
More formatting rules.
More edge cases.
More exceptions.
Eventually, the system prompt became the primary mechanism for controlling behavior.
The result was predictable: the agent worked sometimes, but not reliably.
The biggest problem wasn't context loss between agents.
It wasn't tool-call failures either.
The real problem was prompt alignment.
I was trying to manage architecture through instructions.
Version 2: Google ADK and Higher-Level Abstractions
My next experiment used Google ADK.
Compared to the first version, ADK provided a high-level, cleaner, and more structured framework for agent development.
Many orchestration concerns were abstracted away.
This made development faster and reduced some of the complexity I had been manually managing.
But it also taught me something important:
Frameworks can simplify development, but they don't automatically solve architectural problems.
I still needed a clear way to define responsibilities, manage behavior, and structure agent workflows.
Version 3: MCP and Skill-Based Design
The current version uses the MCP Python SDK together with Skill-based design.
This was the point where the project finally started to feel maintainable.
Instead of pushing more logic into a growing system prompt, I could separate capabilities into tools and skills with clearly defined responsibilities.
MCP wasn't magical.
It didn't suddenly make the agent smarter.
What it provided was structure.
Skills gave me a dedicated place for behavioral instructions.
MCP provided a consistent interface for tools.
Together, they made the system easier to reason about, test, and improve.
So What Was Actually Breaking Before MCP?
Looking back, the biggest issue wasn't context loss or tool-call inconsistency.
It was architectural drift.
Whenever the agent behaved incorrectly, my solution was usually to add another instruction to the system prompt.
Over time, the prompt became harder to maintain and reason about.
The more complexity I added, the less predictable the behavior became.
In hindsight, I was trying to solve an architecture problem with prompt engineering.
Final Thoughts
The Tokyo Transit project is still under active development.
There are bugs to fix, improvements to make, and plenty left to learn.
But the most valuable outcome wasn't the transit tool itself.
It was seeing how my approach changed over time:
- From large system prompts
- To higher-level agent frameworks
- To MCP and Skill-based architecture
The project became a record of my own learning journey as AI agents evolved from experiments into systems that can be structured, maintained, and improved over time.
If you've been building with agents, MCP, or AI frameworks, I'm curious: what was the biggest lesson that changed the way you design your systems? Feel free to share your experience in the comments below.
Top comments (0)