WORKBENCH / DISPATCH 001 / 2

Per-engagement Companions.

why a Companion you scope to one engagement beats a stable of per-role agents, and what that means if you've spent the year arguing the opposite.

  • nextjs
  • mcp
  • fastmcp
  • agents
  • vercel-ai
STATUS · BUILDING

Over the last three months I’ve watched teams reach for the same shape: a stable of role-specialised agents (a developer agent, a researcher agent, a writer agent) orchestrated by a router. It looks tidy on a slide. It falls apart in practice.

The teams that ship faster aren’t running a stable. They’re running a single Companion scoped to one engagement, one client, one shipped thing. The Companion knows the codebase, the stakeholders, the constraints, the prior decisions. It doesn’t need a router because it doesn’t need to be routed.

The shape that works.

The Companion lives in one repository. It picks up context from the repo itself: recent commits, open PRs, the project’s own docs, the issue tracker. It runs as an MCP server with a small surface area, and the entire context budget goes into the work, not into convincing a stranger of its remit.

// companion-engine/src/server.ts
import { FastMCP } from "fastmcp";
import { engagement } from "./engagement";

const companion = new FastMCP({
  name: "companion-engine",
  scope: engagement.id,        // one engagement, not "all clients"
  context: engagement.bundle(),
});

// no router. no agent registry. no orchestrator.
companion.serve();

Twelve lines. No agent registry. No router. No abstraction over “tools” that pretends each tool is a different agent. The Companion is the codebase plus the conversation, scoped to one project, written once.

The router is the problem. You don’t need a router for a meeting of two people.

What it looks like in practice.

A Companion knows things a stable of role-agents cannot, because the things worth knowing are entangled. The deploy pipeline, the on-call rota, the unspoken decision from a Tuesday call, the architecture choice that looked wrong but turned out to be load-bearing. A router cannot ferry those. A Companion that has been on the engagement for six weeks already holds them.

Three patterns hold across the engagements where we’ve shipped this shape:

  • One Companion per engagement. Not per role, not per stack, not per team. The Companion has the engagement’s name. When the engagement ends, the Companion is archived.
  • No orchestrator over Companions. If a piece of work spans two engagements, a human escalates. The Companions do not talk to each other; humans triangulate.
  • Tools, not agents. The Companion picks up MCP tools (filesystem, GitHub, deploy logs) as capabilities, not as personalities. A “researcher” is a tool surface, not an agent identity.

If you’ve spent the year telling a client that role-specialised agents are the future, this is the part that’s awkward. I have, too. The work didn’t agree.

BUILT.