Background
LLM-based coding agents have moved from novelty to daily tool — Claude Code, OpenAI Codex, and Google’s Gemini CLI all run in the terminal alongside the rest of a developer’s workflow. The interesting question is no longer whether to use them but how to make them dependable across many projects, many contexts, and many sessions.
This project is the working system I have built and refined to do that, applied to real engineering and consulting work every day.
The tooling stance — multi-tool, not single-vendor
I install and use three terminal-based AI agents in parallel: Claude Code, Codex, and Gemini CLI. Each has different strengths in reasoning depth, code generation, instruction-following, and tool-use behavior. Treating them as interchangeable hides those differences; treating them as separate tools with distinct lanes makes the whole stack more useful.
Homebrew manages installation and upgrades. A consistent shell environment means I can move from one tool to another mid-task without rebuilding context.
Repo-local instructions — the CLAUDE.md hierarchy
The single biggest lever on consistency is repo-local instruction files. I run a three-level guidance hierarchy:
- Global (
~/.claude/CLAUDE.md) — non-negotiable standards across every workspace: git hygiene, security, code review checklist, secrets management via 1Password CLI, journaling, portfolio awareness, blog capture - Workspace (
workspace/CLAUDE.md) — architecture, shared infrastructure, deployment, auth, logging, observability for everything inside a workspace - Project (
project/CLAUDE.md) — build commands, API docs, database tables, project-specific config
Each level adds specificity without overriding the level above. The global file is 500+ lines of standards refined over months of use. Workspace and project files inherit and extend. Fifteen-plus projects across personal and infrastructure work all run on this pattern.
The result: agents arrive at every conversation already knowing how I work, what I value, and what is non-negotiable. I do not re-explain my conventions every session.
Persistent memory — agents that remember across conversations
Default LLM context is conversation-scoped. The auto-memory system extends that across sessions through a file-backed memory store organized by type:
- User memories — role, goals, expertise, how I want to collaborate
- Feedback memories — corrections and confirmations, with the why so future sessions can judge edge cases
- Project memories — current initiatives, decisions, deadlines
- Reference memories — pointers to external systems
Each memory is its own markdown file with structured frontmatter. A MEMORY.md index lets the agent scan what is available before responding. Memories are read, written, and updated automatically based on conversation signals. The system is portable across the three CLI agents — it is a file convention, not a vendor lock-in.
This is what makes a coding agent useful for ongoing work rather than only one-off tasks.
MCP servers — turning AI into a real systems integrator
The Model Context Protocol lets AI agents call out to external systems through standardized tools. I use this extensively:
- Twenty-plus MCP wrapper scripts that launch vendor MCP servers with credentials injected at runtime from 1Password — covering operational tools (RMM, EDR, M365, identity, networking, DNS, email security, payments, brokerage, telephony, more). Secrets never live in MCP configuration files; the wrapper convention keeps every server safe to commit alongside the project.
- A standalone MCP server I built from scratch —
schwab-mcp, a TypeScript Node.js server that handles Schwab OAuth2, refresh-token lifecycle, and exposes account info, quotes, option chains, and order management as MCP tools. Standalone, with its own token storage and rotation. - A Plausible analytics MCP integration so I can query site traffic on my portfolio and blog from inside an agent conversation rather than switching to a dashboard.
The pattern is consistent: one wrapper script per vendor, one secret reference per credential, one place to rotate accounts or vaults.
Multi-tool evaluation — criteria, not opinions
When I compare Claude Code, Codex, and Gemini CLI, I do it against criteria, not vibes:
- Instruction-following depth — does the agent honor repo-local CLAUDE.md, or override it?
- Tool-use behavior — how does it choose between built-in tools and MCP servers, and does it batch parallel calls when independent?
- Reasoning vs. action — when given an ambiguous task, does it ask, plan, or jump?
- Memory-system fit — does it respect persistent-memory conventions across sessions?
- Cost and latency profile — for the kind of work I do most often
Different tools win on different dimensions. The point of running all three is that I can route a task to the one most likely to do it well, rather than defaulting to whichever I installed first.
What this enables, day to day
This is not a research project. The system runs across:
- Engineering work — full-stack development on Cloudflare Workers, Python services, Ansible automation, all with the same instruction patterns
- Consulting and operational work — MCP servers brought into client engagements for RMM, EDR, identity, and ticketing integrations
- Knowledge work — research, planning, writing, journaling, and blog drafting with persistent context across sessions
- Job search — application tailoring, materials build pipeline, and a job-scout tool that screens postings using LLM evaluation against my actual profile
The same conventions, memory, and MCP fabric apply across every one of those.
Why it matters
Most “I tried AI” demos are one-off chats. The shift that actually matters is when AI moves from chat to tool: repo-local, memory-persistent, integrated with the systems you already work in, and consistent enough to trust on real work. That requires conventions and infrastructure, not just a subscription.
This project is that infrastructure for me. It is also the reusable pattern I bring into engineering, consulting, and team work — the rules, the memory, the MCP fabric, the multi-tool stance — wherever the goal is “use AI on real work without losing the standards that make the work good.”