Living Online

Agency OS

Internal Architecture Reference

Agency OS operating architecture

This internal Pages site collects architecture decisions, runtime maps, hosted Jessie execution status, marketing skill prompts, and runbooks for the team building and operating Agency OS.

Cloudflare Runtime

Pages + Workers

Pages hosts the internal reference and web interface; Workers run API, webhook, and queue logic.

Hosted Execution

7 Jessie paths

SEO, GA4, Google Ads, Meta Ads, Integrated Performance Report, technical SEO audit, and the Jessie workbench run from Asana intake.

Evidence Library

Staff-only registry

Report artifacts, files, provenance, and revision rounds are indexed in D1 with larger packages referenced from R2.

Executive Summary

CEO briefing

Asana is the work front door

Consultants and admins create or update Asana tasks. Asana webhooks notify Agency OS, so tasks can trigger build runs, agent runs, or client data setup work without staff leaving Asana.

Cloudflare is the operating platform

Cloudflare Pages, Workers, Queues, D1, R2, Browser Run, and Secrets Store keep the system serverless and reduce vendor sprawl.

Admin config drives agent readiness

The Agency OS web interface now separates Manage Users and Manage Clients. Client setup is captured as Sources, Context, and Users so agents know which tools and facts are safe to use.

Evidence stays inspectable

Jessie still posts artifacts to Asana, but the Report Artifact Registry gives staff a durable index for reuse, auditability, evidence lookup, and revision history.

Cloudflare-First Runtime Map

Internal reference

Cloudflare Resource Inventory

Current dev runtime
LayerResourceRoleNotes
Pagesagency-os-architecture-siteInternal living reference for system architecture, ADRs, docs, diagrams, and skills.No API proxy and no dashboard data secret.
Pagesagency-os-web-interfaceOperational Agency OS web interface for dashboards, Report Library, and Admin & Configuration CRUD.Has encrypted Pages secrets for the API origin and internal service token, office-IP middleware restriction, report artifact views, and admin deep links by Business Unit.
Workersagency-os-dev-platform-build-control-planeAPI, Asana webhook intake, queue consumers, Team Agent Runtime shell, Admin Registry, Report Artifact Registry, Client Data Plane fixture/data endpoints, health checks.Current public dev worker runs on workers.dev. Team Agent run state, run events, feedback rounds, execution candidate factories, and watchdog runtime now live in focused modules called by the Worker shell.
D1agency-os-dev-platform-build-runsOperational database for build runs, Team Agent runs, report artifact registry, Client Data Plane setup, facts, access grants, and access logs.Binding: PLATFORM_BUILD_DB. Registry tables index artifacts, files, channel provenance, and revision rounds.
R2agency-os-dev-technical-seo-auditsStores larger generated artifact packages such as technical SEO crawl/evidence bundles.D1 stores stable keys and metadata for audit packages.
R2agency-os-dev-client-data-planeStores Raw Source Snapshot payloads for Client Data Plane ingestion runs.Binding: CLIENT_DATA_PLANE_BUCKET. Strategic Settlements manual SEO refresh writes GA4, Search Console, and optional Accuranker raw snapshots here while D1 stores metadata and curated facts.
Queuesagency-os-dev-platform-build-runsDecouples Asana webhook receipt from build-run processing.Binding: PLATFORM_BUILD_QUEUE.
Queuesagency-os-dev-team-agent-runsDecouples Asana webhook receipt from Team Agent assessment and execution.Binding: TEAM_AGENT_QUEUE.
Secrets StoreAgency OS credential storeRuntime binding for Asana, Google OAuth, Google Ads, Meta, Accuranker, DataForSEO, Semrush, Ahrefs, and Browser Run credentials.Secret values are not stored in Git, D1, R2, Asana comments, or dashboard payloads.
AI GatewayOpenAI provider, gpt-5.5 model configCentral policy/observability point for agent model calls.Payload logging defaults off unless explicitly enabled.
Browser RunCloudflare Browser Run APICrawl/render evidence for SEO reporting and technical audit workflows.Uses a scoped token from Secrets Store.

