Skip to content
Ascend GTM Ops — Docs

Ascend Operator OS — Vision & Master Plan

Ascend Operator OS — Vision & Master Plan

Status: ADOPTED (2026-05-07) Owner: Mishaal Murawala Supersedes: Implicit “V5 = MCP gateway” framing in docs/archive/PRD_GATEWAY_V5_FINAL.md Implementation entry point: docs/decisions/ADR-040-operator-os-q1-five-parallel-tracks.md · docs/plans/OPERATOR-OS-Q1-FOUNDATION.md

Note on existing V5 invariants. .claude/rules/v5-invariants.md (the 15 invariants) governs the gateway substrate that the Operator OS sits on top of. Where this document changes one of those invariants (hot-path budget, tool ceiling, MCP registration model, KV-only memory, composites), an ADR will land alongside the change before any code does. The existing 15 invariants stay in force until their ADR ships.

§0 — Reframe: What we are actually building

Ascend GTM is not building “an MCP gateway with a few agents on top.” We are building an Operator OS for Private Equity portfolio companies and the funds that own them: a substrate where every revenue motion (ICP scoring, outbound, paid-channel allocation, pipeline review, board reporting, cross-portco pattern transfer) is a multi-tenant agent backed by per-tenant memory, dynamic capability retrieval, and outcome-based metering.

The V5 gateway is the execution substrate. The Operator OS is the product.

Adoption decisions captured in Appendix B at the bottom of this doc:

  • A. Adopt as master plan. ✓ ADOPTED 2026-05-07
  • B. Land level: PE Operating Partners (fund) AND portfolio companies (portcos), simultaneously. ✓ BOTH 2026-05-07
  • C. Q1 sequence: engineering-led, 5 parallel tracks. ✓ See ADR-040 + Q1 plan doc 2026-05-07

§1 — Three buyers, in priority order

#BuyerLand motionCompounding asset for themWhy we sell to them
1PE Operating Partners (funds)Fund-level platform agreement → 1 portco pilot → 3 portco rollout → fund-wideCross-portco operating benchmarks; signal-driven board prep; auto-distilled best practiceHighest-ACV, longest-retention, network-effect buyer. One Op Partner sells the next 5 portcos.
2Portfolio company GTM leaders (CMO / VP Sales / VP RevOps)Per-portco subscription, sometimes intro’d by fund, sometimes directTheir own per-tenant agent fleet + memory; outcome guarantees; replaces 2-4 GTM hiresLand here when fund isn’t engaged. Most direct revenue path.
3Ascend GTM itself (dogfood)InternalEvery agent improvement we ship runs against our own pipeline firstForcing function. We never ship an agent we wouldn’t run on our own funnel.

We sell to (1) AND (2) simultaneously — Op-Partner-down and Portco-up at the same time. Adopted 2026-05-07.

§2 — The five operating bets

Each bet is testable. Each one fails openly if wrong.

  1. Per-tenant agents beat generic agents. A SDR Agent that has 90 days of this portco’s calls, emails, ICP firmographics, and disqualification reasons in episodic memory will outperform a generic “GPT does outbound” baseline by ≥30% on reply rate within 6 weeks. Eval: per-tenant A/B vs. generic baseline.
  2. Capability index beats static MCP registration. When agents retrieve tools dynamically by embedding similarity + cost/latency/success priors, we ship 50+ tools without bloating any single LLM context past 20. Eval: token cost per task at constant quality, before vs. after capability index lands.
  3. Cross-portco patterns are a moat. Anonymized signal patterns (e.g., “PE-backed industrial-services portcos with EBITDA <$15M who run Google Ads at >$300 CPC see 2.4× higher acquisition cost than peers running LinkedIn ABM”) get richer with every portco onboarded. Eval: at 5 portcos, the pattern-bank should improve a new portco’s first-90-day baseline.
  4. Outcome metering will price out cost-plus consultants. Charging per qualified meeting, per pipeline-lift point, per ad-dollar managed beats hourly fractional CMO billing in margin and in client trust. Eval: unit economics — ARR / portco / quarter under outcome metering vs. hours-based engagement.
  5. The eval dataset is the long-term moat, not the model. Foundation models will commoditize. The proprietary thing in 18 months is “for this tenant, this task, here are 10,000 graded examples and a router that picks the right model+prompt+tools combination.” Eval: per-tenant eval coverage, freshness, A/B win rate.

