Dashboards and Personal Assistants

Once the cortex/spine architecture was running across three projects, I hit a practical problem: I couldn't keep it all in my head anymore.

Three apps. Three knowledge stores. Three sets of CLAUDE.md files, three domains of documentation, three codebases with different stacks and different deployment pipelines. I was constantly context-switching, bouncing between terminal sessions, trying to remember which agent had which context loaded and whether the last build had passed. It was working, technically. But switching between three projects with three sets of everything was getting unwieldy.

build.ai: The Dashboard

build.ai started as a dashboard. A simple React app where I could see all my projects in one place, check their harness state, and maybe kick off a build. I spun it up with Vite + React + Express, backed by Neon PostgreSQL, and figured I'd have something basic running in a weekend.

It grew from there.

The first version showed project cards with status indicators. Green for healthy, amber for pending work, red for broken builds. Within a week I'd added the ability to dispatch work to agents directly from the interface. Submit a request, describe what you need, and build.ai would spin up a Claude Code CLI session with the right context already loaded. I could watch the agent work in real-time, streaming output line by line.

Then I added request decomposition. A single request like "add offline caching to the way2fly logbook" would get broken into a phased pipeline:

Discovery  →  Design  →  Specs  →  Build  →  Wire  →  Adapt  →  E2E  →  Deploy

Each phase had its own context requirements, its own validation criteria, its own agent session. The agents didn't just execute blindly — they pulled context from the knowledge layer at each phase. Discovery would read the domain cortex to understand what offline caching means for skydivers. Design would reference the UI conventions. Specs would validate against the existing API contracts.

The request pipeline became central to how I worked. Requests come in — from me, from user feedback, from the assistant detecting pain points — and flow through the pipeline with full traceability. Every phase produces artifacts. Every artifact is versioned. Every agent session is logged. Essentially CI/CD, but for AI-powered development itself.

marco.ai: The Assistant That Manages the Assistants

While build.ai handled orchestration, I had a different problem for daily life. I was maintaining harness files not just for my three consumer apps, but for personal domains too. Skydiving progression tracking. Fitness programming. Financial planning. Every time I wanted to update a knowledge file, I'd open an editor, find the file, make the change, and hope I hadn't broken the markdown structure that the AI sessions depended on.

So I built marco.ai — a personal assistant with one key capability: it could read and write the knowledge files that powered all the other AI sessions.

marco.ai wasn't just a chatbot that answered questions. It managed the knowledge files across all projects. When I learned something new about canopy piloting and wanted to update the way2fly domain cortex, I'd tell marco.ai. When my training schedule shifted and the way2move fitness harness needed updating, I'd tell marco.ai. It understood the file structure, the conventions, and the relationships between domains.

marco.ai had access to everything:

• Build harnesses — project cortex files, spine configs, CLAUDE.md for every repo
• Personal harnesses — skydiving progression, fitness, finance, life goals
• Operational context — deployment states, CI status, pending work items

It became the single conversational interface for my entire knowledge system. "What's the current state of way2save?" and "Am I on track for my A-license?" were equally valid questions, answered from the same underlying knowledge architecture.

The Multi-Tenant Idea

I was talking to a colleague about what I'd built — the cortex/spine structure, the assistants that read domain knowledge, the orchestration pipeline — and he asked:

"Could you set this up for our company?"

That's when I realized the structure wasn't specific to my projects. It could work for any company.

A hospitality chain gets their own "anatomy" — domain knowledge covering hotel operations, staff training procedures, guest experience protocols, seasonal pricing strategies. Their AI assistants don't just answer generic questions; they understand their business, their terminology, their processes.

A manufacturing firm gets theirs — safety protocols, quality checklists, compliance frameworks, equipment maintenance schedules. Same brain architecture. Completely different knowledge.

Same cortex/spine structure. Different domain knowledge. Multi-tenant AI assistants.

cortex.ai: The SaaS Concept

This became the concept for cortex.ai — a platform where any organization could deploy the same knowledge architecture I'd built for myself. Each tenant gets their own isolated knowledge store but benefits from shared structural patterns across all tenants. The cortex format, the spine conventions, the agent orchestration — those are the platform. The domain knowledge is the tenant's.

This idea — structuring organizational knowledge so AI assistants can reason over it effectively — is emerging across the industry under different names. KPMG calls it "knowledge engineering", Anthropic calls it "context engineering", and Martin Fowler calls it "harness engineering". I arrived at the same conclusion from the practitioner side, from trying to make three apps and a personal assistant all share a consistent knowledge architecture.

The Shape of the System

The layers were becoming visible. Consumer apps at the surface. An orchestration platform managing development. A personal assistant managing knowledge. And a SaaS concept that could bring the pattern to other teams.

But something felt off. I had six apps, a dashboard, a personal assistant, and a SaaS concept. The architecture was sound. The orchestration was working. The knowledge layer was doing what I'd designed it to do.

And yet I was still thinking about it wrong.

I was focused on the tools — the agents, the CLI, the API endpoints, the streaming output, the pipeline phases. I was building increasingly sophisticated ways to run AI agents and orchestrate their work. Tool after tool after tool.

The next realization shifted my perspective on the whole system.