Terminology note: Cloudflare uses D1 for serverless SQL and R2 for object storage. If you see R1 or D2 in discussion notes, read that as R2/D1 unless we deliberately introduce a different product later.

Asana Operating Model

Work source
1
Platform Build project

Build tasks move through intake, clarification, ready, in progress, review, blocked, merged/done, or error sections.

2
Jessie Intake project

Team Agent work enters a dedicated intake queue. Current dev requires the task to be assigned to Jessie before hosted execution is eligible.

3
Client brand projects

Each client account/brand becomes a single Asana project. Subscription sections, such as SEO, group the planned and completed work that can later appear on dashboards.

4
Client-visible task flag

Tasks are private by default. Consultants or agents can mark selected subscription tasks as client visible when strategy or sprint planning is ready.

Webhook + Queue Flow

Event-driven
1
Asana sends webhook

Asana calls POST /webhooks/asana when configured projects or tasks change. The Worker supports the X-Hook-Secret handshake.

2
Worker verifies signature

The Worker requires X-Hook-Signature and validates it against ASANA_WEBHOOK_SECRET before accepting event payloads.

3
Events are grouped by task

The Worker groups task and task-comment story events by Asana task GID and creates idempotent Platform Build and Team Agent candidate messages.

4
Queues absorb processing

Messages go to PLATFORM_BUILD_QUEUE and TEAM_AGENT_QUEUE so webhook acknowledgement is fast and downstream work can retry safely.

5
D1 records state

Queue consumers persist run state and event history in D1, detect duplicates, and decide whether a task is ignored, blocked, needs clarification, ready, or review-ready.

6
Runtime modules own Team Agent internals

The Worker shell now calls focused state and watchdog modules for Team Agent run leases, run events, feedback rounds, revision recovery, and stale runner requeue/failure behavior.

Team Agent Runtime

Extraction slice 1
1
Worker shell stays deployed

The Cloudflare Worker still owns fetch, queue, scheduled entry points, HTTP/admin routes, Asana webhook verification, and adapter composition. Existing exported functions remain available for tests and scripts.

2
State modules own D1 SQL

Team Agent run lookup, status transitions, execution lease acquisition, watchdog listing/recovery, append-only run events, processed feedback comment claims, and feedback round persistence now live under src/state/.

3
Watchdog runtime is isolated

runTeamAgentRunnerWatchdog delegates to src/team-agent/watchdog.ts, which plans ready/running/revision-running recovery, respects retry caps, requeues execution candidates, and records failure through explicit Worker ports.

4
Queue contracts stay stable

team-agent-run and team-agent-execution message shapes did not change. Revision execution candidates are created by src/team-agent/execution-candidates.ts using the same idempotency keys and correlation format.

5
Compatibility tests stay broad

The existing index.test.ts remains the Worker-shell behavior backstop, while new module tests cover lease acquisition, duplicate rejection, feedback claiming, revision lookup, watchdog requeue, and retry-cap failure.

Current Module Map

  • src/team-agent/types.ts: shared Team Agent runtime types.
  • src/team-agent/execution-candidates.ts: ready and revision execution queue candidate factories.
  • src/team-agent/watchdog.ts: stale run recovery orchestration and watchdog planning.
  • src/state/team-agent-runs.ts: Team Agent run state, lifecycle, lease, and watchdog SQL.
  • src/state/team-agent-run-events.ts: append-only run event SQL.
  • src/state/feedback-rounds.ts: processed comment claiming and feedback/revision round SQL.
  • src/index.ts: deployed Worker shell plus remaining orchestration for feedback handling, skill execution, Asana write-back, artifact registration, and HTTP/admin routes.

Still To Extract

  • Post-review feedback/revision orchestration.
  • Asana comment rendering.
  • Per-skill hosted execution dispatch.
  • Technical SEO hosted execution runtime.
  • Queue dispatch after run/execution modules have smaller interfaces.

Asana Task Lifecycle