§3 — Architecture: seven planes

┌────────────────────────────────────────────────────────────────────┐
│  Surface Plane   — claude.ai, Cursor, Codex, mobile, Slack, email │
├────────────────────────────────────────────────────────────────────┤
│  Agent Topology  — 19 agents, each a per-(tenant,agent_type) DO    │
├────────────────────────────────────────────────────────────────────┤
│  Eval & Learning — per-tenant datasets, A/B router, bandit weights │
├────────────────────────────────────────────────────────────────────┤
│  Inference Router — Cerebras triage → Anthropic/Gemini reasoning   │
├────────────────────────────────────────────────────────────────────┤
│  Orchestration   — Anthropic planner/fan-out/synth on CF Workflows │
├────────────────────────────────────────────────────────────────────┤
│  Memory          — working/KV · episodic/D1 · semantic/Vectorize · │
│                    procedural/DO-SQLite (all per-tenant)           │
├────────────────────────────────────────────────────────────────────┤
│  Capability Index — Vectorize-backed, dynamic tool retrieval       │
├────────────────────────────────────────────────────────────────────┤
│  Substrate (V5 Gateway) — KV hot path · D1 cold · DO refresh · R2  │
└────────────────────────────────────────────────────────────────────┘

Plane responsibilities, briefly:

  • Substrate (V5 gateway). Already built. Auth, token resolve, fail-fast proxy, AI Gateway. ≤30ms hot-path budget (was 10ms — see §9).
  • Capability Index. Vectorize namespace capability_index. Tools embedded by description + scopes + cost/latency/success priors. Replaces server.registerTool static fanout. Agent retrieves top-K tools per task; LLM context never sees more than ~20.
  • Memory. Four tiers, all per-tenant. See §3.1.
  • Orchestration. CF Workflows step-functions. Anthropic planner emits a graph of step.do(tool, input) calls. Fan-out where independent. Synthesizer collapses results.
  • Inference Router. Cerebras for sub-200ms triage and routing. Anthropic Claude / Google Gemini for reasoning. Multi-armed-bandit weights live in KV per (tenant, task_type).
  • Eval & Learning. Per-tenant golden datasets in D1. A/B routing at the orchestration layer. Bandit updates from real outcomes (meeting booked / pipeline created / ad CAC). The compounding asset.
  • Agent Topology. 19 agents, see §4. Each is a per-(tenant, agent_type) Durable Object.
  • Surface Plane. Already partially wired — claude.ai, Cursor, Codex CLI, iOS, Slack monitor. Add: PE Operating Partner dashboard (web), portco CMO dashboard (web), board-prep PDF generator.

§3.1 Memory tiers

TierStoresSubstrateTTLRetrieval signal
WorkingCurrent turnKV (TTL’d)~1hRequest scope + key
EpisodicPast sessions / runsD1 memory_episodes (per-tenant)90d hot, 5y cold (R2)Recency × task-type relevance
SemanticPer-tenant factsVectorize (per-tenant namespace tenant_{tenant_id})NoneVector similarity
ProceduralLearned workflowsDO SQLite (per-tenant)NoneTask-type match × bandit weight

KV-only-everywhere is no longer the rule. Hot path stays KV. Cold paths use the substrate that fits the data shape.

§3.2 Capability index KV/Vectorize schema

capability_index:{tool_name} → {
  embedding_id,
  namespace: "capability_index",
  provider: "hubspot" | "google_ads" | …,
  scopes_required: [...],
  cost_estimate_usd,
  avg_latency_ms_p50,
  avg_latency_ms_p99,
  success_rate_p50,
  success_rate_p99,
  schema_ref: "kv://tool_schemas/{tool_name}",
  combines_with: [...other_tool_names],
  graph_depends_on: [...],
  last_updated: "..."
}

Retrieval: agent emits intent → Vectorize top-K → priors filter (scope, cost ceiling, latency ceiling) → top 10–20 tool schemas hydrated into LLM context.

§4 — Agent topology: 19 agents

Three rings. Each agent is a per-(tenant, agent_type) DO. SQLite-backed (per ADR-026).

Ring 1 — Per-portco agents (10)

  1. SDR Agent — outbound sequencing, reply triage, meeting booking
  2. Pipeline Reviewer — weekly deal-by-deal stage hygiene + risk flag
  3. Forecast Agent — opportunity-weighted forecast vs. plan
  4. ICP Scorer — fit + intent scoring on inbound + buy-list
  5. Paid Channel Allocator — Google + LinkedIn + Meta budget moves vs. CAC band
  6. Content Distillation Agent — Gong call → battle card / objection map / ICP refinement
  7. Account Brief Agent — 1-page brief for any account, on demand
  8. CRM Hygiene Agent — owner / stage / amount / close-date sanity
  9. Reporting Agent — weekly + MoM dashboards, exec one-pager
  10. Onboarding Agent — net-new client provisioning (auth, ICP discovery, SLA contract, first agent boot)

Ring 2 — Per-fund agents (5)

  1. Cross-Portco Benchmark Agent — anonymized peer-set metrics
  2. Operating Partner Brief Agent — board-prep / investor-update one-pagers
  3. Pattern-Transfer Agent — “Portco A solved this; Portco B has the same pattern, here’s the play”
  4. Fund-Level Pipeline Roll-up — cross-portco bookings / pipeline / CAC trend
  5. Diligence Agent — pre-acquisition GTM diligence (clean room mode)

Ring 3 — Mishaal-operated (4)

  1. Ascend Pipeline Agent — our own pipeline (dogfood)
  2. Ascend Content Agent — our own thought leadership / SEO / outbound
  3. Platform Telemetry Agent — usage, cost, eval drift, agent-level SLO
  4. Customer Success Agent — every portco’s last-7-day signal + escalation queue

Total: 19. None of these are static prompt templates. Each is a DO instance per tenant with its own memory, its own evals, its own bandit weights.

§5 — Five compounding loops

These are the things that make the system worth more in month 12 than in month 1.

  1. Capability index. Every new tool added → embedded → discoverable by every agent across every tenant. Index gets denser; tool selection gets cheaper and more accurate.
  2. Eval dataset. Every agent run produces a (input, output, outcome) tuple. Per-tenant, this is the dataset that fine-tunes routing and prompt selection. 2027 moat.
  3. Procedural memory. Successful task graphs (“how SDR Agent for Portco X books meetings”) are stored, weighted, and replayed. Bandit selects the high-EV graph next time.
  4. Fund benchmark. Each portco onboarded sharpens the peer-set. Operating Partners get more useful comparisons over time.
  5. Cross-portco pattern bank. Anonymized “what worked in Portco A is structurally available to Portco B” recommendations. Hardest to replicate; hardest to start.

Each loop has measurable second-derivative output. We track all five.

§6 — Operating model: both buyers, simultaneously

Adopted 2026-05-07. We do not pick fund-down vs. portco-up. We do both, in the same week, with the same substrate.

ChannelMotionWho runs it
Fund-downDirect outbound to PE Operating Partners + Operating Executives at MM/LMM funds. Land = 1-portco pilot inside their portfolio.Mishaal direct
Portco-upDirect outbound to CMO / VP Sales / VP RevOps at PE-backed B2B portcos ($5-50M ARR band). Land = per-portco subscription.Mishaal direct, then SDR Agent dogfood
Ascend (dogfood)Internal use across our own pipelineMishaal

Same substrate. Same agents. Different commercial wrapper (fund-level platform fee vs. portco subscription vs. internal).

§7 — Velocity SLAs (engineering)

CadenceTarget
Plan-first PR for any new project<1 day from idea to merged plan-first PR
New per-tenant agent (cold-start to first useful output)<2 weeks
New tool indexed into capability index<1 day from wrangler secret put to discoverability
Portco onboarding (auth → first agent boot → first useful weekly brief)<7 days
Eval dataset coverage (per active agent_type, per tenant)≥100 graded examples within 30 days of agent going live

§8 — Outcome-based pricing

We charge for outcomes, not time. Pricing surfaces:

  • Per qualified meeting — SDR Agent floor + commission
  • Per pipeline-lift point — Pipeline Reviewer / ICP Scorer commission
  • Per ad-spend dollar managed — Paid Channel Allocator (% of spend, capped)
  • Per-portco subscription — flat platform fee covering Rings 1+3 for that portco
  • Fund-level platform fee — covers Ring 2 cross-portco agents at fund scope

