StudioX AI

The challenge

Company knowledge sat in SharePoint, Confluence, Jira, ticketing systems, and years of unstructured files. Assistants that could reach it ignored permissions, so an answer could expose a document the asker was never cleared to read. The work that actually consumed headcount was multi-step — read a mailbox, extract fields, query a knowledge base, generate a document, send it — and that needed automation, not a chat window.

Collaboration

This was a TrueLogics client engagement. I sat in the meetings myself. Each company walked through how the business actually ran, I proposed the AI solution on the platform, and I carried it through implementation to production. The same platform served very different customers because each one enables only the services it needs: law firms for legal document work, IoT companies for data analysis, teams sitting on large PDF libraries for employee and customer chatbots, and sales teams for sales analytics.

From discovery to production

• Legal document workflows for law firms, taken from the client's process through to production
• Data analysis for IoT companies
• Document chatbots that answer employee and customer questions from the company's PDF libraries
• Sales analytics for sales teams
• A YAML workflow runtime — about 26 step types — so a new automation ships without a deploy
• Permission-aware retrieval, so search only runs over documents the asker is cleared to read
• Ingestion across about 15 source types, including PDFs, Office files, audio, video, SharePoint, Confluence, and Jira
• Self-hosted Milvus and reranking, which cut vector-search cost and made on-premise installs possible
• Per-tenant token and storage budgets with a cost check before a request is sent, plus tracing on every API resolver and database command

How it was solved

A GraphQL API fronts about 100 feature domains. Behind it, a 10-stage pipeline normalizes about 15 source types into Milvus. An LLM pass maps the question onto the labels that person is cleared for, and only those labels become the search filter — filtering after the search would leak that a document exists. Workflows are YAML step graphs with conditionals, loops, scheduling, sub-workflows, and human prompts. A self-hosted cross-encoder reranks results so document text never goes to a third-party reranker, which is also what made air-gapped installs possible. Recurring jobs claim ownership in MongoDB so scaled replicas do not process the same work twice.

Key technical decisions

• 01Automations are YAML, not hardcoded flows, so a new operational workflow ships without a deploy.
• 02Access control runs inside retrieval, before the search. Filtering afterward leaks the existence of a document.
• 03Reranking stays self-hosted, so document text is not sent to a third-party API and on-premise deployment stays possible.
• 04Moved off a hosted vector database to self-hosted Milvus for cost at volume and for air-gapped installs.
• 05Recurring jobs claim ownership in the shared job collection at boot, so horizontal replicas do not double-process.

Screenshots

Impact

• One codebase now serves multi-tenant SaaS customers and on-premise enterprise installs.
• Operations teams author their own automations in YAML instead of waiting on a deploy for each new workflow.
• Assistants answer from company knowledge without crossing a permission boundary, which is what made the platform deployable for regulated customers.
• Vector-search cost dropped, and on-premise deployment became possible, after the move to self-hosted Milvus and reranking.
• Production issues became queryable history: every resolver and database command records timing, arguments, and errors.