Building Apex: My Automated Personal Executive

  • Node.js
  • TypeScript
  • Claude API
  • Shell

As software engineers, our job is rapidly shifting from writing boilerplate to designing systems, managing state, and enforcing boundaries around non-deterministic components.

I built Apex (Automated Personal Executive) as a personal testbed to explore these exact challenges. It is a multi-channel orchestration engine that handles context switching across email, calendar management, research, and project scaffolding.

Here is how the system is designed, the constraints I put in place to make it reliable, and what building it taught me about practical AI engineering.

System Design & Infrastructure

The core goal was to build a unified system that operates across existing interfaces with persistent memory, rather than relying on isolated chat sessions.

The architecture consists of three main operational tiers:

Key Architecture Choices

Security & Guardrails

Integrating AI into personal workflows carries operational risk. The real engineering work lies in designing clear trust boundaries:

Core Execution Workflows

1. Context Aggregation (/briefing)

The main engine queries the Google Calendar API, fetches unread emails needing response metadata via the Gmail API, and reads active markdown tasks from Obsidian. It synthesizes this data into a concise, prioritized action list delivered straight to mobile.

2. Isolated Project Scaffolding (/build)

When given a feature description, a specialized Builder sub-agent scaffolds a fresh local directory, injects base constraints via a reusable UI layout module, writes standard frontend code, and executes an initial Git commit without cluttering the main agent's working context.

3. Structured Data Processing (/prospect-trade & /outreach)

For business development workflows in my web agency (Set the Pace Designs), the system executes a two-step pipeline:

Key Takeaways for Production AI

Building and relying on this system daily highlighted several truths about working with LLMs in real environments:

  1. Architecture Over Prompt Engineering: Reliable systems come from clean routing, strict schemas, and isolated execution scopes, not endless prompt tweaking.
  2. Deterministic Guardrails are Mandatory: Non-deterministic models should never have unmediated access to destructive or outbound APIs. Restricting capabilities increases real-world utility by making the system safe to run.
  3. Output Real Files, Not Just Chat Replies: A chat window is temporary. Real value comes from having the AI generate permanent, structured files you can actually use later—like Git repositories, Markdown notes, or CSV databases.

Technical Summary

Command & Routing Map