AI Agent Orchestration

Multi-agent systems that survive contact with production — identity, credentials, supervision, and recovery.

Getting one agent to do something impressive is a prompt problem. Getting twenty of them to run unattended for a week is an operations problem, and it is a different discipline entirely. I build the layer underneath the models: process supervision, scoped credentials, identity per agent, structured recovery when a run fails, and an interface a human can actually use to see what the fleet is doing. I have built this system for myself and run it in production, which means I am designing from operational experience rather than from a diagram.

What I build

Orchestration architecture

The topology decision comes first: whether agents run on one operator machine or coordinate through an always-on host, how work is distributed, what happens when a node disappears mid-run, and where state lives so that a restart is safe rather than destructive. I design this concretely against your workload instead of adopting a framework's defaults and discovering their limits later.

Credential and permission boundaries

An agent that holds your production keys in an environment file is a breach waiting for a bad tool call. I build scoped, expiring credential access so each agent receives only the secrets it needs, for only as long as it needs them, without a human pasting values into a chat window. This is exactly what abracadabra does, and the same pattern transfers to whatever vault or secret manager you already run.

MCP servers and tool surfaces

Agents are only as capable as the tools you expose to them, and a badly shaped tool surface produces confident, wrong behaviour. I write MCP servers that expose your internal systems to agents with the right granularity, sensible failure messages, and the guardrails that keep a retry loop from becoming an incident.

Observability and control

Fleets fail quietly. I build the cockpit — live visibility into what every agent is doing, the ability to attach to a running session, structured logs that survive the run, and a kill switch that actually works. Without this you cannot debug a multi-agent system; you can only restart it and hope.

How I work

We start with a paid consult where I map what you are actually trying to automate against what agents can reliably do today. Plenty of workloads do not need agents, and I will say so — a cron job and a well-shaped script beat a fragile agent loop every time. Scoping this honestly up front is cheaper than discovering it three weeks in.

From there I write the architecture down before writing code: topology, state boundaries, credential flow, failure modes, and the specific way each one is recovered from. You get that document whether or not we continue, and it is written to be handed to another engineer.

Implementation runs in short increments against a working system. I would rather have two agents running reliably in week one than twenty agents that have never survived a restart, so the supervision and recovery layer gets built before the fleet is scaled up.

I hand over runnable documentation — the environment checklist, the deployment path, and the runbook for the failures we actually hit during the build, not a theoretical list. Your team should be able to operate the system without me.

Proof

Case studies from work I have built and run, not client logos.

Stack

  • TypeScript
  • Node.js
  • MCP
  • Claude Agent SDK
  • Docker
  • Cloudflare
  • Postgres
  • Redis
  • Ollama

Questions

What counts as agent orchestration rather than just calling an LLM API?

Orchestration starts when agents run longer than a request, run concurrently, or run unattended. At that point you need supervision, per-agent identity, credential scoping, state that survives a restart, and a way to observe and stop the system. If you are making one API call and rendering the response, you do not need orchestration and you should not pay for it.

Which agent frameworks and models do you work with?

Primarily the Claude Agent SDK and MCP, with self-hosted Ollama where private code or data cannot leave your infrastructure. I am deliberately not dogmatic about frameworks — the orchestration, credential, and recovery layers are the durable parts, and they outlive whichever SDK is current.

Can agents run on our own infrastructure instead of a hosted service?

Yes, and it is often the right call. The systems I have built run on self-hosted machines behind a tunnel, on Cloudflare Workers at the edge, and on containerised cloud hosts. If your constraint is that source code or customer data cannot reach a third-party model, self-hosted inference is a first-class option rather than a downgrade.

How do you keep an autonomous agent from doing something destructive?

Three layers: the credential boundary means an agent cannot reach a system it was not scoped for; the tool surface is shaped so destructive operations require explicit, separately-authorised calls; and the observability layer means you see what is happening while it happens rather than afterwards. Prompt-level instructions are the weakest of the three and I do not rely on them alone.

What does an agent orchestration engineer actually do?

An agent orchestration engineer builds the system that runs AI agents, rather than the agents themselves. That means process supervision so a crashed agent is noticed and restarted, per-agent identity so you can tell which one took an action, scoped credentials so an agent can only reach what it was granted, state that survives a restart, and observability so a human can see and stop what is happening. The prompts and the model choice are a small part of the work; the operations layer is most of it.

How long does it take to build a production multi-agent system?

A supervised system running two or three agents reliably is typically a few weeks. Scaling that to a larger fleet is mostly additional work on credentials, observability, and recovery rather than on the agents. The honest answer is that the first working version comes quickly and the last ten percent — the failure handling — is what takes the time, which is why it gets built first rather than last.

How do engagements start?

With a paid 30-minute consult. You get a concrete architectural opinion on your problem in that call whether or not we work together afterwards.

Last updated .