Flagship case study
Central Brain
From Business Intent to Authorised Action
Multi-tenant AI business platform combining company knowledge, persistent memory and authorised actions through connected services.
- Role
- Applied AI Engineer
- Company
- Projekt Rising
- Period
- 2026
- Delivery
- Internal / staging
Context
Business problem
Central Brain was a multi-tenant AI business platform for SME owners and employees whose company knowledge, conversations and operational tools were spread across disconnected systems. Finding relevant organisational context and turning intent into action required switching between applications.
We designed one conversational workspace where an authenticated user could retrieve company knowledge, maintain context between conversations and invoke authorised services. The interface streamed tool progress and results so multi-step work remained visible.
Role
My responsibility
The concept and requirements were shaped collaboratively by a team of three to four people. I led the technical implementation, translating that shared concept into the working platform.
I personally designed and built the FastAPI backend, agent and tool-calling architecture, hybrid retrieval, persistent memory, Microsoft 365 integrations, and React and TypeScript frontend. I also designed the streaming event model, authentication and isolation controls, testing and evaluation infrastructure, chat sharing, pinned conversations, and both deployment workflows.
I owned Lead Engine and Subscription Finder end to end, co-developed Competitor Analysis with another engineer, and independently integrated all three into Central Brain. Azure SQL, Microsoft Graph, Clerk and OpenAI were established Projekt Rising technologies; I designed Central Brain's architecture within that environment.
System
Architecture and scale
The React frontend consumed server-sent events for status updates, tool activity, citations and response text. FastAPI handled identity, conversation state, retrieval, persistence and integration boundaries. A bounded OpenAI Responses API orchestration layer made multiple model passes and selected authorised tools.
Hybrid retrieval and persistent memory used Azure SQL, while Microsoft Graph and three business platforms supplied external capabilities.
- Agent tools
- 12
- External systems
- 7
- Backend test definitions
- 485
- Evaluation cases
- 180
Flow
From request to result
- 01
The backend authenticated the user with Clerk, established organisation context and checked conversation ownership.
- 02
It loaded bounded conversation history, relevant user settings and permitted user memory, avoiding uncontrolled growth in model context.
- 03
The orchestration layer selected an appropriate retrieval operation, clarification step or authorised business tool.
- 04
Tool arguments were parsed and validated. Trusted identity and tenant values were injected server-side rather than accepted from model-generated arguments. Calls used controlled timeouts, retries and failure results.
- 05
Retrieved evidence and tool outputs returned to the agent for synthesis. The completed turn and supporting metadata were persisted while progress, citations and response text streamed to the frontend.
Engineering
Core challenges
Challenge 01
Multi-pass orchestration
Requests could require retrieval, clarification, several independent tools and a final synthesis pass. I implemented a bounded loop with per-turn tool availability, model-tier routing and serial or concurrent execution.
Malformed arguments became explicit tool results, individual failures did not automatically terminate the turn, and reaching the pass limit forced a final text response. A structured SSE model carried status, tool calls, results and response deltas to the interface. This kept complex execution finite and observable.
Challenge 02
Persistent memory
The original implementation stored larger plain-text memories under titles. The model selected apparently relevant titles and complete entries were inserted into the agent context. This depended heavily on title selection and could load more text than the request needed.
I redesigned memory around user-scoped fact extraction. New facts were consolidated against existing records, superseded information was retired without losing its evidence, and temporal reconciliation distinguished current from outdated context. Semantic and keyword retrieval produced candidates that were ranked and trimmed into bounded context.
I also implemented evidence-backed synthesis over memory and conversation records. This created a granular architecture with explicit control over scope, freshness, relevance and context size, without relying on the model to select whole memory documents.
Challenge 03
Connected services
Microsoft Graph required OAuth handling, server-side token handling and refresh, and calendar or mailbox operations. Internal business services could be slower and sometimes needed to continue beyond the immediate request.
I implemented validated service adapters, timeouts, retry policies, asynchronous jobs, completion webhooks and streamed progress events. Partial failures became controlled results that the agent could explain or work around, while bounded execution prevented stalled dependencies from creating unending turns.
Boundaries
Security and multi-tenancy
I implemented multi-tenancy as an application boundary, not a prompt instruction. Clerk established identity; conversation access was ownership-checked; company knowledge and business tools were organisation-scoped; and memory and mailbox access were user-scoped.
The backend discarded model-supplied identity fields and injected trusted user and organisation identifiers server-side. Additional controls included hashed sharing tokens, webhook validation, route-level rate limiting, server-side Microsoft token handling and refresh, tool-argument validation and secret redaction.
Quality
Testing and evaluation
I created essentially all of the automated testing and evaluation infrastructure. The backend test suite comprised 51 files and 485 test definitions; the frontend added five files and 25 definitions.
Tests covered agent routing, tool validation, concurrent execution, retrieval, reranking, memory, conversation recall, Microsoft integrations, streaming, sharing, background processing, security controls and failure paths. The evaluation suite contained 180 cases across eight datasets, creating a repeatable basis for analysing changes over time.
Delivery
Outcome
Central Brain was deployed to an internal/staging environment and tested as a complete system by Projekt Rising team members. Their feedback informed iterations across frontend usability, answer quality, retrieval, memory, business tools and reliability.
The platform demonstrated the full path from authenticated intent through orchestration, grounded retrieval and authorised action to persisted, streamed results.
Reflection
What I would improve now
The next stage would add reproducible fixed-dataset benchmarking, automated tenant-isolation integration tests, sustained-load testing for streams and asynchronous jobs, deployment smoke tests, stronger model-and-tool observability, and automated secret-scanning gates.
These additions would make quality, isolation and operational behaviour continuously measurable as the platform evolved.