A worked example of autonomous system architecture.

Autonomous Agent Development

I built a personal AI executive team inside Claude Code with six named agents, role-based ownership, and an orchestrator. Here's how the system works and what I've learned designing it.

The Team

Luke's West Wing: an AI executive team org chart showing Luke at top, Charlie as strategic advisor, Leo as orchestrator, and four directors (Sam, CJ, Donna, Josh)

I named them after The West Wing. agent-Leo McGarry runs the orchestrator. agent-Sam Seaborn owns product and engineering. agent-CJ Craig handles marketing and growth. agent-Donna Moss runs career and job search. agent-Josh Lyman manages operations, calendar, and costs.

Then I added agent-Charlie Young, different from the others. The first five directors are executors: they own a lane and execute work in it. agent-Charlie is a thinking partner and strategist. He pattern-matches across the team, surfaces second-order effects, flags when something feels off, and owns the memory layer. Leo doesn't task Charlie with work. Leo brings Charlie in when the decision is hard or when you want a sharper second opinion before committing.

The org chart shows the structure. Beneath each director is the lane they own and the types of work they handle.

How I Designed It

Tight role ownership.

Each director owns one lane with no overlap. Vague roles produce vague output. Tight ownership produces work you can actually use. When agent-Donna handles a job application, she owns it end-to-end. When agent-CJ publishes marketing content, she owns positioning and distribution. agent-Sam owns the technical spec. If the work belongs to no one or to two people, you fragment your effort and spend cycles on handoff debates instead of making the work better.

An orchestrator, not a router.

agent-Leo doesn't just send tasks downhill. He coordinates handoffs between directors, decides when to bring in agent-Charlie for strategic input, and runs a protocol for when two lanes touch the same work. This was the biggest design win. Without the orchestrator, the agents would thrash around the edges trying to figure out who owns what. With it, I spend far less time babysitting the system and far more time using its output.

A thinking partner alongside the executors.

Most agentic systems are all execution. My agent team converged on adding one director whose only job is to think about how the whole team thinks. agent-Charlie reviews decisions before they lock, tracks what works and what doesn't, and surfaces patterns the individual directors might miss. It sounds like overhead. It turned out to be load-bearing.

How It Works in Practice

agent-Donna's job application system is one example of this architecture in action. One entry skill orchestrates the full lifecycle: job description intake, resume and cover letter generation, iteration, a structured audit, certification, interview prep, and mock interview. Seven specialist sidekicks handle each phase. The workflow diagram below shows the full journey and how each phase connects to the next.

flowchart TB classDef skill fill:#e8f0f7,stroke:#2c5f8a,stroke-width:2px,color:#1a1a1a classDef sidekick fill:#fff4e8,stroke:#b85c00,stroke-width:2px,color:#1a1a1a classDef file fill:#eaf5ea,stroke:#4a7c4a,stroke-width:1px,color:#1a1a1a classDef shared fill:#efeaf5,stroke:#6a5a8a,stroke-width:1px,color:#1a1a1a classDef user fill:#fff,stroke:#1a1a1a,stroke-width:2px,color:#1a1a1a User([User pastes JD + Company + Title]):::user User --> JobApp["/job-app"]:::skill User -. score only .-> JobFit["/job-fit"]:::skill JobApp --> Setup[["Create folder
JobApps/Company_Mon_YY/
Write jd.md"]] Setup --> P1[application-prep
APP.RUN]:::sidekick P1 --> F1[/"resume_v1.md
cover_letter_v1.md
audit_v1.md"/]:::file F1 -. iterate .-> P2[app-edit
APP.EDIT]:::sidekick P2 --> F2[/"resume_v{N+1}.md
cover_letter_v{N+1}.md
audit_v{N+1}.md"/]:::file F2 -. more edits .-> P2 F2 --> P3[app-qa
APP.QA]:::sidekick P3 --> F3[/"qa_package.md"/]:::file F3 --> P4[app-final
APP.FINAL]:::sidekick P4 --> F4[/"final_resume.md
final_cover_letter.md
confidence_score.md
LOCKED"/]:::file F4 --> P5[interview-prep]:::sidekick P5 --> F5[/"interview_guide.md"/]:::file F5 --> P6[mock-interview-voice]:::sidekick P6 --> F6[/"mock_interview_v{N}.md"/]:::file Setup -. anytime .-> P7[outreach-drafter]:::sidekick P7 --> F7[/"outreach_to_firstname_lastname.md"/]:::file T1[/"cover_letter_template.md
resume_director_template.md
resume_senior_pm_template.md"/]:::shared T1 -. reads .-> P1 T1 -. reads .-> P2 P1 -. status .-> S[(career_state.md)] P4 -. status .-> S P5 -. status .-> S

Mobile: scroll horizontally to see the full diagram.

The design choice that surprised me most: every application gets its own folder, and that folder holds everything the agents need. Job applications take multiple days with natural pause points. If the agents only held context in their own memory, I'd lose everything when I closed Claude and came back later. My agent team made the call to save everything to files. The folder becomes the source of truth. Before any sidekick acts, it reads the latest files. I can close Claude, come back days later, and the system picks up exactly where it left off. This pattern scales to hundreds of applications without needing a database.

Building this system taught me more about autonomous agent design than anything else I've worked on. The coordination overhead is real, and the role-ownership protocol matters more than I expected. If you're designing systems like this, I'm especially curious how you handle cross-lane decisions and keep handoffs clean without adding layers of approval overhead.