I built an AI chief of staff for my college admissions practice.
The Morganelli Method OS: three agents that collaborate to triage email, draft post-meeting follow-ups, and surface what needs my attention. Production-grade infrastructure on Render with Postgres, automated testing, and self-healing health checks. An actual product, not a side project.
Source of truth: the OS student record, PAGES, dossiers, calendar grid, commitments, and portfolio sections. The Master Client List is frozen as a historical baseline as of 2026-06-25.
The bottleneck was never the work. It was the email.
I run Ivy League Admissions — a college admissions consulting practice. Fifty to a hundred substantive emails a day. Strategy sessions with high-stakes families. Portfolios that need to stay current as students evolve.
The bottleneck was never quality of thinking. It was finding hours in the day to keep up with the volume. So I built a multi-agent system that mirrors how I actually run the practice. It doesn't replace my judgment — every email it drafts gets my review before it goes out. But it removes the fixed cost of triage, draft assembly, and post-meeting follow-up that was eating my mornings.
Three agents. One team.
The system mirrors how I'd staff a real practice: a chief of staff at the top, two specialists reporting in. Each has a defined role, what they handle, and explicit boundaries.
Chief of Staff
Chief of Staff sits above the other agents. She produces a morning briefing in my voice, names specific stale items by student, proposes new voice rules when she detects patterns in my edits, and accepts actionable chat commands — "mark Jordan's flag handled", "kill the stale drafts" — that I confirm with a single click.
She's the layer that turns the other agents' raw activity into something I can scan in ten seconds and act on.
Email Agent
Email Agent triages every inbound email through a categorizer (22 buckets), a router that decides draft-or-flag, and a drafter that produces the actual reply.
Her drafter sees the full Gmail thread, my last 10 messages to that sender, the matched student's complete portfolio, recent strategy meeting summaries, and 15 of my recent sent emails as voice anchors.
Meeting Agent
Meeting Agent owns post-meeting follow-up. When a Read.ai transcript hits the webhook, he summarizes the meeting, drafts the follow-up email in my voice, and detects strategic shifts that need to be reflected in the student's portfolio.
New ED choices, major direction changes, research pivots — those shifts become proposed Strategic Notes updates I approve or reject from the dashboard.
One email, end to end.
Every inbound email follows the same path. Here's what happens between the moment it lands in the inbox and the moment a draft appears for my review.
The dotted path is the audit trail. Every email gets a Postgres row with the categorizer's reasoning, the draft body, the model cost, and (after I send) the diff between Email Agent's version and mine. That diff is what feeds the voice-rule learner.
A clever script can't be trusted with my client communication. A real product can.
Built like a real product, not a clever script.
The agents are the visible layer. Underneath is the discipline that makes them safe to actually trust with my inbox every day.
Render + Postgres
Five services on Render — a web dashboard, three cron jobs (morning, hourly, weekly), and an OAuth health check. Postgres backs every persistent piece of state: emails processed, drafts, learning examples, audit logs.
Self-healing checks
A health-check cron runs every 15 minutes, probing OAuth refresh + the Gmail API. Failures surface in the morning briefing before any downstream cascade. An autonomous doctor playbook diagnoses common failure modes and fixes the ones it can.
Cost ceilings + SLOs
Daily spend cap stops the agents before they exceed budget. Per-call cost telemetry feeds an SLO dashboard. I can see exactly what each draft costs, which categories are getting heavily edited, and which voice rules need tuning.
Audit trail + tests
Every email Email Agent touches gets a Postgres row with the categorizer's reasoning, confidence, the draft, and (after I send) the diff between her version and mine. Code changes ship through PRs with automated test runs before they hit production.
The infrastructure isn't engineering for its own sake.
The temptation with this kind of system is to make it a clever script — wire up a few prompts, paste in your inbox, hope for the best. I went the other way on purpose.
The audit trail means I can answer the question "did Email Agent actually look at that portfolio before drafting?" with a database query, not a guess. The cost ceiling means a runaway prompt can't quietly cost me hundreds of dollars overnight. The self-critique pass and the voice-rule learning loop mean it gets better at my voice without me sitting down to manually fine-tune anything.
The point is so I can actually use this thing every day without losing sleep over what it might do behind my back.
I didn't write the code. I ran the product.
I'm not a developer. I built this with Claude Code as my engineering team — directing what to build, reviewing every output, testing it in my actual inbox, and iterating until each piece met the bar.
Across about three weeks and 320 commits, I put in roughly 100 hours of hands-on time. A senior full-stack engineer with AI experience would have spent 700–1,000 hours to build the same surface area from scratch. The work that compressed was the code. The work that didn't is what I did.
The four jobs that don't compress
Deciding that an agent network — not one mega-agent — was the right shape. That Chief of Staff should learn from feedback. That meetings, emails, and student state are all the same problem.
Knowing what a good draft looks like in this practice. Which emails are safe to auto-draft, which need a flag. What "ED choice changed" means downstream for a student's portfolio.
Approving voice samples one by one. Deciding what I sound like — and what I don't. A developer literally cannot do this for me.
Every draft hit my actual inbox. Every Meeting Agent summary came off a real student meeting. I am the test environment — when something breaks, I catch it because I'm the user.
I'm not 10× more productive than a developer. I'm doing a different job entirely. A developer would still need a product manager, a designer, a domain expert, and a QA person standing next to them. I'm all of those — and the AI is the developer.
See it running
The dashboard is behind a login — this is my actual production system, not a demo. The architecture above is what you'll find if you build something like it.
Open the dashboard