Agentic Chief of Staff

Challenge

One person running a growing set of AI-assisted workflows needed something closer to a chief of staff than a chatbot: commitment tracking, automatic meeting prep, email drafted in the user’s voice, and a daily briefing. It had to deploy inside a Fortune 500 environment under locked-down IT controls. So the AI is the runtime: no server, no database, no application code beyond the Claude app. Everything lives in structured markdown the model reads in a defined boot order, which is why it deploys at scale with zero IT involvement.

Process

Five layers. An identity file holds operating principles, voice registers, and hard never-do rules, auditable and editable without code. At session open, a boot loader reads all other context in a defined order, leads with the most urgent item, and runs boot checks: an agent-to-agent inbox relay, a heartbeat on background services, and a memory-freshness audit. Context is layered by rate of change (slow organizational context, weekly priorities, an append-only commitment log, a session-handoff file), so one stale file can’t rot the system. Skills are markdown files with a name, a trigger description, and instructions; any user can drag one in to add it or delete it to remove it. Roughly 30 skills fire on a spoken phrase, a schedule, or an event such as a meeting ending, covering the daily briefing, meeting prep, commitment tracking, voice-aware email drafting that never sends without human review, and self-maintenance. Memory is one fact per file. A consolidation pass runs only after both a time threshold and a session-count threshold are crossed, merging duplicates, pruning stale facts, and promoting recurring patterns.

Self-install and self-repair were first-class problems. Install is dragging one file into the app and saying “set this up.” An onboarding interview captures role, stakeholders, projects, and communication style, and role tier filters connector scope and skills at install so nobody loads what they don’t need. Compliance guardrails (a no-auto-send rule, the enterprise data-classification policy) sit in a protected organizational layer, apart from the personal layer the user fully controls. Upgrades apply only the delta and never touch personal context. Broken installs are diagnosed and repaired with the user’s consent instead of handed back to debug, and “fix my setup” runs the first-install path. Behind this is a deduplicated 19-issue failure catalog from real community installs, and one rule: silent failure is the enemy. Nothing is declared live until a test file is written and read back on both storage paths.

I also scoped a fleet layer. Thin local agents send structured issue reports to a central intake, a triage agent classifies and routes each to a specialist, and a curator agent prunes superseded fixes and flags any that quietly stopped working. The design calls this roughly 70% buildable today and names the platform blockers. Silent pushes to every install aren’t possible, so upgrades are consent-based: the system detects it’s behind, shows a one-line nudge at boot, and upgrades when the user says so. Versioning follows the org chart: a base OS, plus a role module (individual contributor, manager, director, or senior-leader), plus a department module. Each tier scopes connector permissions and skills and has one canonical distributable at a single share link, updated by delta only. The scale-ready bar: a colleague given only the link installs it with no follow-up call.

It is cross-platform from day one, with no shell-only install or repair steps. An executable release gate, built after one documentation-drift failure, diffs live skill files against the distributable template on every version bump and blocks the release on drift. A seven-layer pre-ship audit on top of it has closed 45 findings across seven rounds, including three personal-name leaks in templates caught before they reached downstream installs. Because it runs as one long-lived session, transcripts are snapshotted before any context compaction. A deterministic pre-tool hook blocks any command containing a raw credential. Its stated limit is a secret pasted directly into chat, which is handled behaviorally.

Result

It grew from one personal instance to a small community of colleague installs, with a director as design partner for the senior-leader tier, and has been demonstrated to senior leadership. A dedicated SME-review agent, run on a live training deck before it went to the team, caught two critical defects a straightforward proofread missed.

Every capability was built around a verified platform constraint, and the designs state what isn’t buildable yet and why. It is internal tooling for a specific team, not a commercial product. It maintains itself (memory consolidation, the drift-blocking release gate, consent-based self-repair, a curator pruning its own knowledge base) because a system that quietly rots is a liability.