apLabs
A practical AI workbench for technical leaders, consultants and engineers managing complex knowledge work.
apLabs is my personal platform for applying LLMs, memory, agents and automation to real professional workflows: research, writing, project context, task management and technical analysis.
Built around strict project context boundaries, smart memory and real consulting work, not generic chat.
Uses: Microsoft Semantic Kernel, MongoDB, OpenAI, Gemini. Built with: VS Code and GitHub Copilot.
What is apLabs?
apLabs started as a practical experiment: to understand what useful AI-assisted knowledge work could look like for technical professionals working across multiple clients, projects and contexts.
It evolved into a working system I use to support consulting workflows, including research, writing, task tracking, document handling and project memory.
At its core, apLabs is designed to help technical work stay structured, traceable and context-aware over time.
Why I built apLabs
Large language models opened up real possibilities for technical knowledge work, but most AI tools still break down in professional use.
They often:
- blur context across projects and clients
- lose important decisions and working knowledge
- rely on repeated prompting instead of persistent memory
- fit casual chat better than structured professional work
- lock users into large platform ecosystems
apLabs was built to explore a different approach: AI support designed around project integrity, long-term context and real consulting workflows.
It is not a finished product story. It is a working system, developed in practice, with the architecture decisions, trade-offs, limitations and lessons documented openly.
Core Design Principles
apLabs has evolved through practical use: identify a real need, build a workable solution quickly, and improve it through iteration.
Project Isolation
Strict boundaries between projects and clients preserve context and reduce cross-project contamination.
Model independence
apLabs works across OpenAI and Gemini models to avoid dependence on a single vendor.
Persistent Memory
Structured notes, conversations, decisions and references help the system retain useful context over time.
Workflow fit
The platform is shaped around real consulting work: research, writing, analysis, task management and delivery support.
Practical automation
Agents are used where they can save time, improve consistency or reduce manual overhead, not for novelty.
Iterative development
apLabs is built by testing ideas in real work, keeping what proves useful and discarding what does not.
Why this exists
This page shares the process of building modern AI software in practice: the architecture decisions, workflow choices, failures, constraints and useful outcomes.
The aim is simple: to share practical lessons for technical professionals who want a more grounded view of what AI can and cannot do in serious knowledge work.
This is not a polished success story.
These pages are an honest working record of building with modern AI tools: what worked, what failed, what changed, and what proved useful in real consulting practice.
MongoDB, Performance Constraints and the Case for Self Hosting
MongoDB helped apLabs get started, but the real lesson came later. Atlas Free Tier was a generous way to learn the platform and build iteratively, but as the project grew, performance on the hosted free tier became the bottleneck. Moving to self-hosted MongoDB Community Edition on a local Debian server solved the immediate constraint and kept the work moving without forcing an unnecessary upgrade.
From Spoken Notes to First Draft: How I Use apLabs to Write Faster
Typing is not always the best way to think. In apLabs, I can record rough spoken notes, convert them to text automatically, and use an LLM to turn them into a structured first draft for a blog article in minutes rather than hours.
Adding a Video Generation feature to apLabs: A lesson about good foundations
A short morning experiment adding AI video generation to apLabs turned into a useful reminder about software architecture, prompt discipline, and vendor independence. The feature itself was quick to build. The more important lesson was why earlier architectural groundwork made that speed possible.