Recently shipped and in-flight direction
What Is Underway.
What landed in the last week, the client-facing dashboard, and the proposed agent-loop and tool-library direction still under review.
Recently Shipped
Work merged to the live control plane in the last week. These are in production-shadow or live runtime behavior, not proposals.
| Area | What changed |
|---|---|
| Agency Brain lean context | Jessie now receives a bounded task-time context capsule (resolved Business Unit, compact sourced facts, tool pointers) instead of large context dumps, and the box.client_context_read workbench lane is executable for resolved Business Units. Gated by TEAM_AGENT_AGENCY_BRAIN_CAPSULE_ENABLED (ADR-0018). |
| Technical SEO audit reliability | Brief revisions reuse already-gathered audit evidence instead of re-crawling, follow-up/clarification replies are parsed as continuations of the same job, and Asana comment pagination is read in full for audit follow-ups. |
| Strategy planning grounding | Strategy plans now draw on a deliberately diverse spread of evidence sources (context, Harvest budget, channel data) rather than over-weighting one source. |
| Execution reliability | Run-step and final writes are gated by an active execution lease with heartbeat refresh; consultant-feedback rounds allocate atomically; the watchdog recovers stuck revision runs; context refresh only promotes valid context; context preflight retrieval is hardened. |
| Platform Error dedupe | Platform-development error tickets are deduplicated through SHA-based claim rows in D1, so the same failure no longer spawns duplicate Asana tasks. |
| AI Gateway robustness | The AI Gateway adapter now unwraps chat responses delivered in a nested envelope shape, preventing parse failures during model-call synthesis. |
| Cloudflare Agents SDK | Upgraded to agents 0.14.5; the Team Agent Durable Object continues to run in production-shadow mode pending synthetic proof before live execution adoption. |
Client Data Plane And Dashboard
A client-facing performance dashboard is live for the first client and reads prepared facts from the Client Data Plane — it does not query source APIs at view time.
Live Today
- A client dashboard surface is deployed on its own Cloudflare Pages project (separate from this internal site) and is currently IP-restricted.
- Strategic Settlements is the first business unit served from prepared Client Data Plane facts.
- The Client Data Plane holds client groups, business units, channel subscriptions, source assets, and Current Client Facts, with raw source snapshots in R2 and prepared facts/metadata in D1.
- Manual data refresh ingests GA4, Search Console, and AccuRanker into Current Client Facts for a business unit.
In flight Phase 1 hardening
- A ?view=client toggle on reports renders a curated client view (forensic detail stays in the consultant view).
- Living Online brand tokens, a mobile layout breakpoint, and per-card data-source/last-updated provenance.
- Visibility gating so only client_visible facts reach a client viewer, and removal of hard-coded fallback date ranges.
- Client dashboard access scopes plus scheduled data refresh (proposed in a dashboard-access ADR on a working branch).
The dashboard is reviewed-before-delivery: facts may refresh automatically, but client-facing narrative remains consultant-published. Cloudflare Access for per-client login is a later step, not the current protection layer.
Agent-Loop Execution Core
Proposed — under review ADR-0019 proposes evolving how skills execute, while keeping the existing governance shell unchanged.
Kept as-is (governance shell)
- Asana intake, eligibility, and readiness assessment.
- Cloudflare Queues, D1 run ledger, and R2 artifact/context lake.
- Approval gates, dry-run defaults, and review-before-delivery.
Proposed change (execution core)
- Replace per-skill TypeScript pipelines with a pluggable execution adapter that runs CLI agent harnesses inside Cloudflare Sandboxes.
- Skills become executable SKILL.md documents rather than hand-coded pipelines.
- The first adapter is the Claude Agent SDK, with the boundary designed so other harnesses could plug in; per-skill routing is chosen via consultant-judged evals.
- Migration is skill-by-skill with side-by-side evaluation so the live Plunkett flow never breaks.
This direction is a proposal drafted with Claude and recorded as an ADR; it is not built. The mechanism for exposing integrations to harnesses (a typed tool library versus MCP tools hosted on Workers) is still being decided.
Typed Tool Library And Router
Proposed — under review Claude_06 proposes a capability layer beneath skills so the runtime can reason about tools the agent can use, not only skills the agent can run.
- A typed TypeScript tool library (@agency-os/tools) of focused functions wrapping existing integrations, where the TypeScript types act as the schema.
- A RouterAgent that classifies each request as codified, ad-hoc, needs-clarification, or out-of-scope, and proposes a plan a consultant approves before any ad-hoc run.
- Ad-hoc work runs model-written TypeScript in a Cloudflare Sandbox; tool calls RPC back to the durable Team Agent so credentials and approval gates never leave the control plane.
- Skills become declarative compositions (frontmatter + workplan + template), so adding a skill is closer to a registry write than touching several files.
This is exploratory architecture for scaling past today's fixed skill set. It overlaps with the agent-loop direction above; the two are being reconciled, and neither is live.
Source References
- docs/adr/0018-agency-brain-lean-context-runtime.md
- docs/adr/0006-cloudflare-client-data-plane.md
- docs/Claude/Claude_06_tool_and_skill_registry_architecture.md
- docs/Claude/Claude_03_decide_apps_platform.md
- apps/platform-build-control-plane/src/client-data-plane.ts