Four Agent Frameworks in Sixteen Months · Vasco Engineering

← All articles<br>Four Agent Frameworks in Sixteen Months

How Gama went from LangChain to LangGraph to Google ADK to Mastra to the Claude Agent SDK — and what we’d tell our December 2024 selves.

Sebastien Castiel

Staff Software Developer

July 24, 2026

On this page

$ git log --oneline gama/runtime<br>- LangChain (TypeScript)Dec 2024<br>- LangGraph (Python)mid 2025<br>- Google ADK + Agent Engine (Python)Oct 2025<br>- Mastra (TypeScript)Mar 2026<br>+ Claude Agent SDK (TypeScript)Apr 2026

Gama is Vasco’s AI agent. It answers questions about your revenue data, investigates why a metric moved, writes business reviews, and runs the custom agents our customers build. Under the hood, it has been rebuilt on a different agent framework four times in sixteen months.

That sounds like a failure. We want to argue it isn’t — and that the real mistake in 2026 is the opposite one: staying loyal to a framework out of sunk cost. But to make that argument honestly, we have to walk through each migration, including the parts that don’t flatter us.

By the numbers

4frameworksin 16 months

1.5weeksADK → Mastra, 2 devs, ~50 PRs

37klinesof old stack deleted (395 files)

hoursprototype to green light on the Agent SDK

few $/reportfor a deep business review, better than before

0disruptionagents kept running behind a feature flag

December 2024

Babysitting the LLM

Gama started as a feature called Stage Diagnostics: a text explanation of the numbers on a page, to make the analysis easier to read. Simple enough. We had two problems.

The first was that hallucinations were everywhere, and no amount of prompt engineering gave us a guarantee. Worse — and this is the part people forget about 2024 — the outputs that were accurate were mostly useless. They stated the obvious. "Your conversion rate went down because fewer accounts converted." Thanks.

The second was structured output. LLMs at the time were bad at returning data in the exact shape you asked for, and we needed specific values formatted a specific way inside the text. Our fix, and we’re not proud of this, was to write code that parsed the generated text, detected the numbers in it, and reformatted them ourselves. Our first solution to unreliable AI output was to write more code around it.

If we’re honest about the effort split, about 70% of the work on that feature was babysitting the LLM — parsing, validating, retrying, formatting — and maybe 30% was the product.

Every prompt change risked breaking the parsing logic, and every parsing change constrained the prompt. That’s the context in which LangChain looked like salvation: a mature framework (by the standards of the time) that promised to absorb the babysitting. We wrote an ADR, chose LangChain over Vercel’s AI SDK (too young) and CrewAI (Python-only, and we were a TypeScript shop), and committed. We even decided not to build an abstraction layer on top of it. Going all in felt efficient.

2025

The hiring decision that became an architecture decision

Here’s a migration you won’t find an ADR for: LangChain in TypeScript became LangGraph in Python. Nobody sat down and wrote "we are switching languages because the person we hired knows Python" — but that’s what happened, and at the time it was completely rational. In early 2025, Python was the language of AI. The ecosystem, the examples, the reference implementations, the future hiring pool: all Python-first. When we hired our first AI developer, betting on TypeScript for the AI layer would have felt contrarian. So we carved the LLM logic out of our existing services into a dedicated Python service, and moved on.

What did it actually cost? More than we expected, in a way that had nothing to do with the language being hard. Python is not a complex language. But doing things right — developer experience, CI/CD, Docker builds, deployment hygiene — meant our team of TypeScript veterans had to ramp up on a whole ecosystem.

Meanwhile, the AI developer we’d hired was genuinely good with AI but didn’t have much production engineering experience. So we ended up with the worst of both worlds: the people who knew how to run services in production didn’t know the language, and the person who knew the language wasn’t the one setting up its scaffolding. Everyone was outside their comfort zone at the same time.

We also created a split that a later migration would exist purely to undo: two stacks, one monorepo full of shared TypeScript libraries our AI service couldn’t touch.

October 2025

Google ADK, or "It Worked Locally"

By fall 2025 the LangGraph service worked, but it was heavy: custom orchestration, hand-rolled conversation state in Postgres, Docker builds through CircleCI, and a framework whose age was starting to show — API decisions made early in LangChain’s life had calcified, and we were paying for them. When Google’s Agent Development Kit came along, the promise was exciting. Less boilerplate than LangGraph, batteries...