Operational control
AreaAsana state or signalAgency OS actionStored where
Platform BuildTask enters build project or relevant sectionCreate candidate Build Run and enqueue processing.D1 build run tables and events
Team AgentTask assigned to Jessie or matching configured eligibilityAssess skill request, context, credentials, and readiness.D1 team agent run tables and events
Agent ExecutionTask is readyRun the selected skill, create review comment, and attach artifacts when needed.D1 run state, Asana comments, R2 artifacts when large
Client Data PlaneClient brand/subscription setup is approved or manually refreshedActivate source assets, data products, subscription data views, dashboard inclusion, and GA4/GSC fact refreshes.D1 setup/fact tables, R2 raw snapshots
Client-visible TasksTask marked client visible and assigned to a subscription sectionExpose task name, status, subscription, planned date, or Asana completed time in dashboard facts.Prepared dashboard fact feed from stored facts
ErrorsChecks fail or execution cannot continueCreate or update platform error tasks and keep evidence for review.D1 event history, Asana error/regression section

Report Artifact Registry

Staff-only evidence library
1
Jessie produces a review artifact

SEO, GA4, Google Ads, Meta Ads, Integrated Performance Report, technical SEO audit, and useful general workbench runs keep their existing Asana attachment/comment write-back.

2
Worker registers the shared artifact contract

The control-plane Worker writes report_artifacts, report_artifact_files, report_channel_provenance, and report_revision_rounds rows with lifecycle status, visibility, evidence capsule JSON, reusable state, and supersedes/superseded-by links.

3
R2 holds larger packages

Technical SEO crawl data, CSV exports, raw debug JSON, screenshots, and future larger evidence bundles live in R2 when available; D1 stores stable keys and references.

4
Web interface exposes evidence workspaces

The staff-only /reports/ view remains the global Evidence Library. Business Unit dashboards add an internal Report History tab for that client, including lifecycle, reuse, evidence capsule, files, provenance, Asana task, and revision timeline.

Boundary

  • Asana remains canonical: task discussion, consultant approval, and feedback rounds stay on the original Asana task.
  • D1 indexes artifacts: the registry is the durable lookup surface for artifact reuse, auditability, and evidence discovery.
  • Server-side visibility: client/external viewers only receive future client-visible/published records; V2 artifacts remain staff-only by default.
  • Lifecycle-safe reuse: dismissed, superseded, blocked, stale, wrong-period, wrong-channel, and unresolved-feedback artifacts are excluded from reusable artifact queries.
  • Context control: prompts should start from compact evidence capsules and fetch deeper JSON/CSV only when a specific section needs it.
  • Sanitized metadata: no credentials, provider tokens, or raw sensitive payloads are returned by the registry API by default.

Agent Marketing Skills

Open skill library

Recent System Changes

Hosted Jessie path
1
Team Agent Runtime extraction slice

Run state SQL, run event SQL, feedback round SQL, execution candidate factories, and watchdog recovery moved out of index.ts into focused src/state and src/team-agent modules. The Worker shell and queue contracts remain behavior-compatible.

2
Multi-skill hosted execution

The Team Agent queue can execute SEO reporting, GA4 reporting, Google Ads reporting, Meta Ads reporting, Integrated Performance Report, technical SEO audit, and governed Jessie workbench requests.

3
Integrated report package

The aggregate-performance-reporting route now produces `client-report.html`, `consultant-appendix.html`, and `evidence.json` on the same Asana task for consultant approval.

4
Report Artifact Registry

Review artifacts, package files, channel provenance, and revision rounds are indexed in D1 and visible in the staff-only Report Library.

5
Performance snapshot evidence fix

The Integrated Performance Report now renders actual channel performance evidence in Performance Snapshot and What Changed instead of channel draft-label text.

6
Post-review feedback rounds

Human comments after review_ready are classified as acceptance, revision request, discussion, scope change, or no-op, then processed on the same canonical Asana task.

7
Crawl and PageSpeed audit hardening

Technical SEO audit packages use Browser Run, R2, Asana evidence links, and incomplete-crawl findings instead of silent empty success reports.

8
Jessie workbench direction

Generic Jessie requests now plan, clarify, or use approved read-only analysis tools when confidently matched, including Plunkett Meta creative frequency and Plunkett SEO keyword-gap analysis.

9
Review artifact delivery

Hosted skills attach or link review-required artifacts to the source Asana task and keep client delivery consultant-mediated.

