The inquiry desk

A read-only question-answering surface a writing agent can query — what the product is, what's already published, the house voice, linkable routes, the keyword universe with live positions, and what currently ranks for a term.

What it is

Eight whitelisted topics behind one endpoint: product, posts, post (by slug), voice, links, keywords, serp (by keyword) and pages. Each answer is computed live from the same tables the panel reads. The product topic states plainly what the software is, who it is for, what it does, how it is positioned — and what must never be claimed. Calling it with no topic returns the menu.

Also called: agent context API · what does the product do · research endpoint · content context

See it
The inquiry desk
Won
47%
Avg cycle
18d
Pipeline
$599k
JanSep
The topic menu response, then one topic — product — showing whatItDoes, positioning and the neverSay list. Sample data — no customer information appears here.
How it works
  1. 1GET /api/cron/blog-context returns the topic menu with a one-line description of each.
  2. 2topic=posts returns every published post with its target keyword and the rule not to duplicate one.
  3. 3topic=keywords returns the universe with stage gate, unlocked flag, season label and the current live position for each term.
  4. 4topic=serp costs a real SERP call, and the menu says so, so it is only asked when it matters.
  5. 5An unknown topic is a 400 with the whitelist, not a guess.
  6. 6The route is read-only by construction — it exposes no customer or tenant data and has no write path.
Why we built it

The header explains why context is answered rather than shipped: "That machine cannot reach the database, and it starts every run with zero memory of this business. Handing it one frozen blob of context at assignment time would work exactly until something changed — a new product capability, a post that shifted position, a price. So instead of a bigger payload, it gets a QUESTION-ANSWERING SURFACE… Nothing is stale because nothing is cached." The product description lives in the repo for the same reason as the voice: "so it is reviewed like code rather than living in a scheduler's prompt box where nobody sees it drift."

The problem
  • A remote writer had no live view of the product, the published set or current rankings.
  • A frozen context blob goes stale the first time anything changes.
  • Product claims drifted because they lived outside the repo.
Sound familiar?
What you get
Every answer is computed live, so nothing the agent reads is stale
What must never be claimed is stated explicitly and versioned in the repo
Read-only and topic-whitelisted — no customer or tenant data is reachable

See it on your own jobs

Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.

or keep browsing features →