Agentic Chief of Staff

Challenge

A single person handling a growing set of AI-assisted workflows needed something closer to a chief of staff than a chatbot: a system that tracks commitments, preps meetings automatically, drafts email in the user’s voice, and runs a daily briefing, all while deploying inside a Fortune 500 environment governed by admin-locked tool approvals and identity-policy constraints. That constraint set forced the central architectural bet: the AI itself is the runtime. There is no server, no database, and no application code to install beyond the Claude app itself. Everything the assistant knows or does lives in structured markdown files that the model reads in a defined boot order, which is the entire reason it can deploy at scale with zero IT involvement.

Process

The system is five layers. An identity file holds the agent’s operating principles, voice registers, and hard never-do rules in one place, separate from everything else, which makes its behavior auditable and editable without touching code. A boot loader runs at session open, reads all other context in a defined order, and surfaces the single most urgent thing as its opening line; it also runs a set of boot-time checks, including an agent-to-agent inbox relay, a heartbeat check on background services, and a memory-freshness audit. Context itself is layered by how often it changes, slow organizational context, weekly priorities, an append-only commitment log, and a session-handoff file, so that no single stale file can rot the whole system. Skills are markdown, not code: a skill is a file with a name, a trigger description, and an instruction set, and any user can drag one in to add it or delete it to remove it. Roughly 30 skills fire off three trigger types, 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 a human looking at it first, and the system’s own self-maintenance. The fifth layer is memory: one fact per file, with a consolidation pass that is dual-gated, meaning it only runs once both a time threshold and a session-count threshold have been crossed, merging duplicates, pruning stale facts, and promoting patterns that keep recurring.

To turn a personal tool into something shippable, I treated self-install and self-repair as first-class problems, not afterthoughts. The entire user-facing install is dragging one file into the app and saying “set this up.” Under the hood, a structured onboarding interview populates the new user’s role, stakeholders, projects, and communication style, connector scope and the active skill set are filtered by role tier at install time so nobody loads a surface they don’t need, and compliance guardrails, including a no-auto-send rule and the enterprise data-classification policy, live in a protected organizational layer that is kept separate from the personal layer the user fully controls. Repair works the same way in reverse: upgrades apply only the delta and never touch personal context, a broken install is diagnosed and repaired with the user’s consent rather than handed back to them to debug, and “fix my setup” runs the identical path as a first install. That confidence is backed by a deduplicated 19-issue failure catalog assembled from real installs across the community, governed by one rule I hold above the rest: silent failure is the enemy, so the system writes a test file and reads it back on both storage paths before it will declare anything live.

Beyond a single install, I scoped an honest fleet layer into the design: thin local agents that write structured issue reports to a central intake, a triage agent that classifies each one and routes it to a specialist, and a curator agent that prunes fixes once they’re superseded and flags any fix that has quietly stopped working. The design states plainly that this is roughly 70% buildable today and names the exact blockers, admin-locked tool approvals and identity-policy constraints among them, rather than over-promising a fully autonomous fleet. The same platform reality turned consent-based upgrades from a limitation into a feature: because a silent push to every install is not possible, the system instead detects that it’s behind, surfaces a one-line nudge at boot, and only upgrades once the user says so. Versioning follows the org chart itself, a base OS plus a role module (individual contributor, manager, director, or senior-leader) plus a department module, with connector permissions and the active skill set scoped per tier and one canonical distributable per tier living at a single share link, updated by delta only. The bar for calling a release ready to scale is simple: forward the link to a colleague with no other context, and they install it with no follow-up call.

None of that held up without engineering discipline behind it. The system is cross-platform from day one, with no shell-only steps anywhere in the install or repair path. An executable release gate diffs the live skill files against the distributable template on every version bump and blocks the release step outright if they’ve drifted — a gate I built as the direct answer to a documentation-drift failure mode the system had already hit once. A broader seven-layer pre-ship audit runs on top of that gate and has closed 45 findings across seven rounds, including catching three personal-name leaks embedded in templates before they could propagate into every downstream install. Because the assistant runs as one long-lived session rather than cold-starting, transcript snapshots are taken before any context compaction, so nothing that mattered silently disappears. And a deterministic pre-tool hook blocks any command containing a raw credential before it runs, with its one honest limitation stated in the design itself: it cannot intercept a secret a person pastes directly into chat, so that case is handled behaviorally instead.

Result

The assistant went from a single personal instance to a small community of colleague installs, with a director serving as design partner for the senior-leader tier, and it has been demonstrated to senior leadership. Its review discipline extends past its own output: a dedicated SME-review agent was pointed at a live training deck before it went out to the team and caught two real critical defects that a straightforward proofread had missed, the clearest evidence that the review layer is catching genuine mistakes rather than rubber-stamping.

The system holds together because every capability was engineered around a verified platform constraint rather than an assumption, and the designs say plainly what is not buildable yet and why instead of over-promising. It is internal tooling built for a specific team, not a commercial product, and it is built to maintain itself, through memory consolidation, the drift-blocking release gate, consent-based self-repair, and a curator that prunes its own knowledge base, because a system that quietly rots is a liability the design refuses to accept.