I build tools, stories, and small systems that make room to create.

What the system does: Text and voice interfaces, retained context, coordination code and local status checks.

My role: I set the expectations, personality, capabilities and what useful assistance should actually feel like.

Evidence and limits: Sierra's Python application, voice launcher, state files and smoke tests exist locally. Individual integrations need ongoing verification.

What this project taught me: A useful personal assistant needs continuity and context, not just a good answer in a single conversation.

What the system does: Role registry, recorded sessions, approvals, handoffs, provenance and SQLite audit records.

My role: I designed the collaboration model and decision rules, with final approval kept in my hands.

Evidence and limits: Standalone AI Council codebase, database schema and tests exist. The complete integration with all live agents remains unfinished.

What this project taught me: Multiple agents need defined roles, traceable recommendations, and a clear owner-approval process.

What the system does: Local inspection, bounded agent execution paths, Codex-based experiments, repo tools and workflow integration.

My role: I determine what should be automated, approve the scope and verify whether the work actually happened.

Evidence and limits: Local Dex and Bunker components are present. Execution permissions differ by tool path; a fully autonomous reliable agent is not yet claimed.

What this project taught me: Delegating a task is not the same as verifying it finished; the system must show what actually happened.

The problem: Appointment setting is repetitive and demands constant attention. I wanted to explore whether an AI agent could hold the initial conversation and automate the administrative handoff.

What I worked on: An ElevenLabs conversational agent using the Stan persona for Midtown HR/PEO prospecting, combined with an n8n appointment workflow. The conversation design covered SPIN-style discovery, concise responses, objections, and the planned calendar tools get_available_time and book_meeting.

My role: Defined the caller persona, lead qualification logic, appointment objective and tool behavior; iterated on conversational prompts and the workflow during prototype testing.

Evidence and limits: The conversation specification and tool requirements are retained in the Bunker. I tested a working prototype, but it was never made live. There is no verified production booking history or public demo linked here; the current n8n export was not located in the local project inventory.

What this project taught me: AI doesn't just need to sound natural. The conversation, handoff tools and appointment confirmation must be designed as one coherent experience.

What the system does: Original-footage cataloging, proxy and audio prep, transcripts, edit decisions, draft sequences, review exports and owner approval.

My role: I define the story, editing priorities and review criteria, then direct AI-assisted work and test the results.

Evidence and limits: Multiple long-form rough cuts and episode packages exist on the F: drive. Final music, audio review and publish approvals are still case-by-case.

What this project taught me: The rough cut is only one milestone. Music, real dialogue, pacing, and review still matter.

What the system does: Transcript-based candidate selection, ranking, vertical reframing, burned captions and review before release. The general clipping tool and KM51-specific clipper have distinct goals.

My role: I specify how a good clip should behave, which audience it serves and how much manual editing the pipeline should replace.

Evidence and limits: General and KM51 clipping apps passed local health checks; rendered vertical clips are on disk. Unlimited, end-to-end unattended publishing is not claimed.

What this project taught me: A short made to drive people to a full video needs different scoring than a self-contained clip.

What the system does: Gameplay direction, progression changes, browser/mobile simulation and iterative prototypes.

My role: I define the feel of the game, request mechanics, review versions and make the call on what changes next.

Evidence and limits: 25 configured stages, two original tracks and published browser-test evidence. Real handset feel still needs validation.

What this project taught me: Simulation tests can check timing, but the feel of a game still needs real hands-on playtesting.

What the system does: Product rules, time-entry screens, project rates, Android packaging and testing. No live billing or commercial release yet.

My role: I set the product direction, requested changes, tested rate behavior and shaped the pricing concept.

Evidence and limits: Android debug APK, recorded 44/44 isolated web tests and separate on-device verification.

What this project taught me: Details like project-specific pay rates have to behave predictably; even small rules change the experience.

What the system does: Customer, contractor and administrator flows, bidding, acceptance, chat and wallet/commission logic.

My role: I define the opportunity, user flows, business logic and feature priorities.

Evidence and limits: React Native/Expo and FastAPI/MongoDB source and project specifications exist. This is not presented as a public commercial launch.

What this project taught me: A marketplace is more than a listing page: trust, bidding, chat, commissions, and local payment realities all affect the flow.