I built an agent for the fourth time last week

I built an agent for the fourth time last week.

Same pattern: tools, MCP, HITL, sub-agents, observability, thread persistence. 400 lines of glue code I had already written three times before.

That is when I understood the problem was not the agent. It was me reinventing the wheel.

Architectures converged

Agent architectures have converged. Whatever the use case — real-estate data extractor, code reviewer, RAG assistant, sales agent — you find the same skeleton.

Model + system prompt + tools + MCP servers + sub-agents + interrupt rules + observability middleware.

Always. The only thing that changes is the config.

I had to test several hypotheses for a client, so I encapsulated all of that in a home-grown framework.

The idea: you declare your agent in a 20-line YAML. The framework handles the rest (create_deep_agent, SSE streaming, PostgreSQL persistence, tool resolution, MCP, sub-agents, prompt management via Phoenix).

An agent today looks like this:

name: haiku-files
model: openai:anthropic/claude-haiku-4.5:nitro
mcp_servers:
  - name: my-mcp
    url: https://awsomemcp/your/mcp
    headers: { X-API-Key: ${AWESEOME_API_KEY} }

The YAML is about 20 lines. Everything else (thread persistence, streaming, tool loader, MCP lifecycle) lives in the framework.

Then the market caught up

More serious solutions arrived, including Docker Agent and Kagent for Kubernetes.

They do exactly the same thing: declare an agent, wrap it in standard behaviours.

What should happen, happened — bigger players shipped better tools than mine.

That is the open-source game. You ship, you learn, and when the giant releases the same idea, you know the idea was not so bad after all.

My repo is in the comments. Docker Agent and Kagent as alternatives if you want something more industrialised.