Anonymized portfolio piece. This describes the personal AI operating platform I designed, built, and run daily. Two of its subsystems already have their own case studies on this site: the hybrid local/cloud router with a code-enforced data-sovereignty gate and the concurrent multi-agent orchestrator. This case covers the operating system around them. All identifying detail about what the system is used for is removed; the architecture, mechanism, and validation figures are real.
The user and the problem
I run sensitive, document-heavy work daily: notes, transcripts, documents, reference libraries, and a growing trail of prior decisions, all of it scattered, and some of it not safe to hand to a cloud model. Most AI tools are optimized for isolated conversations. They do not reliably preserve operational knowledge, distinguish sensitive information from general questions, complete work that outlives one context window, or convert failures into permanent safeguards. That gap costs real hours: re-explaining context every session, re-deciding settled questions, and manually deciding case by case what was safe to send off the machine.
The system needed to solve five connected problems: keep sensitive information local by default, search and reason across a large, fragmented knowledge base, preserve useful context across sessions without filling every prompt with history, execute multi-step tasks reliably across different models and machines, and improve over time instead of repeating the same failures.
The requirement was an operating environment around the model: memory, control, evidence, and learning, with private data confined to controlled infrastructure.
The bet
I bet on a tiered architecture instead of picking one model and living inside its limits. A primary workstation handles sensitive inference, document processing, speech services, scheduled tasks, and agent execution. A second local machine provides embeddings, intent classification, and low-latency voice inference. Selected cloud models are used only for tasks that carry no private content, or for tightly controlled planning and review workflows with restricted, read-only file access. Every request is classified before execution, and classification uncertainty or a routing error fails toward local execution, never toward the cloud.
That bet traded convenience for control. A single cloud subscription would have been simpler to run and would have given every task access to the strongest available reasoning by default. I gave that up: personal content cannot cross the external-model boundary unless it has been explicitly approved and transformed into an allowed format, synthetic fixtures, redacted structural examples, or aggregate telemetry. Cloud models may review process and architecture by default; reviewing sensitive content requires explicit approval. The boundary is enforced through code paths rather than written policy alone, exercised by 41 dedicated privacy and sovereignty tests, so the rule is a verified code path instead of a document nobody rereads.
What shipped
On top of that foundation the system operates as one connected environment. Private routing classifies every request and sends sensitive or recalled personal information to local models. Large-scale retrieval covers more than 67,000 indexed knowledge chunks across 19 sources, with scoped search, deduplication, incremental reindexing, offline-source tolerance, stale-document annotation, and provenance-aware results. Persistent memory distills completed sessions into structured memory, and a recalled private item forces the entire request back onto local infrastructure. Task execution runs on durable queues with retry and blocked states, multi-agent decomposition, parallel research, and compact-and-continue for work that outlives one context window. Local voice reaches approximately 115 milliseconds to first content when warm, through a complete local speech-to-speech path plus a separate desktop dictation application, with audio processing and inference kept on local hardware.
A second frontier model serves as an independent planning and review layer, operating through a read-only interface with schema-controlled output and file-level citations, and its recommendations are adjudicated by the primary orchestrator before anything is acted on.
Measured outcome
The current system runs more than 67,000 indexed knowledge chunks across 19 sources, 41 dedicated privacy tests, 251 passing evaluation cases across self-test, retrieval, and recall (93 of 93 system self-tests, 104 of 104 retrieval cases, and 54 of 54 memory and recall cases), 43 historical sessions backfilled into structured memory, more than 210 recorded operating decisions, and a warm local voice path at approximately 115 milliseconds to first content. In initial production exercises, the independent review layer achieved 7 of 7 precision with zero false positives, and a planning exercise then surfaced a real schema incompatibility in the review interface itself, which was corrected and re-tested before the interface was expanded. Task queues, retrieval, memory, voice, and multi-model review workflows are all production-tested.
What I would do differently
Three production incidents exposed the same pattern: the failures came from infrastructure edges I had not tested, not from the model reasoning itself. A platform-specific path-format inconsistency caused deep scoped searches to silently return nothing until the indexer was corrected and all 67,394 existing chunks were migrated in place. A nightly evaluation process generated reports that a silent downstream failure left unread, so review freshness had to be added after the fact instead of on day one. A shell-specific argument-handling issue stripped quotation marks during model handoff and required moving prompt delivery from command arguments to standard input. If I rebuilt this, I would build the freshness monitoring and self-test coverage for these infrastructure seams in from the start instead of writing each one as a regression test after it had already failed once in production.
Why it transfers
Engineering and construction organizations face the same underlying problems this system was built to solve. Project knowledge is fragmented across files, email, software, and individual employees. Proposals and reports require repeated reconstruction of information the organization already has. Senior judgment is concentrated in a small number of people. AI experimentation happens without clear data or approval boundaries, automations accumulate as isolated scripts, and the same lessons are repeatedly rediscovered.
The transferable opportunity is an internal AI layer with the same properties demonstrated here: connect fragmented knowledge across proposals, project records, correspondence, and prior decisions with provenance intact; define the data and approval boundaries in code so confidential content stays on controlled infrastructure while external reasoning is still available where it is safe; and make judgment reusable and failures permanent, so settled decisions carry forward and incidents become regression tests, approval gates, and operating standards instead of repeat costs.
Qualified professionals keep technical and commercial approval; the system does the connecting, checking, and remembering that no one has time to do by hand.
Public disclosure note. This case study describes architecture, capabilities, generalized failure modes, and verified system metrics. It intentionally excludes personal content, private source documents, credentials and network details, identifying project information, sensitive prompts, internal file contents, and security-sensitive implementation specifics.
Josiah Bujanda, AI Product Manager. Four years owning 0-to-1 AI products from discovery through launch, backed by ten years leading high-stakes commercial construction work.
Construction AI • AI Systems Architecture • Workflow Automation • Business Systems Integration