Skip to content

Rewrite Orchestrator as general workload orchestrator with MCP adapter#32

Open
emerson-gray wants to merge 3 commits intomainfrom
add-orchestrator
Open

Rewrite Orchestrator as general workload orchestrator with MCP adapter#32
emerson-gray wants to merge 3 commits intomainfrom
add-orchestrator

Conversation

@emerson-gray
Copy link
Collaborator

@emerson-gray emerson-gray commented Mar 14, 2026

Summary

Rewrites the orchestrator architecture from an agents-only orchestrator to a general workload orchestrator that manages agents, MCP servers, and discovery signals. Adds the MCP Adapter as a new component.

Key design decisions

Orchestrator scope expansion:

  • Renamed from "Agents Orchestrator" to "Orchestrator" — reconciles all workload types.
  • MCP servers are separate workloads, not sidecars. Each MCP server gets its own OpenZiti identity with independently scoped network access.
  • Dependency ordering — Orchestrator starts MCP server workloads first, waits for readiness, then starts agent workloads. On shutdown, agents stop first; MCP servers stop when no agents reference them.
  • MCP server demand has two sources: agent config references (agent dependency) and discovery signals (short-TTL for tool listing from UI).
  • Tool discovery — UI creates a short-TTL signal, Orchestrator starts MCP workload, UI queries tools through a platform service, workload auto-stops on TTL expiry. Reuses the same reconciliation loop.
  • State tables split: workload_assignments (shared) + agent_assignments + mcp_assignments.

MCP Adapter (new component):

  • Standalone binary added to any MCP server image as the container entrypoint.
  • Launches the MCP server process as a subprocess and bridges its native transport to gRPC.
  • stdio mode: communicates with the subprocess via stdin/stdout (JSON-RPC). Supports the majority of existing MCP servers distributed via npx, uvx, etc.
  • HTTP mode: launches the subprocess, waits for it to listen, connects via Streamable HTTP locally, exposes gRPC externally.
  • Agents always talk gRPC to MCP servers over OpenZiti — uniform interface regardless of underlying MCP transport.
  • Configuration via CLI flags: adapter --mode stdio --command "npx best-mcp-server" --grpc-port 50051.

MCP Server resource definition updated:

  • New fields: image (required), transport (stdio/http), httpPort.
  • image and command now required (MCP server is its own workload, needs an image).

Files changed

New:

  • architecture/mcp-adapter.md — MCP Adapter architecture

Rewritten:

  • architecture/orchestrator.md — general workload orchestrator

Updated (cross-references and naming):

  • architecture/agent/overview.md — MCP servers as separate workloads, gRPC over OpenZiti
  • architecture/system-overview.md — component diagram, summary, repo map
  • architecture/control-data-plane.md — renamed, updated reconciliation resources
  • architecture/resource-definitions.md — MCP Server fields
  • architecture/authn.md — MCP server identities
  • architecture/notifications.md — broadcast rooms
  • architecture/runner.md — identity management for all workload types
  • README.md — doc index
  • gaps/current-state.md — renamed
  • gaps/migration-roadmap.md — renamed
  • open-questions.md — updated references, added MCP identity scoping question

New docs:
- orchestrator.md: Reconciliation loop (demand vs supply diff), demand
  signal from Threads (pull + notifications via threads:messages:new),
  supply tracking from Runner (pull + notifications via
  runner:workloads:status), workload_assignments PostgreSQL table,
  status state machine, workload assembly, idle timeout enforcement,
  failure handling, source-oriented notification rooms.

Updated docs:
- system-overview.md: link Agents component to orchestrator.md
- control-data-plane.md: link Agents Orchestrator to orchestrator.md
- agent/overview.md: cross-reference orchestrator in Lifecycle section
- README.md: add Agents Orchestrator to doc index
- open-questions.md: replace Scheduler Service question (resolved —
  orchestrator subsumes scheduler) with Orchestrator Horizontal
  Scaling question (sharding strategy, coordination)
Major changes:
- orchestrator.md: Renamed from "Agents Orchestrator" to "Orchestrator".
  Now reconciles all workload types (agents, MCP servers, discovery signals).
  MCP servers are separate workloads with own OpenZiti identities, not sidecars.
  Dependency ordering: MCP workloads start before agents.
  Tool discovery via short-TTL signals through the same reconciliation loop.
  State tables split: workload_assignments + agent_assignments + mcp_assignments.

- mcp-adapter.md: New doc. Standalone binary wrapping any MCP server.
  Supports stdio mode (launches subprocess, bridges stdin/stdout to gRPC)
  and HTTP mode (launches subprocess, connects via Streamable HTTP, exposes gRPC).
  Distributed as a static binary added to any MCP server image as entrypoint.
  Configured via CLI flags/env vars (--command "npx best-mcp-server" etc).

- agent/overview.md: MCP servers are now separate workloads, not sidecars.
  Agent connects to MCP servers via gRPC over OpenZiti.
  Updated contract diagram, tools section, wrapper model, lifecycle sequence.

- resource-definitions.md: MCP Server resource gains image, transport, httpPort fields.
  image and command now required. transport: stdio (default) or http.

- system-overview.md: Renamed Agents Orchestrator to Orchestrator.
  Added MCP Adapter to component summary and repo map (agynio/mcp-adapter).
  Updated component diagram with separate MCP workloads and gRPC connections.

- control-data-plane.md: Renamed to Orchestrator. Updated description and
  reconciliation resources (added MCP Servers).

- authn.md: Updated identity list to include MCP servers alongside agents.

- notifications.md: Added threads:messages:new and runner:workloads:status
  broadcast rooms to room naming convention table.

- runner.md: Updated authentication section — identity management covers
  both agent and MCP server workloads.

- README.md: Renamed Orchestrator entry, added MCP Adapter entry.

- gaps/: Renamed Agents Orchestrator to Orchestrator.

- open-questions.md: Updated Orchestrator reference. Added MCP identity
  scoping question to OpenZiti section.
@emerson-gray emerson-gray changed the title Add Agents Orchestrator architecture Rewrite Orchestrator as general workload orchestrator with MCP adapter Mar 16, 2026
* MCP servers as sidecars, identity scoped to agentId+threadId

- MCP servers are sidecar containers within the agent workload pod
- Agent reaches MCP servers via gRPC on localhost (no OpenZiti)
- MCP sidecars share the agent's OpenZiti identity
- Identity scoped to agentId + threadId
- Orchestrator renamed to Agents Orchestrator (manages agent workloads only)
- MCP discovery extracted to separate service (open question)
- Removed: mcp_assignments table, dependency ordering, MCP server demand
- Removed: image field from MCP Server resource (comes from workspace)
- Shared filesystem works trivially via pod volumes
- Added MCP Discovery Service open question

12 files changed across architecture/, gaps/, open-questions.md, README.md

* Remove redundant localhost references

localhost mentioned once in mcp-adapter.md (canonical location).
All other docs reference 'gRPC' or 'shared network namespace' without
repeating the transport detail.

* Deduplicate facts across docs

Each fact stated once in its canonical location, linked elsewhere:
- Agent workload structure: orchestrator.md
- Identity scoping (agentId+threadId): authn.md
- MCP adapter role: mcp-adapter.md
- Shared network/filesystem: orchestrator.md (workload section)

Removed all localhost references (implicit from shared network namespace).
Removed redundant re-explanations of sidecar model from agent overview,
resource definitions, control-data-plane, system-overview, runner, README.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant