Agent frameworks and AI agents
View All Tags
I have been investigating which decisions in a coding agent deserve a generative call and which can use a smaller mechanism. Choosing a tool, checking a claim and escalating a task are different problems from writing the patch that solves it. My proposal is to distribute that work across code, classifiers, decision models and LLMs, then measure whether the separation improves the outcome.
I want to start automating things with agents and reuse them across projects. An agent that investigates incidents, another that examines repositories, another that prepares documentation. And I want them to collaborate when the work calls for it.
The supply of frameworks is growing so quickly that choosing one seems to have become the mandatory first step. My question starts earlier: how do you design an agent that others can find, assign work to and hold accountable for its results?
That leads me to services, contracts and distributed systems. The framework running each agent will be a decision within that architecture.
I have spent enough time juggling terminals, branches and pull requests to know that running several coding agents is not just a bigger version of running one. It is a coordination problem. Agent Orchestrator (AO) is a desktop app built to solve that problem, and I am using it to coordinate the work on this site.
I have been working on mastra-azure-ai-search, an Azure AI Search vector store provider for Mastra.
The reason is simple: I opened the integration work upstream in Mastra, but the PR has not been approved yet. Rather than keep the adapter blocked inside a pending pull request, I decided to publish it as a standalone package so it can be used, tested and improved now.
In recent months many frameworks for building AI agents have emerged. Two approaches I find particularly interesting are:
At first glance they look like different worlds, but they share a similar mental model: agents that keep conversations via threads/sessions, messages, and runs.