A lightweight, multi-tenant, event-driven Agentic AI platform prototype built with FastAPI, MCP, and an orchestrator-agent architecture.
The platform demonstrates secure event routing, tenant isolation, correlation tracking, human approval for sensitive actions, controlled MCP tool execution, retry and failure handling, observability, auditability, PII protection, and modular agent workflows.
- Challenge
- Architecture
- Core Workflow
- Key Components
- Multi-Tenant Isolation
- Correlation Tracking
- Retry and Failure Handling
- Human-in-the-Loop
- Project Structure
- Technologies
- Setup
- Example Event
- Example Response
- Sensitive Action Example
- Assessment Coverage
- Future Improvements
- Project
AI Engineering Lead – Agentic Platform Prototype
Design and prototype the core of a multi-tenant, event-driven agentic platform.
FastAPI
|
v
Event Router
|
v
Orchestrator
|
v
Agent
|
v
MCP Tool
|
v
Response
CLIENT
|
v
FASTAPI
|
v
AUTHENTICATION
|
v
EVENT ROUTER
|
v
ORCHESTRATOR
|
v
AGENT
+------+------+
| |
v v
MODEL PROVIDER MCP CLIENT
| |
v v
AI MODEL MCP SERVER
|
v
BUSINESS TOOLS
|
v
RESPONSE
Agent
|
v
Sensitive Action
|
v
Approval Service
|
v
Human Approval
|
+-- Rejected --> Stop
|
+-- Approved
|
v
MCP Tool
|
v
Execute Action
- A client sends an event through the FastAPI API.
- FastAPI validates the incoming request.
- Authentication identifies the tenant.
- The Event Router validates the event contract and extracts the tenant and correlation IDs.
- The Orchestrator coordinates the workflow.
- The Agent interprets the task and determines the required action.
- The Agent communicates with the MCP server through controlled tools.
- Sensitive actions can be routed through the Human Approval service.
- Approved actions are executed through MCP.
- The result is returned to the client.
- Observability and audit logs track the workflow.
Provides the HTTP API layer and exposes the platform endpoints.
Validates requests and provides the tenant identity used throughout the workflow.
Responsible for:
- Event validation
- Event contract handling
- Tenant identification
- Correlation ID propagation
- Routing events to the appropriate workflow
Coordinates the overall agent workflow.
It acts as the control layer between the Event Router and Agent, ensuring that the correct processing sequence is followed.
Responsible for understanding the incoming task, identifying the intent, extracting required parameters, and selecting the appropriate tool.
The current prototype demonstrates refund-related task processing.
Provides controlled communication between the Agent and MCP server.
Exposes business operations as tools.
Example tools:
check_refund_eligibility
issue_refund
The prototype uses synthetic business data to demonstrate MCP-based tool integration.
Handles human approval for sensitive operations.
Example:
Pending
|
v
Human Review
|
v
Approved / Rejected
Provides an abstraction layer for AI model integration, allowing the Agent architecture to be extended with different models without tightly coupling the Agent to a specific provider.
Sensitive information is masked before being written to logs.
The platform records important workflow events such as:
AGENT_STARTED
TASK_RECEIVED
MCP_CALL
MCP_SUCCESS
MCP_FAILURE
MCP_RETRY
Important actions are recorded with:
- Tenant ID
- Correlation ID
- Action
- Resource ID
- Result
Every event carries a tenant_id.
Example:
{
"tenant_id": "tenant-a",
"correlation_id": "corr-001"
}The tenant context is propagated through the workflow:
Request
|
v
Event Router
|
v
Orchestrator
|
v
Agent
|
v
MCP
This allows business operations and audit records to remain associated with the correct tenant.
The architecture is designed so that customer context and data are not unintentionally shared across tenant boundaries.
Each request receives a correlation_id.
Example:
corr-010
The same correlation ID is propagated across the workflow.
This makes it possible to trace:
Client Request
|
v
Event Router
|
v
Orchestrator
|
v
Agent
|
v
MCP
|
v
Business Operation
This is useful for debugging, monitoring, and auditing distributed agent workflows.
MCP operations use retry handling.
Example:
Attempt 1
|
v
Failure
|
v
Attempt 2
|
v
Failure
|
v
Attempt 3
|
v
Success / Final Failure
The prototype uses a maximum of three attempts for MCP operations.
If all attempts fail, the Agent returns a controlled failure response rather than silently failing.
Sensitive actions require explicit approval.
For example:
Check Refund Eligibility
|
v
Sensitive Refund Action
|
v
Create Approval
|
v
Human Approval
|
v
Approved
|
v
Execute MCP Tool
This prevents the Agent from automatically executing sensitive business operations without authorization.
Event-Driven-Agentic-Platform/
|
├── app/
│ ├── agent/
│ │ └── agent.py
│ │
│ ├── models/
│ │ └── events.py
│ │
│ ├── orchestrator/
│ │ └── orchestrator.py
│ │
│ ├── router/
│ │ ├── approval_router.py
│ │ ├── event_router.py
│ │ └── request_router.py
│ │
│ ├── services/
│ │ ├── approval.py
│ │ ├── auth.py
│ │ └── model_provider.py
│ │
│ ├── utils/
│ │ └── pii.py
│ │
│ ├── mcp/
│ │ └── server.py
│ │
│ └── main.py
│
├── .gitignore
├── requirements.txt
└── README.md
- Python
- FastAPI
- FastMCP
- MCP
- Pydantic
- Uvicorn
- AsyncIO
git clone https://github.com/maaran77/Event-Driven-Agentic-Platform.gitcd Event-Driven-Agentic-Platformpython -m venv venvWindows PowerShell:
venv\Scripts\Activate.ps1pip install -r requirements.txtuvicorn app.mcp.server:app --host 127.0.0.1 --port 8001In another terminal:
uvicorn app.main:app --reloadThe API will be available at:
http://127.0.0.1:8000
Swagger documentation:
http://127.0.0.1:8000/docs
{
"event_id": "evt-010",
"event_type": "agent.requested",
"tenant_id": "tenant-a",
"correlation_id": "corr-010",
"payload": {
"message": "Check order ORD-1001 and tell me if it is eligible for a refund"
}
}{
"status": "processed",
"event_id": "evt-010",
"tenant_id": "tenant-a",
"correlation_id": "corr-010",
"agent_result": {
"status": "completed",
"order_id": "ORD-1001",
"mcp_result": {
"success": true,
"order_id": "ORD-1001",
"amount": 2499,
"eligible": true,
"reason": "Within refund window"
}
}
}For a sensitive action such as issuing a refund, the workflow can become:
Client
|
v
FastAPI
|
v
Event Router
|
v
Orchestrator
|
v
Agent
|
v
Approval Service
|
v
Human Approval
|
v
MCP Server
|
v
issue_refund
|
v
Response
An approved action returns information such as:
{
"status": "approved_and_executed",
"approval_id": "approval-id",
"tenant_id": "tenant-a",
"action": "issue_refund",
"resource_id": "ORD-1001",
"mcp_result": {
"success": true,
"order_id": "ORD-1001",
"refund_amount": 2499,
"status": "refund_issued"
}
}The prototype addresses the key architecture requirements:
| Requirement | Implementation |
|---|---|
| Multi-tenancy | Tenant ID propagation and isolation |
| Event-driven architecture | Event Router + event contracts |
| Agent boundaries | Dedicated Agent component |
| Orchestration | Dedicated Orchestrator |
| MCP integration | MCP Client + MCP Server |
| Human approval | Approval Service |
| Authentication | Auth Service |
| Retries | MCP retry handling |
| Failure handling | Controlled failure responses |
| Observability | Structured logging |
| Auditability | Audit logs |
| Correlation tracking | Correlation IDs |
| PII protection | PII masking |
| Model abstraction | Model Provider service |
| Controlled tool access | MCP tool boundary |
The prototype can be extended with:
- Persistent approval storage
- Production authentication and authorization
- Redis/Kafka-based event streaming
- Database-backed tenant isolation
- Production LLM providers
- Tenant-specific model configuration
- Model fallback strategies
- Prompt and model version management
- Cost monitoring
- Distributed tracing
- Production-grade observability
- Advanced PII detection
- Role-based access control
Event-Driven Agentic Platform
Developed as a prototype for the Mini Hackathon – AI Engineering Lead: Agentic Platform Prototype challenge.
The implementation focuses on demonstrating the core architecture and working execution path rather than production-scale infrastructure.