A product as a forcing function: what FirstHQ is teaching Vocion to build next
We're building FirstHQ (an AI team HQ for agencies) on Vocion — and using it as a forcing function for the platform. Here's the architecture direction it's driving: scoped retrieval with document ACLs, durable ingestion pipelines, a discovery-vs-mutation permission model, and a clean split between the MCP tool plane and the API control plane.
The fastest way to find the holes in a platform is to build a real product on it. So we are: FirstHQ, an AI-team HQ for agencies, runs on Vocion — and we treat it as a forcing function. Every time FirstHQ needs something Vocion doesn't have yet, the rule is the same: build it in the platform, not the product. FirstHQ stays a thin commercial layer; Vocion gets more capable for everyone.
FirstHQ's next two milestones — connect your tools and do real work under human review — surfaced five concrete platform demands. This is the direction they're pushing Vocion (forward-looking; not shipped yet — it's the plan).
1. Retrieval needs scope, not just a tenant
Vocion's retrieval is native (pgvector + Postgres FTS + reciprocal-rank fusion) and org-scoped. That's the right floor — but an agency has many clients inside one org, and one client's documents must never surface in another's work. So retrieval needs scope (workspace → client → team) and document-level ACLs, enforced in the query itself. Retrieval becomes the place we enforce what a principal is allowed to discover.
2. Ingestion has to be durable
"Connect Google Drive" sounds simple until the crawl is 100k documents, the request times out, and you re-fetch from page zero. Synchronous, in-process sync doesn't survive contact with real data. Ingestion becomes a durable Temporal pipeline: resumable cursors, incremental delta sync (honor etag/mtime), scheduled re-syncs, webhook-triggered deltas, and a dead-letter for the document that fails — so doc 487 of 1,000 failing doesn't silently skip the rest.
3. Discovery vs. mutation — the permission model that matters
This is the keystone. Reading is not writing. An AI teammate should be able to discover widely inside its client scope, but mutate — send an email, change a deal stage, publish — only through a gated action. Vocion already gates external actions via the mission autonomy ladder; the next step is to make that one explicit model:
principal (human or agent) × scope × resource × mode (
discover|mutate) × gate (none|approve@autonomy-level).
Discovery is governed by read scopes + ACLs; mutation by action grants + approval. And crucially, one review queue — a gated action is reviewed the same way whether a teammate triggered it through a tool or an app triggered it through the API.
4. Two planes, one authorization
Which brings us to interfaces. Vocion exposes both an MCP server (the agent/tool plane — how teammates and external assistants call tools) and an HTTP/oRPC API (the control plane — how an app drives the runtime: start work, fetch status, approve). The direction:
- API = control plane — app ↔ runtime, with a write API, tenant tokens, and outgoing webhooks.
- MCP = tool plane — agents' tools and external agents, over HTTP + OAuth for multi-tenant use.
- Both call the same authorization + review layer (#3), so gating never diverges between them.
5. One context, authored and ingested
Finally, the connective tissue: authored context (the git-backed workspace) and ingested knowledge
should be one scoped, versioned, provenance-tracked context model — not two stores. Vocion already
stamps every run with a workspace_sha; ingested context should earn the same audit citizenship.
None of this is exotic — it's the difference between a framework that demos and one that runs a real business safely. That's the point of building a product on your own platform: it tells you the truth about what to build next. Full architecture lives in our internal roadmap; the short version is above.