Vision#

Modern service ecosystems are rich in APIs, but composing them reliably from natural-language intent is still hard. This project explores a control-plane design where an LLM planner transforms intent into a JSON DAG, and an orchestration layer executes that graph with retries, fallback handling, and service-to-service coordination.

Why This Matters#

NOTE

The README describes the repository as the control-plane implementation for the Autonomous Microservice Composition paper, with a FastAPI app that handles planning, execution, and combined plan-and-execute flows.

IMPORTANT

The control plane explicitly combines four pieces: Redis for service registry, OpenAI GPT-4o-mini for planning, PostgreSQL with pgvector for metadata/embeddings, and HTTPX + NetworkX for orchestration.

TIP

This architecture is useful because it separates service knowledge, reasoning, and execution into distinct layers that can evolve independently.

WARNING

The public repo is compact and implementation-focused, so this post should be read as a technical walkthrough rather than a full benchmark or production-hardening guide.

CAUTION

Any real deployment would need additional controls around authentication, validation, timeout strategy, observability, and execution isolation.

What the Control Plane Does#

1
User Intent
2
    ↓
3
LLM-Based DAG Planner
4
    ↓
5
JSON Workflow Graph
6
    ↓
7
Execution Orchestrator
8
    ↓
9
Microservice Calls
10
    ↓
11
Results + Errors + Fallback Handling

The repo README and control_plane.py show this flow through three REST endpoints: /plan, /execute, and /plan_and_execute.

Project Attributes#

Repository Structure#

At the time of writing, the public repo is intentionally small and centered on the main application file.

1
Autonomous-Microservice-Composition-via-LLM-Agents-in-an-MCP-Control-Plane/
2
├── README.md
3
└── control_plane.py

Setup Summary#

The README lists three required environment variables:

1
export REDIS_URL="redis://localhost:6379/0"
2
export POSTGRES_DSN="host=localhost dbname=metadata user=postgres password=secret"
3
export OPENAI_API_KEY="<your_openai_api_key>"

It also lists the main dependencies as:

1
pip install fastapi uvicorn redis httpx networkx psycopg2-binary pgvector openai

And the app is started with:

1
uvicorn control_plane:app --reload --host 0.0.0.0 --port 8000

Core Components#

1
{
2
  "name": "user-profile",
3
  "endpoint": "http://user-profile-service/api",
4
  "input_schema": {},
5
  "output_schema": {},
6
  "cost_profile": 0.005,
7
  "fallback": "http://user-profile-fallback/api"
8
}

1
class PlanRequest(BaseModel):
2
    intent: str
3

4
class PlanResponse(BaseModel):
5
    graph: dict

1
def _fetch_embeddings_metadata(self):
2
    with self.conn.cursor() as cur:
3
        cur.execute("SELECT name, input_schema_vector FROM service_schemas;")
4
        return cur.fetchall()

1
for name in nx.topological_sort(G):
2
    node = G.nodes[name]
3
    service_url = node["endpoint"]
4
    inputs = {k: results.get(v, payload.get(v)) for k, v in node["inputs"].items()}

API Surface#

The FastAPI app exposes three endpoints:

1
@app.post("/plan", response_model=PlanResponse)
2
def plan_intent(req: PlanRequest):
3
    return planner.plan(req.intent)
4

5
@app.post("/execute", response_model=ExecuteResponse)
6
async def run_graph(req: ExecuteRequest):
7
    return await orch.execute(req.graph, req.payload)
8

9
@app.post("/plan_and_execute", response_model=ExecuteResponse)
10
async def plan_and_run(req: PlanRequest):
11
    plan = planner.plan(req.intent)
12
    return await orch.execute(plan.graph, {})

These three endpoints create a clean split between planning-only, execution-only, and a combined end-to-end flow.

Why This Design Is Interesting#

• It keeps planning and execution separate
• It uses a registry instead of hardcoding services
• It supports topological execution of dependency graphs
• It includes fallback behavior for failed services
• It leaves room for telemetry- and embedding-aware planning

This makes the repository a useful prototype for control-plane thinking around LLM-driven service composition.

Current Limitations#

• The public repo is compact and does not yet include a broader project structure
• Security, auth, and multi-tenant concerns are not the visible focus of the starter
• There is no complete benchmark or evaluation harness in the repo root
• Retry policy is described in the README, but the visible code is still a concise reference implementation

What I Would Add Next#

• Typed DAG schemas and stronger validation
• Structured retry policies with exponential backoff
• Authentication and service authorization
• Richer telemetry capture and observability dashboards
• Safer prompt construction and planner guardrails
• Execution sandboxes and rate limiting

These additions would make the control plane much more deployment-ready.

Key Innovation#

IMPORTANT

The central idea is combining LLM-based workflow planning with a service-aware execution control plane, rather than using the LLM only as a text generator.

Conclusion#

This project is a strong prototype for autonomous microservice composition. Its value lies in how it unifies registry metadata, semantic context, DAG planning, and orchestrated execution into one control-plane design.

From user intent to executable service graph — that is the core promise of this MCP control plane.