Multi-agent systems that hold up under real usage.

How I approach agent orchestration

Every agent I build follows the same three rules, whether it's one agent or a coordinated fleet.

First: agents run on an explicit state graph, not a single large prompt. Each decision, tool call and return is a node. The state is checkpointed at every step so sessions can pause and resume exactly where they left off. This is what makes an agent debuggable and auditable, instead of a black box.

Second: tools live behind a Model Context Protocol server, not hardcoded inside the agent. Same tools serve any framework, any model, any client. Redeploying a tool doesn't touch the orchestration.

Third: every irreversible action has a hard pause enforced by the graph itself, waiting for a human decision. This isn't a prompt asking the model to be careful. It's execution that genuinely stops, at the exact node where damage would otherwise happen.

Small teams: 2 to 5 agents

A small business usually wants a support triage agent, a qualification agent, and something automating a repetitive back-office task. Three specialized agents, each with a tight set of tools connected to what the business already runs on (spreadsheet, CRM, shared inbox).

My approach: build each agent as an independent unit that can be deployed and monitored on its own. Free-tier infrastructure covers real usage for most small deployments, so ongoing cost is close to nothing. The client gets a system they can operate without a dedicated team.

Enterprises: dozens of coordinated agents

At larger scale the interesting problem changes. It stops being about any single agent and starts being about how they coordinate: handoffs, shared context, avoiding two agents doing the same work, avoiding an agent triggering another in an infinite loop.

My approach: a supervisor agent routes work to specialized worker agents, each with a scoped MCP server exposing only the tools that worker actually needs. State is centralized so handoffs preserve context. Recursion limits and idempotency keys prevent the two most common failure modes of multi-agent systems.

Scaling from three agents to fifty doesn't require a rewrite. The spine is the same. What changes is the number of worker nodes, the routing logic in the supervisor, and the monitoring surface.

Security is not optional

An agent with tool access is a piece of software that takes actions in your systems on behalf of a language model that can be manipulated. Treating that casually is how companies end up in security incident reports.

Every tool I ship goes through a least-privilege review before it leaves my machine, and every agent is tested against an automated red-team suite: role-override attempts, secret exfiltration, escalation abuse, requests to generate destructive code. The tests run against the real model, not a mock, and use deterministic assertions so they don't depend on any paid judge model to run.

Keeping infrastructure cost near zero

The default assumption around AI is that it's expensive. That's only true if you build it wrong.

My tool servers run on Cloudflare Workers, which covers 100,000 requests per day on the free tier. Model calls default to provider free tiers, with a straightforward path to a paid key when the client wants to scale. Nothing in my architecture requires a subscription or a credit card to start. This matters: it's the difference between a client saying yes and a client saying "let me think about the budget."

Proof: triagem-atendimento

The triagem-atendimento project is the concrete reference: a customer support agent with three tools (order status, refund policy, human escalation), built with LangGraph for orchestration, MCP for tools, and a hard human-approval pause before any escalation goes through.

It runs end-to-end: agent in Python, tools deployed to Cloudflare Workers in production, a FastAPI HTTP layer, a Next.js interface, and an automated security suite passing against the real model. The full source is public.

This is my starting point for any new client project. What changes per client are the tools (their systems, not mocked), the domain of the agent, and the approval routing (Slack, WhatsApp, email, dashboard). The architecture stays.