How I build
Context Engineering + Agentic Execution
How one founder ships at the pace of a full engineering team: by structuring information so AI agents can do complex work with little intervention.
The Automation Levels
AI writes code, human integrates everything.
GitHub Copilot autocomplete, manual file management, no structure. Each file change meant switching between editor, terminal, and documentation. Useful for line-level suggestions, but no architectural awareness.
AI edits files, human runs commands.
Windsurf for intelligent editing. VS Code Copilot for inline suggestions. Google’s Project Antigravity for multi-agent experiments. Each tool taught something. Antigravity showed the promise of agent orchestration, and Windsurf proved that AI could manage multi-file edits. None delivered a structured, mission-driven pipeline for production code.
Key learning: the bottleneck was context management, not code generation.
Claude Code executes missions. Human plans, approves, pushes.
The breakthrough. Claude Code turned “AI helps a coder” into “an architect directs an engineering team.” The core workflow crystallised: /start → /architect → /engineer → /summarise. Mission files became contracts: self-contained specs that agents execute line by line. The Golden Path rules emerged here too. Package imports only, no Navigator.push, no setState, surgical migrations, dart analyze zero errors.
TrekMeet went from concept to Google Play Beta in this phase. 60+ missions shipped across 10 sprints.
Currently at 4.2 · Phase 11-H · R2 launched
Post-commit QA live. Multi-agent coordination. Diagnostic subagents.
Post-commit QA automation is live. Every commit triggers dart analyze and flutter build into a structured JSON report, read by /CTO before push approval. The system proved itself through the R2 launch rotation (June 2026): ~17 missions shipped across the production cutover and a multi-cycle iOS push saga, all under V-gate smoke discipline, every decision persisted to decisions.log.
Agent coordination is formalised via the 2-scratchpad model. For each mission topic, /Architect writes the plan scratchpad and /CTO writes the sign-off scratchpad; strict ownership prevents merge conflicts when missions run in parallel. The skill pipeline has grown from 4 commands to 12: /start, /architect, /engineer, /summarise, /sprint, /phase, /audit, /handover, /cto, /qa, /qa-review, /fixer.
Diagnostic subagents run narrowing disable-and-reproduce tests before fixes land, catching the cases where theory doesn’t match reality.
The Agent Team
/Architect
Plans every mission. Reads context, drafts the step-by-step contract, then hard-stops for sign-off. Never writes code; separation of concerns is the discipline.
/Engineer
Implements the mission, runs the build gates, commits and reports. Touches only the files the contract names.
/CTO
Reviews plans, signs off, owns rotation close-outs via /handover. Catches citation drift before the engineer touches a file.
/UX Partner
Writes the UX specs missions build from. Stored in docs, integrated into the backlog.
/QA
Reads screenshots and debug logs from device testing, and prepares structured reports for triage.
Claude Code
The engine underneath. Every agent above runs as a Claude Code session with MCP access to the live backends.
MCP — Backend Access
How Context Survives Across Sessions
Backlog volume is the easy part; agents handle that. The harder problem is preventing context bloat as the codebase grows. Three mechanisms keep per-session context bounded:
Canonical state files
A small set of always-loaded files (a few KB) hold cross-session truth: current phase, mission state, active blockers. Regenerated each rotation, never appended.
Domain rules that auto-load on touch
Architecture rules load only when their matching code is touched, so an agent editing the map layer never carries the auth rules it doesn’t need.
Phase-boundary archiving
At each phase close, history is swept to an append-only log and the hot state is re-projected. The working context stays small even as the project history grows large.
The Bottleneck
Most of the build is already handled. The part still being solved is removing the founder as the heartbeat, the human who triggers each rotation. Right now the system holds state, plans, builds, and records on its own, but a person still starts the loop. Level 5 onward is about that loop running on its own cadence. That is the real work between here and a Solo Founder Operating System.
Full autonomous loop: plan, build, test, deploy.
The engineering pipeline runs end-to-end without human message bussing. Sprint planning, mission generation, implementation, testing, and deployment happen as a continuous loop. The founder reviews results and makes product decisions; the agents handle the rest. The trekmeet-agent-framework gets extracted as a reusable toolkit, so the method can outlive one product.
Multi-department agent orchestration. One founder, zero staff, two hours per day.
The endgame is an automated organisation, not only an automated engineering team. Engineering, QA, UX, community moderation, support, and growth each get a specialised agent. The founder starts the day with a Command Centre briefing: overnight metrics, pending actions with confidence levels, agent recommendations. Review each department, approve or adjust, and the agents execute.
Virtual Departments
Engineering
Backlog management, bug triage, sprint execution, build monitoring.
Product & UX
Feature proposals from user feedback, UX specs, A/B test analysis.
Community
Content moderation, group approvals, dispute escalation.
Growth & Support
User acquisition, App Store optimisation, auto-categorised enquiries.
Self-healing agents monitor production health. Hotfix proposals auto-queue. UX validation agents compare deployed screens against specs, and sprint retrospectives generate themselves from mission metrics. The framework becomes extractable: a repeatable system for any solo founder building with AI agents.
Live Session
Anatomy of a Mission
Every feature is a contract.
A mission file is the only context an executing agent receives. If something is ambiguous in the mission, the agent will guess wrong. Precision is the methodology.
Objective
One paragraph on the what and the why. No implementation detail here.
Architecture Decision
Pattern choices locked before execution begins. Agents must not freelance.
Infrastructure: CEO Parallel Work
Supabase SQL, dashboard config, RLS policies. Runs while the agent builds.
Agent Steps (Numbered)
File path, exact changes, imports, before/after code blocks. Max 30KB or split.
Do Not Touch
An explicit list of files and patterns the agent must not modify. Prevents scope creep.
Verification Checklist
dart analyze zero errors, flutter build passes, manual test steps on device.
Risk Register
What could go wrong, and the mitigation. The agent knows its failure modes in advance.
This method took TrekMeet from zero to Google Play in 3 months.
The app is the proof. Next comes extracting the framework so it works beyond one product.