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.

Cardboard Architecture: when code looks clean but nobody understands it​

Some projects give a great first impression when you open them:

• Well-organized folders: core, domain, infrastructure, services, helpers…
• Classes with serious names: UserService, OrderManager, PaymentHandler…
• Extensive documentation, diagrams, detailed README…

And yet, when you try to follow how the system actually works, you find something very different: methods calling other methods calling other methods, layers that only delegate, business logic scattered across the repository… and you thinking:

“This looks architectural, but understanding it is painful.”

That’s what I like to call cardboard architecture: it looks solid on the outside but doesn’t really hold the weight of the business inside.

Two ways to build production AI agents​

In recent months many frameworks for building AI agents have emerged. Two approaches I find particularly interesting are:

• Mastra, an all-TypeScript agent framework that feels natural if your stack is Node-based.
• Microsoft Agent Framework + Azure AI Foundry (Azure AI Agents), Microsoft's offering that pairs an orchestration library with a managed agent service on Azure.

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.

In recent years, I've seen two equally damaging extremes in many development teams: over-engineering and the eternal PoC culture. This post is about why both extremes are bad engineering practices and how to find a reasonable middle ground.

Hello and welcome to my personal blog! 👋

This is the first post of many to come. Here I'll share my experiences, learnings, and reflections about technology, software development, and everything I'm passionate about.