Make review the API call your AI pipeline is missing

A B2B SaaS team running AI in production posted a blunt account of the gap they had just lived through. Status 200, latency normal, tokens normal, every dashboard green. About one in fifty of their AI responses was hallucinating, and users were the ones flagging it. Their words: “If you are only monitoring latency and error rates, you are missing the quality layer.” That is one team’s measurement, not a market statistic. The shape recurs.

A multi-agent operator on r/ClaudeCode described the same failure mode under a different stack: “traces look fine, just expensive and wrong.” The pipeline runs to completion. Status checks pass. The wrong-but-confident output ships anyway, because the part of the work that catches it lives somewhere your dashboard cannot see. That part is review.

Your pipeline is automated except one step. That step should be an API call. Typescape exposes that missing step as one typed lifecycle: Reviews -> Findings -> Decisions -> Rules -> Rulepacks. API, CLI, MCP, and web are all first-class surfaces with contract parity. This page is not an endpoint catalog or a complete MCP tool registry. It is the contract argument for a builder deciding whether review can become part of the harness instead of a Slack message someone reads later. AI solved production. Nobody solved review.

What your agent receives from a schema=v2 export

Pull a finished review through GET /v1/reviews/{id}/export?schema=v2. The agent receives JSON shaped like the example below. Identifiers, hashes, and timestamps are illustrative; the field shapes come from product source-of-truth.

{
  "schema": "v2",
  "view_resolved": "full",
  "review": {
    "review_id": "rev_01jaqkillustrative",
    "content_ref": {
      "repo_id": "acme",
      "git_sha": "9f2b1c0a8e4dillustrative",
      "file_path": "docs/api.md"
    }
  },
  "findings": [
    {
      "finding_id": "fnd_01jaqsillustrative",
      "anchor_ref": {
        "block_id": "yvqhblpw3kx4g7aqp5n2mvzj7hs6r3wbq5tcylfxe2pdumsvkjqg",
        "block_type": "paragraph",
        "block_key": "pricing-claim-1"
      },
      "body": "Pricing claim contradicts the canonical tier sheet.",
      "severity": "must",
      "rule_basis": {
        "compiled_hash": "a1b2c3d4e5f6illustrative",
        "fetched_at": "2026-05-03T09:42:00Z"
      },
      "request_id": "req_01jaqxillustrative"
    }
  ]
}

schema=v2 is the authoritative export boundary; format=llm_prompt.v1 is convenience-only and is not safe for compliance, gating, or ingestion. view_resolved self-describes which slice the server actually returned, and an X-Typescape-View response header echoes the same value for automation. content_ref pins the review to a repo, a git SHA, and a file path, so the same input always points at the same review identity. anchor_ref.block_id is base32 of a deterministic SHA-256 over canonical inputs, which means the same paragraph produces the same block_id, every time. block_key is an optional human-named override for authors who want a stable anchor by name. rule_basis.compiled_hash and rule_basis.fetched_at ride along with the finding so the server can detect rule drift; staleness is advisory at submit time, never blocking. request_id is the per-call audit handle.

Decisions, evidence, and lineage all travel with the finding inside the export envelope under their own field shapes. Those literal sub-fields belong in the deeper docs, not on this page. The line that matters here is the schema boundary above. schema=v2 is what the next agent run, the next CI gate, and the next human reviewer all read against. For the longer take on the deterministic anchor itself, block-level anchoring explained walks the algorithm.

Pick a surface by where the work happens

Same lifecycle, four call sites. Pick the one that fits where the work actually happens.

REST is for high-volume server automation and CI gates. The first calls a builder reaches for are POST /v1/reviews to open the review and GET /v1/reviews/{id}/export?schema=v2 to pull the canonical bundle. Findings and decisions stay nested under the review (POST /v1/reviews/{id}/findings, POST /v1/reviews/{id}/findings/{id}/decision), and GET /v1/rules returns the active rulepack. Typescape’s REST shape ships under a frozen OpenAPI v1 contract.