We commit to outcomes the substrate makes us comfortable committing to. Where outcomes are noisy, we ship in shadow mode and meter usage until eval coverage hits the SLA in §7.

§9 — Killed constraints (formerly canonical, now retired)

These are constraints from .claude/rules/v5-invariants.md and prior PRDs that the Operator OS retires or reframes. Each requires its own ADR before code lands. The current invariants stay in force until those ADRs ship. ADRs are pre-listed here for traceability.

Old constraintNew positionADR slot
Gateway hot-path overhead ≤10ms (invariant 10)≤30ms — we add capability-index retrieval and per-tenant memory lookup to the hot pathADR-041
35-tool ceiling, static server.registerTool (invariant 7)Unlimited tools in capability index; ≤20 surfaced to any single LLM context via dynamic retrievalADR-042
KV-only hot path (invariant 2)KV-only for working memory + token resolve. Vectorize for capability + semantic. D1 stays cold. DO SQLite stays per-tenant procedural.ADR-043
MCP composites (was on roadmap)Deferred to Phase 5+. Capability index makes composites unnecessary at <50 tools.ADR-044
Per-(tenant, agent_type) DOs as primary primitiveConfirmed. Adds to existing TokenManager DO.(no ADR — extends invariant 6)

§10 — Twelve-month build plan

Q1 — Foundation (Operator OS Q1 — see docs/plans/OPERATOR-OS-Q1-FOUNDATION.md)

Five parallel tracks. Engineering-led sequencing per ADR-040.

  • Track A — Per-tenant agent DO + 1 SDR Agent. Weeks 1-6. Single agent end-to-end: per-(tenant, sdr_agent) DO, working + episodic memory, Langfuse traces, A/B vs. generic baseline.
  • Track B — Capability index. Weeks 1-8 (parallel to A). Vectorize namespace, embedding pipeline, retrieval helper, tool-priors writer, integration into agent runtime.
  • Track C — Per-fund agent DO + cross-portco read view. Weeks 4-12. Operating Partner brief, fund-level roll-up, anonymized peer benchmark.
  • Track D — Semantic + procedural memory tier upgrades. Weeks 6-12. Per-tenant Vectorize namespace, DO SQLite procedural store, retrieval into agent runtime.
  • Track E — Per-tenant evals + A/B routing + Cerebras triage. Weeks 8-12. Per-tenant eval dataset table, A/B at orchestration, Cerebras routing tier.

Q2 — Land paying portcos + first fund

  • 3 portcos onboarded under per-portco subscription
  • 1 fund-level platform agreement signed (1 portco pilot inside it)
  • Eval coverage SLA hit on SDR Agent + Pipeline Reviewer + ICP Scorer for all active tenants

Q3 — Compound

  • Cross-portco pattern bank live (≥3 portcos = peer set)
  • Outcome metering live for ≥1 surface (per qualified meeting)
  • Operating Partner dashboard GA

Q4 — Scale

  • 10 portcos, 2 funds
  • 19-agent topology fully populated for at least 1 tenant
  • First public retrospective on capability-index efficiency vs. static MCP

§11 — What this isn’t

  • This is not n8n-style “drag-and-drop workflow builder for marketers.”
  • This is not a generic chat-with-your-CRM bolt-on.
  • This is not “ChatGPT for sales reps” (no per-tenant memory; no multi-agent topology; no eval moat).
  • This is not an open-source product. Substrate is proprietary; capability schemas are open-able if it accelerates distribution.
  • This is not a single-buyer ICP. Fund AND portco; we will get told “no” in both directions and that is fine.