10
Admin Registry UX and readiness fix

Admin now focuses on Manage Users and Manage Clients, with client setup split into Sources, Context, and Users. Dashboard cards distinguish Dashboard Needed from Setup Needed, and list readiness is recomputed from current records.

11
Dashboard surface provisioning

Ready Business Units now expose Create dashboard on the Dashboards page. The Admin Registry Worker upserts an active staff-preview dashboard surface and the web interface opens slugged dashboard routes such as /dashboards/strategic-settlements/.

12
Strategic Settlements manual ingestion

The first real Client Data Plane ingestion slice adds Refresh data for GA4, Search Console, and optional Accuranker Source Assets, R2 Raw Source Snapshots, D1 curation runs, current facts, fact versions, comparison-period movement, freshness warnings, and dashboard fact retrieval.

Client Data Plane

Dashboard facts
1
Admin-led onboarding

Agency staff configure the client group, Business Unit, source assets, context folder, staff access, and dashboard surface inclusion.

2
Manual SEO refresh

POST /admin-registry/business-units/:businessUnitId/refresh-data runs the configured GA4, Google Search Console, and optional Accuranker Source Assets for that Business Unit. Strategic Settlements is the first real client slice.

3
Raw snapshots

The Worker uses Google OAuth credentials from Cloudflare Secrets Store, stores minimized raw GA4/GSC payloads in CLIENT_DATA_PLANE_BUCKET, and writes raw_source_snapshots metadata rows in D1.

4
Normalized facts

Curation runs upsert current_client_facts and client_fact_versions with lineage linking source assets, ingestion runs, raw object keys, date range, and transformation version.

5
Web interface

Staff dashboards expose a Refresh data action and then read prepared fact feeds from the Worker. They do not query source platforms directly on page load.

Secrets + Access Boundary

No secrets in data
Runtime binding
Secrets Store

Worker credentials are injected through Cloudflare Secrets Store bindings such as AGENCY_OS_ASANA_AGENT_PAT, Google OAuth credentials, Google Ads credentials, Meta token, Accuranker, DataForSEO, Semrush, Ahrefs, and Browser Run.

Pages secrets
Web interface API origin and service token

The web interface uses encrypted Pages secrets for AGENCY_OS_API_BASE_URL and AGENCY_OS_INTERNAL_API_TOKEN. The architecture site does not have these secrets.

Worker service token
Internal route guard

