The Framework Debate is Over
For the better part of a year, almost every conversation I had about enterprise AI started the same way. It wasn't about what the agent needed to do, but about which SDK we were supposed to bet on: Semantic Kernel, AutoGen, or maybe Foundry? It felt like these framework choices were the defining architectural decision, the one thing that would either propel our project into success or doom it to obsolescence in a few months.
We were wrong.
Microsoft finally settled that debate for us. By introducing a unified Agent Framework and quietly putting both Semantic Kernel and AutoGen into maintenance mode, they effectively stopped the clock on that specific anxiety. By April 2026, when the new framework hit version 1.0 and GA, the choice we had spent months agonizing over simply ceased to exist as a decision.
But here’s the reality: Microsoft changed the menu, not the meal. The stress we put on picking the "right" framework obscured the far more difficult, far more important engineering challenges that actually determine whether an agent survives in production.
Do You Actually Need an Agent?
The first question I ask now is much simpler: Does this actually need to be an agent?
The term "agent" has become a magnet for over-engineering. I’ve watched teams spend weeks designing elaborate, multi-agent orchestrations for processes that were, at their heart, straightforward, linear sets of deterministic steps: read a document, validate it against a table, call a specific API, move to the next file.
When you already know every step, you have a workflow. And a workflow, built with a handful of clean, well-tested functions, is almost always the better engineering choice. It’s easier to build, easier to maintain, and infinitely easier to trust when something goes wrong.
An agent earns its complexity. It should only be used when the system must make genuine decisions it cannot predetermine—choosing between disparate tools, adapting to unpredictable data, figuring out, on the fly, what comes next. Don’t just label a workflow as an "agent" because it sounds better to stakeholders. If your logic is deterministic, keep your code deterministic.
Less is More: Rethinking Context Management
Once you decide an agent is truly required, the next trap is how you handle information. Early on, I spent a lot of time comparing models, agonizing over them as if I were choosing a restaurant dish. Now, I spend nearly all my time thinking about context.
It turns out that more context is often the enemy. I have seen perfectly capable agents fail because they were handed far too much information. One team I worked with assumed that flooding the model with every internal document they possessed would result in superior, more knowledgeable answers. It did not.
The results became slower, more erratic, and curiously prone to skipping the salient facts. The agent was struggling to find the signal in the massive amount of noise. When we aggressively cut the context down to only what was strictly necessary for the immediate task, the performance jump was instant.
Stop trying to give the model "everything." The most resilient agent systems I’ve built are the ones that are ruthlessly selective about what reaches the model, and when.
Engineering for Real-World Failure
Most demos look flawless because they are designed for the happy path. But production is not a demo.
In the real world, APIs time out after you’ve already kicked off an agent. Tool calls will fail, sometimes partway through execution. Models will enter loops, repeatedly calling the same tool because the output wasn’t exactly what they wanted. Dealing with these errors is where 80% of the actual engineering work happens.
That is your recovery logic. It’s not flashy, it’s not something a framework will do for you, and it’s arguably the most critical part of the entire system.
You need to decide, for every step: When things go sideways, do we retry? Do we roll back a previous action? Do we pause and hand the state to a human, or do we limp on with partial results? No framework will make this judgment call for you. It’s on you. The mark of a production-ready agent isn’t how it performs when it works, but how gracefully it handles reality when it refuses to follow the script.
The Security Boundary is Identity
Finally, stop thinking about security as solely an orchestrator problem. The moment an agent touches real business systems, identity becomes your most important boundary.
Every project reaches this point, and it’s usually later than it should be: Who, exactly, is this agent acting as? Is it using your developer credentials? A shared service account? The credentials of the specific user who submitted the request?
If you get this wrong, you’ve built something that is essentially an autonomous user running with more power than any single human employee should possess. That looks fine, right up until the moment of the first audit.
The Agent Framework helps wire these systems together—standards like the Model Context Protocol make the technical implementation much smoother. But the governance? The questions of where a human needs to sign off, what constitutes "too much" access, and how much autonomy to grant in a specific context—those are still, and will always be, your decisions.
Building for Long-Term Resilience
Looking back at this past year, the biggest challenges weren’t technical. They were organizational. As soon as a team hears "agent," expectations shift instantly. Business stakeholders start expecting magic—they assume the agent can autonomously solve problems that haven’t been clearly defined, while developers often assume the agent will have a "reasoning" capability that doesn't yet exist.
Don't build for today’s framework winner. Build for change. Understand that your biggest hurdle isn't the SDK version or the orchestration model; it’s building systems that operate as predictably as possible despite being built on non-deterministic models. Focus on the context, plan for the failure, and be the one to set expectations before the buzzwords do the damage for you.
