I run a startup, freelance on the side, write a book, plan a conference, and maintain half a dozen active projects. My context switching penalty is brutal. So I did what any engineer would do: I built a system where Claude manages the operational overhead for me.

This isn’t a prompt engineering post. This is about infrastructure. Persistent memory, a pipeline dashboard, custom skills, and automation that lets Claude operate as an executive administrator across sessions, projects, and tools.

What “Executive Administrator” Actually Means

An executive admin doesn’t just take notes. They maintain systems, track follow-ups, draft communications, manage a pipeline, and surface the right information at the right time without being asked. The key word is “persistent.” A good admin remembers that you passed on a lead last week and doesn’t resurface it. They know your preferences, your writing voice, your active deadlines.

Claude out of the box doesn’t do any of this. Every session starts fresh. No memory of yesterday’s architecture decision, no awareness of the proposal you drafted last Tuesday, no concept of your active job pipeline. You get a brilliant colleague with amnesia.

The fix is three layers: memory, tools, and automation.

Layer 1: Total Recall (Persistent Memory)

The foundation is a session memory system I built in about 400 lines of Python. Every Claude Code conversation gets ingested into a SQLite knowledge graph with hybrid search (keyword + semantic), conversation DAG traversal, and cross-session linking. I wrote about the technical details in a separate post.

The practical effect: I open a fresh Claude Code session, type “where were we?” and get this:

“We were working on the Arachne CLI chat command. Specifically fixing name resolution so users can reference agents by artifact name rather than just deployment name. The last change strips the org prefix when matching by artifact name…”

Compare that to a fresh session without memory:

“It looks like this is a fresh session, so I don’t have any context from a previous conversation to pick up from. What were you working on?”

Same model, same day. The only difference is 25K+ indexed conversation chunks searchable in under a second. This is the layer that makes everything else possible, because without continuity, Claude can’t be an admin. It can only be a temp.

Layer 2: Teletron-1 (The Dashboard)

Memory gives Claude context. But an admin needs tools. Teletron-1 is a local pipeline dashboard (Python, SQLite, vanilla JS) that serves as the operational hub. It runs at localhost:8081 and tracks:

• Job leads scored and tiered automatically by a Playwright-based monitor that scrapes Upwork and LinkedIn on a schedule
• Application tracking with status, next actions, and follow-up dates
• Task management in a persistent sidebar
• Competitive intelligence and a project portfolio

The dashboard has an API, which is the important part. Every operation (add a job, draft a proposal, update a task, change application status) is a REST endpoint. That means Claude can operate the dashboard programmatically through skills.

Layer 3: Skills (Claude’s Toolkit)

Claude Code supports custom skills: markdown files that teach Claude how to perform specific operations. I set up four:

/add-job adds a job to the pipeline. When I’m evaluating an Upwork posting in conversation, Claude can add it directly to the database instead of me copying URLs into a spreadsheet.

/draft-proposal drafts a proposal for a job and saves it to the database with versioning. Claude reads the job details, considers my background, and writes a tailored proposal. I review, edit in the WYSIWYG markdown editor on the dashboard, and submit.

/task manages the task sidebar. “Add a task to follow up with the Deel pitch competition by April 25” becomes a tracked item visible in both the CLI and the dashboard.

/recall queries session memory directly. “What did we decide about the WebSocket refactor?” pulls the actual conversation where that decision was made.

Each skill is a thin wrapper around a curl command to the local API. The skill file tells Claude what parameters to extract and how to call the endpoint. Here’s what /add-job looks like in practice:

/add-job "SaaS Voice Agent" https://upwork.com/jobs/... upwork hot

Claude parses the arguments, POSTs to localhost:8081/api/jobs, and confirms the job was added. It shows up in the dashboard immediately.

The Workflow

Here’s what a typical morning looks like:

1. Open Claude Code. Type “where were we?” Claude queries session memory and picks up the thread.

2. The Upwork monitor ran overnight. I check the dashboard for new hot leads, or just ask Claude: “any new hot leads?”

3. I find an interesting posting. “Give me a go/no go on this project” with the URL. Claude opens it in Chrome (via the browser automation MCP), reads the posting, evaluates the client history, and gives a recommendation calibrated to my strategy (quick wins for profile building, not max revenue).

4. If it’s a go: /add-job to track it, /draft-proposal to write the cover letter. Claude drafts, I review in the EasyMDE editor, adjust, and submit on Upwork.

5. /task "Follow up on voice agent proposal" --due 2026-04-02 --project upwork to track the follow-up.

6. Switch to Arachne development. Claude already knows the full project context because session memory spans projects. No re-explanation needed.

The key insight: none of these tools are individually impressive. A dashboard, a task list, a memory system, a few curl wrappers. What makes it work is that they compose into a coherent system where Claude has persistent state, operational tools, and enough context to make judgment calls.

What You Need to Build This

The full stack:

• Claude Code (Max plan for the long context window, but Pro works too)
• Python 3.13 and SQLite (session memory, dashboard)
• Ollama with nomic-embed-text (local embeddings, no API keys)
• Playwright (job monitoring, optional)
• CLAUDE.md that teaches Claude how to use your tools

The session memory system is open source at github.com/aguywithcode/total-recall. The dashboard and skills are specific to my workflow, but the pattern generalizes: give Claude an API to call, write a skill that teaches it the endpoints, and let it operate.

The Counterintuitive Part

The thing that surprised me most: the bottleneck isn’t Claude’s capability. It’s the infrastructure around it. Claude can draft a perfect proposal, but only if it has the job details, your background, and your strategic preferences loaded into context. It can track your tasks, but only if there’s a persistent store it can read and write.

Once you build the infrastructure, Claude stops being a chatbot you prompt and starts being a system you collaborate with. The difference is continuity. An admin who forgets everything every morning isn’t an admin. An admin with a filing cabinet, a calendar, and institutional memory is a force multiplier.

That’s what this setup is: the filing cabinet.