The Worker requires X-Agency-OS-Internal-Token on /client-data-plane/* and /report-artifacts/*, then compares it with the AGENCY_OS_INTERNAL_API_TOKEN secret binding before serving staff-only metadata.

No data leakage
Fact and artifact policy

Secrets must not be written into D1 records, R2 objects, Asana comments, generated reports, dashboard HTML, or logs.

Future access
Staff now, clients later

The web interface is staff-only during development. Future client credentials and client-shareable access must use explicit grants and separate access controls.

Admin Registry + Readiness

Updated 21 May 2026
1
Admin entry point

Admin & Configuration has two primary modes: Manage Users and Manage Clients. Manage Clients starts with a Business Unit selector and a Create Client action.

2
Client setup tabs

Each Business Unit is configured through Sources, Context, and Users tabs. Source IDs such as Asana project GID, GA4 property, Search Console site, Accuranker project, Google Ads, Meta, and HubSpot live in Sources.

3
Context and team authority

Context stores the Box client context folder binding. Users stores internal staff assignments now and leaves room for external client access later.

4
Readiness source of truth

The Worker recomputes readiness from current records for source assets, staff mappings, Business Unit roles, Jessie service identity, and no-live-connector policy. Dashboard lists no longer trust stale persisted readiness snapshots.

5
Dashboard surface status

A Business Unit with passed admin setup but no dashboard route is shown as Dashboard Needed with a Create dashboard action. The Worker creates an active staff-preview dashboard_surface_configurations record, then the card switches to Open dashboard.

6
Manual fact refresh

Business Unit dashboards now expose Refresh data. The action calls Admin Registry, validates GA4/GSC Source Assets, persists raw snapshots, and lets the dashboard render current facts.

Why This Matters

  • Strategic Settlements: setup readiness is passed, the staff-preview dashboard surface can be provisioned, and manual SEO refresh now fills the dashboard with stored GA4, Search Console, and optional Accuranker tracked-keyword facts.
  • Operator clarity: admins see exactly whether they need to edit Sources, Context, Users, or create/open the dashboard route.
  • Dashboard routes: non-Plunkett Business Units use slugged dashboard URLs such as /dashboards/strategic-settlements/ after surface creation.
  • Agent safety: setup readiness describes whether the agent has the source IDs, context, staff authority, and service identity it needs before execution.

What Exists Now

Live dev
  • Architecture site: internal Pages site with docs, ADRs, diagrams, resource inventory, and skill inventory.
  • Agency OS web interface: separate Pages site serving the fixture-backed Plunkett SEO dashboard, real Business Unit dashboard routes with Refresh data and internal Report History tabs, dashboard registry, staff-only global Report Library, simplified Admin & Configuration CRUD, and staff-preview dashboard creation for ready Business Units.
  • Worker API: health, Asana webhook intake, task-comment follow-up handling, queue consumers, hosted Team Agent execution, extracted Team Agent state/watchdog modules, Admin Registry, Report Artifact Registry, dashboard surface provisioning, manual SEO data refresh, Client Data Plane fixture seed, dashboard fact feed, and metadata-level agent fact query logging.
  • Hosted Team Agent skills: SEO reporting, GA4 reporting, Google Ads reporting, Meta Ads reporting, Integrated Performance Report, technical SEO audit, and the governed Jessie workbench.
  • D1: migrations include build runs, Team Agent runs and event history, report artifacts/files/provenance/revisions, Client Data Plane setup, facts, dashboard configuration, and agent data access logs.
  • R2: technical SEO audit bucket stores generated audit packages. CLIENT_DATA_PLANE_BUCKET stores raw source snapshots for manual GA4, Search Console, and Accuranker ingestion.
  • Queues: Platform Build and Team Agent queues are configured to keep webhook intake fast and processing retryable.

Near-Term Roadmap

Next build slices
  • Dashboard surface governance: expand the new staff-preview creation path with access grants, inclusion controls, publish states, and audit history.
  • Admin configuration depth: extend the Sources, Context, and Users tabs with richer validation, safer edit history, and external client access grants after staff-only setup is proven.
  • Scheduled ingestion: promote the manual SEO refresh path into scheduled/daily refreshes, then add Asana, Google Ads, Meta, HubSpot analytics, and Harvest reconciliation.
  • Cloudflare Workflows and Containers: target path for longer-running builder execution and build/check automation after branch creation.
  • R2 SQL: later analytics path for larger historical reporting datasets stored in R2.
  • Client access: explicit dashboard access grants and client credentials after staff-only development proves the data and visibility model.

Agent Skills Architecture

41 indexed

Where Skills Live

  • Repo skills: skills/*/SKILL.md stores Agency OS delivery skills such as SEO reporting, GA4 reporting, and Google Ads reporting.
  • Agent skills: .agents/skills/*/SKILL.md stores repo-local operating skills for builders, triage, diagnostics, handoff, and architecture work.
  • Marketing skill pages: /marketing-skills/ exposes the hosted Jessie marketing skills, their natural-language prompts, source prompt text, data sources, outputs, and guardrails.
  • System/plugin skills: installed Codex skills live outside this repo and are available to the agent runtime, but the architecture site indexes the repo-owned skills first.
  • Skill contract: each SKILL.md explains when to use the skill, required inputs, safety rules, and expected outputs.

How Skills Run

  • Trigger: a consultant or admin asks for work in Asana, or an agent receives a build task.
  • Assessment: Agency OS checks the task, context, credentials, and requested skill before marking the run ready.
  • Execution: the selected skill gathers approved data, prepares artifacts, and writes a review-ready Asana comment or attachment.
  • Control: skills do not publish client-facing changes directly unless the workflow explicitly allows it.

Indexed Skill Examples

SKILL

.agents/skills/caveman/SKILL.md

Diagnose

.agents/skills/diagnose/SKILL.md

SKILL

.agents/skills/grill-me/SKILL.md

ADR Format

.agents/skills/grill-with-docs/ADR-FORMAT.md

CONTEXT.md Format

.agents/skills/grill-with-docs/CONTEXT-FORMAT.md

SKILL

.agents/skills/grill-with-docs/SKILL.md

SKILL

.agents/skills/handoff/SKILL.md

Deepening

.agents/skills/improve-codebase-architecture/DEEPENING.md

Interface Design

.agents/skills/improve-codebase-architecture/INTERFACE-DESIGN.md

Language

.agents/skills/improve-codebase-architecture/LANGUAGE.md

Cloudflare Changelog Notes

Checked 22 May 2026

Primary Architecture Docs

View library
  • ADR 0009: Team Agent Runtime Extraction docs/adr/0009-team-agent-runtime-extraction.md ADR 0009: Team Agent Runtime Extraction Date: 2026-05-22 Status: Accepted Context The Cloudflare control-plane Worker has become the always-on runtime for Agency OS. It owns Asana webhook intake, queue consumers, Team Agent state transitions, execution leases,
  • ADR 0004: Hosted Team Agent Execution MVP docs/adr/0004-hosted-team-agent-execution.md ADR 0004: Hosted Team Agent Execution MVP Date: 2026-05-18 Status: Accepted Context Hosted Team Agent intake can now notice Jessie Intake tasks, verify Jessie assignment, create a D1 Team Agent Run, assess readiness, and post a Delegation Confirmation. That pr
  • ADR 0006: Cloudflare Client Data Plane docs/adr/0006-cloudflare-client-data-plane.md ADR 0006: Cloudflare Client Data Plane Date: 2026-05-19 Status: Accepted Context Agency OS needs a data and presentation foundation for client onboarding, source configuration, ingestion, dashboards, future reporting, future alerts, and agent access to trusted
  • Client Data Plane Specification docs/client-data-plane-specification.md Client Data Plane Specification Status: draft for review Updated: 2026-05-19 Purpose The Client Data Plane is the Cloudflare-first subsystem that stores client onboarding configuration, source bindings, ingestion runs, normalized facts, freshness state, and da
  • Client Data Plane Build Blueprint docs/client-data-plane-build-blueprint.md Client Data Plane Build Blueprint Status: draft implementation blueprint Updated: 2026-05-19 Objective Build the first Cloudflare-first Client Data Plane tracer bullet for Agency OS. The first build should prove that Agency OS can onboard a brand/subscription,
  • Platform Build Loop MVP docs/architecture/platform-build-loop-mvp.md Platform Build Loop MVP Purpose The Platform Build Loop is the governed operating loop for changing the Agency Operating System itself. It turns Asana Platform Build Tasks into bounded builder-agent work, review artifacts, and human merge decisions. This MVP p

Operating Loops

Current model

Platform Build Loop

Asana build tasks, builder agents, checks, review artifacts, and human merge decisions.

Team Agent Work

Staff delegate delivery work through governed agent skill execution and human approval.

Client Data Plane

Onboarding setup, source bindings, fixture/dev/prod facts, dashboard feeds, and agent data access logs.

Web Interface

Dashboards, admin configuration, onboarding, and future client-shareable views live on a separate Pages domain.

Related Runtime Surfaces

Different domain boundary

Architecture Site

Internal living reference for how Agency OS is put together. This site should stay staff-only.

Agency OS Web Interface

Dashboard review, staff-only Report Library, admin configuration, onboarding, and future client-shareable views later.

Open web interface

Skill Inventory

View skills

SKILL

.agents/skills/caveman/SKILL.md

Diagnose

.agents/skills/diagnose/SKILL.md

SKILL

.agents/skills/grill-me/SKILL.md

ADR Format

.agents/skills/grill-with-docs/ADR-FORMAT.md

CONTEXT.md Format

.agents/skills/grill-with-docs/CONTEXT-FORMAT.md

SKILL

.agents/skills/grill-with-docs/SKILL.md

SKILL

.agents/skills/handoff/SKILL.md

Deepening

.agents/skills/improve-codebase-architecture/DEEPENING.md