CLI is for terminal pipelines and operator runs. The package is @typescape-ai/cli. Install with bun add -g @typescape-ai/cli, or run with bunx @typescape-ai/cli. Bun >=1.3.10 is required, and TYPESCAPE_API_KEY is the only env var you need. The same lifecycle reads as typescape review create, typescape finding create, typescape finding decision, typescape rules get, and typescape review export, each calling the same endpoints.

MCP is for live agent discovery in a host that speaks the protocol. MCP is an open standard for connecting AI applications to external systems. The package is @typescape-ai/mcp, launched with bunx @typescape-ai/mcp. It needs TYPESCAPE_API_KEY and TYPESCAPE_BASE_URL. The agent receives Typescape MCP tools including typescape_create_review, typescape_create_finding, typescape_record_decision, and typescape_export_review, each routed against the same lifecycle. Claude Code and Cursor each manage MCP server config through their own scopes; Typescape owns the server shape and the tool names, not where the host stores the registry. An r/mcp builder shipping a human-preference MCP server framed the open question plainly: he wasn’t “sure what the right abstraction is yet” for human judgment inside agent loops. The lifecycle behind these tools is one answer.

Web is the human reviewer surface. A magic link drops a non-account reviewer into the right block on a desktop or a phone. Their findings, comments, and decisions write to the same record the API serves, and they surface in the same schema=v2 export your agent reads on the next run. Web does not need a row in a programmatic table because it is not trying to imitate one. It is where the humans are; the content approval versus content review line lives on the web side.

What is frozen behind every surface

The contracts that hold this together are frozen by name: export.v2, anchor-ref.v1, content-ref.v1, error-codes.v1, OpenAPI v1, block_id.v1, and block-key.v1. Field semantics never change inside a version. New fields are additive. Breaking changes mint a new major. The frozen layer is what lets you swap models, reviewers, or hosts around the loop without re-teaching anything what a finding looks like.

What does Typescape not automate?

Typescape doesn’t generate content, and it doesn’t tell you what’s good or bad. It captures human judgment as structured data. The intelligence comes from your reviewers and your agents.

That boundary is BYO-agent. Typescape owns lifecycle state, deterministic anchoring, canonical exports, permissions, audit trails, and rulepack delivery. Your harness owns the model, prompt assembly, semantic classification, contradiction assessment by meaning, repeated-issue synthesis, and revision strategy. If a model says two findings are duplicates, that judgment needs to come from your model, your prompt, or an external advisory artifact stored with provenance. Typescape records and routes it without laundering it into product truth.

A recent r/ClaudeCode discussion showed a strict critic-persona prompt producing a sharper one-shot critique on a single GPT report. It can do that. What it cannot do is leave the next reviewer an anchored finding to resolve, compound a decision into a rule, or hand the next agent run a rulepack to load. Useful as a one-shot rewrite. Not the place review state can live. Adjacent thinking on retrieval-as-contract lives at agentic research workflow.

What if the Typescape server is unreachable?

Local rulepacks keep the loop running when the network does not. A rulepack carries a compiled_hash and one of four named freshness states: fresh, presumed-stale, confirmed-stale, and missing. Submissions ride along with the basis the agent used, so offline work submits cleanly when the server comes back. With no cache and the server unreachable, the agent fails explicitly rather than guessing: No cached rules available. Connect to server to fetch rules. The basis the agent claims to follow is the basis it actually has.

Rules themselves move through Draft, Published, Release Candidate, and Activated states. Live rules come only from the active rule release; publishing a revision does not make it live. Operators on r/ClaudeCode already author CLAUDE.md and AGENTS.md style mini-rulesets to keep their settled decisions from re-deriving every session; rulepacks are the compiled, hash-stamped, multi-surface evolution of that idea. The longer take on activation is at rules to rulepacks.

Free: 15 review sessions per month, no credit card required (start free). For unlimited sessions, SSO, and SLA guarantees, contact us.

Bijan Bina, Founder of Typescape