Post one introduced the OData MCP Proxy and gave us five BTP MCP servers by configuration. Post two took those MCP servers and wrapped them in a Pydantic AI multi‑agent application: an orchestrator on top, one specialist per MCP server below. That fixed the tool‑overload problem the original single‑agent design had hit. But it left one uncomfortable property in place: the list of specialists was still hard‑coded. Adding another MCP server meant editing the repo and redeploying. For my own BTP management experiments that is acceptable. For a broader scenario (say, an AI Data Enabler that wants to expose many, many APIs to LLMs safely) it very clearly isn’t.
So in this final iteration I made the agents themselves first‑class, dynamic objects: created, edited, deleted and reloaded without ever restarting the app.
Post one introduced the OData MCP Proxy and gave us five BTP MCP servers by configuration. Post two took those MCP servers and wrapped them in a Pydantic AI multi‑agent application: an orchestrator on top, one specialist per MCP server below. That fixed the tool‑overload problem the original single‑agent design had hit. But it left one uncomfortable property in place: the list of specialists was still hard‑coded. Adding another MCP server meant editing the repo and redeploying. For my own BTP management experiments that is acceptable. For a broader scenario (say, an AI Data Enabler that wants to expose many, many APIs to LLMs safely) it very clearly isn’t.So in this final iteration I made the agents themselves first‑class, dynamic objects: created, edited, deleted and reloaded without ever restarting the app. Read More Technology Blog Posts by Members articles
#SAP
#SAPTechnologyblog
