Skip to content
Ascend GTM Ops — Docs

Sign-off on ADR-016's 4 preconditions & commitment to Phase 1 Consolidation Sprint

ADR-018 — Sign-off on ADR-016’s 4 preconditions & commitment to Phase 1 Consolidation Sprint

Status: Accepted Date: 2026-04-23 Deciders: Mishaal Murawala Relates to: ADR-016 (context plane + two-plane architecture), docs/session-handovers/2026-04-17_to_22.md §5 Phase 1, docs/platform-product-spec-v0.1.md

Context

ADR-016 proposed the two-plane V5 architecture (Execution Plane + Context Plane). It was explicit that Phase 1 is not context-plane work — Phase 1 is a 2-week consolidation sprint that pays down operational debt before a whole new plane is added. ADR-016 §Open Questions listed 4 preconditions that had to be accepted before Phase 1 could start:

  1. 2-week consolidation sprint is non-negotiable (no feature work during it).
  2. Smart Scheduler Phases 2-5 are formally deferred.
  3. The claude_* tool family (claude_invoke, claude_batch, claude_files, claude_agents) consolidates into one tool with an action enum.
  4. No new gateway tools ship during the sprint.

The 2026-04-22 handover placed all four on Mishaal’s plate as Phase 0 task 0.7.

Decision

All 4 preconditions are accepted. Phase 1 starts 2026-04-23. Scope is frozen at 8 tasks per the handover §5 Phase 1, with exit criteria:

  • ≤25 MCP tools registered in src/handlers/mcp.ts
  • Zero “Proposed” ADRs older than 2 weeks at sprint end
  • All 5 platform-spec gaps closed (see docs/platform-product-spec-v5-mapping.md §Gaps)
  • Bundle size < 2 MB
  • Tech-debt register committed at docs/tech-debt-register.md

Rationale per precondition

1. 2-week sprint non-negotiable

The handover’s engineering-manager analysis was explicit: “we must earn the right to add a whole new plane. This is debt paydown.” Accepting this means no ADR-016 Phase 2+ code lands during the sprint, even if ready. Exceptions: P0 security or uptime fixes only.

2. Smart Scheduler Phases 2-5 deferred

Scheduler Phase 1 (Cal.com self-hosted + SES outbound) is live. Phases 2-5 (findMeetingTimes strategy router, multi-calendar workflows, recurring scheduling intelligence, partner-facing booking) are deferred indefinitely. Formalized in ADR-019 (this PR).

Deferral does not mean “won’t do.” It means “re-evaluate when a client needs it.” If Kahuna or Point Field asks for findMeetingTimes integration, we re-open ADR-019 with specific scope + budget.

3. claude_* consolidation

Current state: 4 separate tools (claude_invoke, claude_batch, claude_files, claude_agents) each wrapping a different Anthropic API. Total input-schema context overhead per MCP session: ~20-40K tokens.

Research pass 2026-04-23 confirmed this is the wrong pattern:

  • Anthropic “Writing Tools for AI Agents” (Sept 2025) explicitly recommends consolidation: “implement schedule_event rather than separate list_users, list_events, and create_event tools.”
  • MCP spec 2025-11-25 fully supports conditional schemas via oneOf + discriminator.
  • Production pattern is validated at scale — Asana’s MCP server ships 126 actions as one tool.
  • Context token savings: 15–20% per session.

Decision: consolidate into one tool claude with action: "invoke" | "batch" | "files" | "agents". Use oneOf discriminator in the Zod schema. Task 1.3 in the Phase 1 plan.

4. No new gateway tools during the sprint

“New” means any tool that adds to the registered-tool count in src/handlers/mcp.ts. Parameter additions to existing tools, bug fixes, performance work, and documentation are fine. A new provider in src/config/providers.ts is fine (doesn’t add an MCP tool). A new wrapper tool that shows up in discover_apis output is NOT fine — that’s a new tool.

Enforcement: pre-commit check 04 already caps the tool count. Pin it explicitly at the current count minus expected consolidation delta (28 → ~25 after Phase 1 task 1.2 + 1.3).

Consequences

Positive

  • Phase 1 has a clean, measurable exit criterion.
  • The claude_* consolidation carries an ~18% agent-context-token savings.
  • Platform-spec gaps are enumerated and scoped, not just named.
  • Scheduler deferral stops stealing cycles from core V5 work.

Negative

  • 2 weeks of no feature-driven user-visible progress. Only platform investment. Client communications (Kahuna, PFP) should frame this as “infrastructure hardening before context-plane work.”
  • Consolidating claude_* is a breaking change for any caller that memorized the old tool names. Documented migration in ADR-020 (below).

Neutral

  • Phase 2 context-plane scaffold now formally starts at Phase 1 exit. Calendar target: 2026-05-08 (+2 wks from today).
  • ADR-019 — Smart Scheduler Phases 2-5 formally deferred (implements precondition 2, task 1.7 from handover).
  • ADR-020 — Cloudflare Analytics Engine for per-tool telemetry (implements task 1.1 infrastructure decision).

References

  • ADR-016: docs/decisions/ADR-016-context-plane-and-always-on-gtm-brain.md
  • Handover: docs/session-handovers/2026-04-17_to_22.md §5 Phase 1
  • Phase 1 plan: docs/plans/V5-PHASE-1-CONSOLIDATION-SPRINT.md (this PR)
  • Platform spec: docs/platform-product-spec-v0.1.md + docs/platform-product-spec-v5-mapping.md