The Grey Matter: The business observability layer you’re

Comments

0

Osvaldo RestrepoMaker

What features would you like to see to improve The Grey Matter's business observability?

About The Grey Matter

The Grey Matter (TGM) is an AI business observability platform built on the Nine Vectors Framework: a canonical view of a company across Assets (market, people, finance), Processes (strategy, operations, execution), and Structures (expectations, governance, entity), decomposed into 37 sub-vectors.

Diagnostic engines run over your own grounded evidence, your documents, financials, interviews, and connected systems. Each engine answers one executive question (pipeline health, forecast, valuation, exit readiness, org design, KPI tracking, DDQ coverage, deal playbook status) and reports what it does NOT know rather than estimating. Results stay scoped to a single workspace, so a portfolio company’s view never leaks across tenants.

TGM orchestrates agents, playbooks, and measurement surfaces so operators, boards, and PE deal teams see where the business actually stands, not where a dashboard says it does. A guided demo walks through a portfolio company end to end.

How it was built with Claude

Claude Code did the heavy lifting. FastAPI + React, Azure Container Apps, Cosmos / Azure SQL / Neo4j, all built against Claude Code day to day. We run multiple worktrees in parallel so several Claude sessions can work on different slices of the product at once without stepping on each other.

The Anthropic SDK powers every diagnostic engine. Each engine is a tool-using agent that reads from the workspace’s own grounded evidence and is required to report what it does NOT know rather than estimate. That constraint is enforced in code, not by prompt alone; “the model confidently made something up” is the failure mode we spent the most time designing against.

An in-house MCP server exposes the whole Nine Vectors toolkit (tgm_board, tgm_forecast, tgm_valuation, tgm_exit_readiness, tgm_ddq, tgm_kpi, tgm_deal_playbook_status, tgm_crm_*, and dozens more). The same engines are callable from Claude Code during development and from Claude Desktop when an exec wants to interrogate their own workspace in natural language. One surface, two audiences.

Claude Skills carry the operator-facing workflows: guided tour, call prep, stakeholder updates, deal review, exit readiness. They live in the repo next to the code they drive, so a workflow change ships like any other PR. The hardest-won prompting lesson turned out to be about the project, not the model: instructions live in CLAUDE.md, but anything the model has to remember to be careful about becomes a CI gate instead. Rules teach, gates catch. The repo’s CLAUDE.md is the reading list; the gates are the safety net.