I Almost Chose My Agent Framework for the Job Market, Not My Clients
For months I wrote about 'an agent framework' instead of naming one. That wasn't a style choice. It was cover for a decision I hadn't made: LangGraph, Google ADK, or PydanticAI, and which career each one actually bet on.
If you’ve read this blog for a while, you’ve probably noticed I write about “an agent framework” or “a state graph” more often than I name one. That wasn’t a style choice. For months it was cover for a decision I hadn’t actually made yet.
Here’s the decision: LangGraph, Google ADK, or PydanticAI. And here’s what I was really deciding, underneath the technical question: not which one is best, but which future I was building toward.
The admission
Writing platform-agnostic is a real house rule here. I do it on purpose, to keep the writing evergreen instead of tied to whichever tool is popular this quarter. But for a stretch of months, the abstraction was doing double duty. It was also hiding the fact that I hadn’t committed to a framework, and the hedging showed up in the prose whether I meant it to or not. I’d write “an orchestration layer” because I genuinely didn’t know yet which orchestration layer I was going to bet on.
Three frameworks, three futures
I want to name the three honestly, because each one wasn’t just a technical stack. Each one was a bet on a different professional future.
LangGraph is the closest thing to a de facto standard right now. It has the deepest job market of the three by a wide margin. If the goal was getting hired, or landing contract work with a team that already has an opinion about tooling, LangGraph was the strongest argument, by far.
Google ADK is newer, expanding fast, and it carries an “enterprise” association that reads well to a certain kind of buyer. Betting on ADK was a bet on enterprise credibility. Not “I can build agents.” More like “I can build agents the way a large, risk-averse organization already trusts.”
PydanticAI is the newest of the three. It has the thinnest job market by far. And it’s the one that actually matched how I like to build: typed, explicit, no magic state dict, no framework I have to fight to understand what actually ran. Betting on PydanticAI meant betting against market recognition and betting on fit.
What actually got built during the hedge
This wasn’t a theoretical exercise I ran on paper. I built the same kind of agent, the same tool calls, the same basic loop, in more than one of these frameworks while the decision stayed open, because the only honest way to evaluate a framework bet is to build something real in it, not read the quickstart and guess.
That’s expensive. Standing up the same agent twice, in two different frameworks, to find out which one actually fits, costs real time. I paid it anyway, because guessing wrong on a framework bet is more expensive than the evaluation.
The reframe that broke the tie
The turning point wasn’t a feature comparison. It wasn’t “ADK’s session model is cleaner” or “LangGraph’s checkpointer does more.” It was admitting what I was actually optimizing for.
I asked myself what I was really trying to get out of any of this. And the honest answer was: getting hired onto someone else’s team was secondary to me. What mattered was building well for the clients and the team I actually have, right now, not the team I might join if I optimized my stack for a resume.
Once that was the real question, the framework with the best market value stopped being the right answer. The one that fit how I build won, even though it’s the weakest of the three if the goal is “get a job.”
What it cost, said plainly
I want to be honest about the tradeoff instead of pretending this was obviously correct for everyone. PydanticAI has the least market recognition of the three. If I were optimizing for contract work or an interview pipeline, this would have been the wrong call, and I’d tell you that directly if you asked me for advice with that goal.
But that wasn’t my goal. And pretending it was, just because the framework with the biggest job market is the “safe” answer, would have meant building the wrong thing for the actual people I build for.
I could have picked the framework that looks best on a resume. I almost did. What changed my mind wasn’t a better comparison chart. It was admitting which future I was actually building toward, and picking the bet that matches the thing I’m really doing, not the thing that sounds better to say I’m doing.