Every client's accounts, one command surface.
Agency Multi-Account Command runs your whole client book through one orchestrated daily cycle, each client's accounts on their own voice, on their own staggered schedule, with their content and metrics walled off from every other client's, and one portfolio view that tells you the state of the book at a glance. Nothing posts, and nothing bills, without a human saying go.
Run one client through the command cycle See the portfolio view and a gate log
THE PROBLEM
An agency at even ten clients is drowning in tabs. Every client has three or four platforms, their own voice, their own cadence, and their own line you cannot cross, and the tooling answer so far has been either a dashboard with more tabs (you still do everything, just in one window), a bench of account managers copy-pasting between dashboards (cost, drift, and one bad Tuesday away from posting client A's take on client B's account), or an auto-posting growth tool that gets the whole network flagged because forty accounts moved at the same minute in the same way. The failure modes are all expensive in the same currency, trust. One off-voice post, one leaked cross-client metric, one synchronized burst, and the retainer conversation changes.
HOW IT WORKS
The substrate is a fleet orchestrator that already exists (it is how AYA runs its own thirteen internal accounts), and the agency layer is a roster, not a rebuild. You add a client as a row: their accounts, their brand voice binding, their isolation group, their report cadence. The daily cycle then builds a staggered schedule (accounts never post in a detectable synchronized burst), distributes content topics so no two accounts flood the same take, runs each account's session in its window, and aggregates the metrics, scoped to each client's isolation group and never across it. Isolation is fail-closed: if a client's boundary is missing or ambiguous, that account is skipped and flagged, never posted cross-client. And the gate is inherited, not optional, every outward post, like, and follow waits for human approval, and there is no configuration that removes it.
WHAT YOU GET
For the book: - one portfolio command view, clients as rows, status, growth velocity, active campaigns, - a staggered daily schedule across every managed account, built to avoid the synchronized patterns platforms flag.
Per client: - their own voice, bound per client, so no client's posts read in another client's voice, - hard isolation, content, audience data, and metrics never cross a client boundary (fail-closed, skip and flag rather than leak), - a report on their cadence, weekly, biweekly, or monthly, scoped to their accounts only, - a gate log, what was approved, what was held, and by whom.
Adding the next client is a roster row, not a hire.
WHO IT'S FOR
Small social and marketing agencies (call it two to twenty-five clients) running multi-platform account management who need per-client voice and hard client isolation without per-client headcount, then in-house teams running a family of brands from one desk, and fractional CMOs carrying several accounts. It is built for the person whose name is on the retainer when a post goes out wrong. It is explicitly not for engagement farming: the coordination rules forbid client accounts amplifying each other, and there is no auto-publish path.
PRICING
Prices below are hypotheses we are validating, not commitments, and we price the ladder, not a single number. - Pilot, one client account group through the full cycle for a fixed period, where you watch the schedule, the gate, the isolation behavior, and the client report before committing the book. - Managed, per client per month once the pilot proves voice and isolation discipline. - Agency platform, the whole-book license, unlimited roster rows and the portfolio view, value-metered on the size of the managed book.
Every charge is a money step and sits behind human confirmation, same as every post.
PROOF (the dogfood)
We are client zero. The orchestration underneath this product is the same substrate AYA runs its own thirteen-account fleet on (nine personas, four business accounts), with the same staggered timing, the same coordination rules, and the same human gates. The first real multi-account migration this product performs is our own: moving that fleet off a dissolving brand onto the new one, using exactly the roster overlay an agency customer would use.
HONEST NOTE
This is a structural build, and here is precisely what that means. The daily orchestration pattern exists, scores valid, and its pieces resolve on disk, and the agency layer (roster, voice binding, isolation, cadence) is data riding on top of it, which is the point, nothing was rebuilt. What has not happened yet is a witnessed run: no live daily cycle, no live post, no real client roster (the rows in the overlay are illustrative schema, not customers), no charge, because that needs credentialed accounts and a running mesh. One of the underlying top-level orchestrator patterns also carries a known composition defect we have declared rather than hidden (it composes a pattern at its own level, which our validator correctly rejects), so the verified deliverable of record is the orchestration span that passes, not that one. When the first witnessed cycle exists, this note changes, and not before.
*This page is a specification. The capability it describes is not built yet, and nothing here is a claim that it runs today.*