§12 — Ten non-consensus bets

  1. PE Operating Partners are an underpriced GTM-software buyer. Most GTM tooling sells portco-by-portco; fund Op Partners hold actual budget and decide whose tool gets used across 10+ portcos.
  2. MCP gateways become commoditized in 18 months. We bet on what sits on top of MCP — the capability index, the eval router, the per-tenant memory.
  3. Outcome pricing wins in PE-portco land. PE buyers have real outcomes; cost-plus consultants do not survive the next downturn.
  4. Per-tenant evals are the moat. Not the model, not the gateway, not the prompts.
  5. Cross-portco anonymized patterns are legally and contractually feasible with the right MSA. We will build the MSA template.
  6. CF Workers + Workflows + DOs are the right primitive for multi-tenant agents at our scale. We do not need K8s.
  7. One operator (Mishaal) plus 19 agents can serve 10 portcos by Q4. This is the compounding-loop bet.
  8. Cerebras / fast-inference becomes table stakes within 12 months. Triage layer must already be built.
  9. Procedural memory matters more than chat memory. Past workflows that worked > past messages.
  10. The Ascend dogfood loop is non-negotiable. Every agent runs against our own pipeline first.

§13 — Success criteria (12 months)

  • ≥10 portcos paying, ≥2 fund-level platform agreements
  • ≥$1.5M ARR, ≥80% gross margin
  • Capability index ≥50 tools, ≤20 surfaced per task on average
  • Per-tenant eval coverage ≥100 examples for every active agent_type
  • ≥1 documented cross-portco pattern transfer with measurable lift
  • Hot-path overhead ≤30ms p99
  • Zero loss-of-tenant-isolation incidents

§14 — Ten open strategic questions (deferred, not blocking)

  1. Do we white-label the Operator Partner dashboard for funds, or run it under Ascend brand?
  2. Do we expose the capability index publicly (bring-your-own tool) or keep it closed?
  3. At what portco count do we hire a second engineer?
  4. Do we accept SOC 2 Type 2 audit cost in Q3 or defer to Q4?
  5. Do we open-source the per-tenant eval format as a wedge against incumbents?
  6. How do we price diligence agent (Ring 2 #15) — per-deal or annual fund retainer?
  7. Do we run a private design partner program for Op Partners, or sell outright?
  8. What’s the first portco we fire and why? (define exit criteria up-front)
  9. Do we build a marketplace for community-contributed agents, or stay first-party only?
  10. When does this product earn the right to pursue Series A capital?

§15 — One-paragraph summary

The Ascend Operator OS is a multi-tenant agent platform on Cloudflare Workers that gives PE Operating Partners and the GTM leaders inside their portfolio companies a shared substrate of 19 specialized agents, each backed by per-tenant working/episodic/semantic/procedural memory, dynamic capability retrieval against a Vectorize-indexed tool catalog, and per-tenant eval datasets that compound into a durable moat. We sell to funds and to portcos simultaneously under outcome-based pricing, dogfood every agent against our own pipeline first, and bet that in 18 months the proprietary asset is not the model — it’s the (tenant × agent × eval × capability) graph we are building today.

Appendix A — Retired positions

PositionStated whereRetired onReplaced by
”V5 = MCP gateway with 35 static tools, KV-only, ≤10ms hot path”docs/archive/PRD_GATEWAY_V5_FINAL.md2026-05-07This document. V5 gateway is the substrate. Tool ceiling, hot-path budget, memory model expand per ADR-041 / ADR-042 / ADR-043 / ADR-044.
”n8n is the orchestration plane”early CLAUDE.md globalalready retired (2026-04)CF Workflows + Anthropic planner, per invariant 9 (still in force).
”Static server.registerTool for every new tool”src/handlers/mcp.tsretiring with capability index in Track BDynamic capability-index retrieval. ADR-042.
”KV is the only acceptable hot-path store”invariant 2retiring (hot-path expands to KV + Vectorize lookup)ADR-043.
”Composites are next on roadmap”implicit2026-05-07Deferred to Phase 5+; capability index makes them unnecessary at our tool count. ADR-044.

Appendix B — Adoption decisions

Three decisions blocked any implementation. All three are now answered.

#DecisionStatusResolved on
AAdopt this document as Ascend’s master plan, superseding docs/archive/PRD_GATEWAY_V5_FINAL.md as the strategic source of truth (V5 spec stays authoritative for substrate-only questions)✅ Adopted2026-05-07
BLand at fund level (PE Operating Partners) OR at portco level (CMO/VP Sales/VP RevOps) — pick the dominant motion✅ Both, simultaneously. No single dominant motion. Same substrate, two commercial wrappers.2026-05-07
CQ1 sequence — do we do it phase-by-phase or parallelize✅ Five parallel tracks (A–E). Engineering-led. See ADR-040 + Q1 plan doc.2026-05-07