External system
Triggers / n8n
Email, CRM, form, schedule, and workflow events
Back to work
AI/SaaS / 2026 / Maintained
Multi-Tenant AI Automation Control Plane
A runnable multi-tenant control plane for AI-assisted business workflows, combining FastAPI, Next.js, PostgreSQL, Redis, n8n, provider routing, human approval, idempotency, replay, cancellation, audit traces, and deterministic local demonstrations.
Role
Designer and engineer (solo)
Disciplines
AI Integration / Backend Systems / Full-Stack
Status
Maintained
What this system solves
Standalone automation workflows become difficult to govern when each one owns its own prompts, credentials, retries, approval logic, tenant context, and execution history. Businesses need a shared control plane that makes agent behaviour reviewable and recoverable without allowing a model or workflow canvas to become the authority over business state.
System overview
The platform centralises tenant-scoped agent definitions, execution state, provider selection, approvals, audit events, retries, replay, cancellation, and operational telemetry. Email triage, CRM updates, document generation, and daily-report agents run through one authority boundary: models propose structured actions, while application services validate policy and execute authorised outcomes.
Architecture
Evidence-led public architecture showing the consequential system boundaries, trust decisions, and reliability controls without exposing confidential routes, credentials, or operating procedures.
Architecture evidence
Tenant-aware AI automation control plane
Triggers and n8n workflows submit tenant-scoped requests to a FastAPI control plane that owns execution state, provider routing, approval, tool authority, audit history, replay, and recovery.
Service
FastAPI control plane
Tenant checks, idempotency, state transitions, policy
Worker / workflow
Model router
OpenAI, Anthropic, or deterministic mock recommendation
Control boundary
Approval and tools
Human decision and authorised application actions
State / data
Operational state
PostgreSQL audit history and Redis execution queue
Trust boundaries
- Tenant context is resolved before an agent definition, execution, approval, or trace can be used.
- Models produce proposed actions; application services retain authority over external side effects.
- Customer-facing and policy-sensitive actions can pause in a durable human-approval state.
Reliability controls
- Tenant-scoped idempotency before side effects
- Replay, cancellation, failure listing, and audit trace IDs
- Ordered provider fallback and deterministic no-key mode
- Queue boundary with PostgreSQL execution state
CI-validated portfolio implementation; authentication, managed migrations, signed webhooks, load testing, and real-provider acceptance remain documented pre-production requirements.
- External triggers and n8n submit tenant, agent, payload, and idempotency context to the FastAPI control plane.
- The API owns execution state and records queued, running, waiting-approval, completed, failed, cancelled, and replayed transitions.
- A provider router selects OpenAI, Anthropic, or deterministic mock mode without giving providers authority over external tools.
- Policy checks and approval state sit between model recommendations and application-owned tool execution.
- PostgreSQL stores tenant, execution, approval, and audit state while Redis provides a queue boundary with a local fallback for reproducible demos.
- The Next.js console reads operational state and exposes explicit operator actions rather than hiding control inside workflow canvases.
Engineering decisions
The control plane owns state
n8n coordinates triggers and integrations, but the application service owns tenancy, execution state, approvals, traces, and tool authority so independent workflows cannot drift into conflicting sources of truth.
Models recommend; services execute
Provider output is stored as a proposed action. Sensitive or customer-facing outcomes pass through application policy and, where required, an explicit human approval state before execution.
Deterministic mode is first-class
Every core workflow can run without paid provider keys, allowing CI and reviewers to validate system behaviour independently of external model availability.
Idempotency precedes side effects
A tenant-scoped idempotency key is resolved before creating a new execution, so repeated triggers return the existing result instead of duplicating downstream work.
What I built
- Designed the tenant, agent-definition, execution, approval, audit, queue, and provider domain model.
- Implemented the FastAPI control plane, SQLAlchemy persistence, Redis-backed queue, deterministic fallback mode, and model-provider adapters.
- Built the Next.js operations console for seeding agents, running gated workflows, approving actions, and inspecting system state.
- Created importable n8n workflows for email triage, CRM updates, document generation, and event-driven post-processing.
- Added Docker Compose delivery, CI validation, failure drills, provider setup documentation, API examples, and a reviewer demo script.
Validation and results
- Validated duplicate-safe execution by repeating the same tenant idempotency key and receiving the same execution record.
- Tested approval-gated generation, approval completion, replay with a new trace, cancellation, and tenant-boundary rejection.
- Ran six backend tests, Python compilation, a production Next.js build, and JSON validation for every n8n workflow in GitHub Actions.
- Documented smoke tests and failure drills for missing provider credentials, repeated events, database failure, and transfer fallback.
Limitations
- This is a runnable portfolio implementation, not evidence of operation under real customer traffic.
- Authentication, tenant RBAC, managed migrations, webhook signature verification, high availability, and formal provider acceptance testing remain pre-production requirements.
What would come next
- Add authenticated tenant context, role-based permissions, managed migrations, and secret rotation.
- Move queue processing to dedicated workers with visibility timeouts, retry policies, cancellation, and dead-letter operations.
- Export OpenTelemetry traces and validate the system under load, provider degradation, and recovery exercises.
Security and privacy
- No credentials, customer records, private prompts, provider configuration, or production traces are published.
- Tenant boundaries and model-versus-tool authority are implemented, while authentication and RBAC are explicitly documented as deployment prerequisites.
- The project makes no compliance or production-readiness certification claims.