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
#abap