Made Scientific

The Operating System

How Made builds. The method is contextual engineering: assembling the right context, skill, tools, and harness for one specific task, at the right level of autonomy, in a system that writes its results back into the same modular context it read from. This page is the launcher — each section defines a piece and drills into the real artifact behind it.

Section 1

The Methodology — Contextual Engineering

The LLM is a processor. The product is the software around it. What makes a processor useful is assembling, at the moment of the task, the right four things — and then writing the result back into the same system it read from. That last step is what compounds.

Context
What it must know. Authored in git across the wiki and the spine, served from the Transfer and RAG databases.
+
Skill
How to do it. 70 registered in os_skills across 24 capability domains.
+
Tools
What it acts on. 20 registered surfaces, each with a credential and usually a bill.
+
Harness
The box it runs in. 9 patterns on the menu; process model, state, retries, cost.
→
Task, done
At the right level of autonomy for the job.
↵  And it writes back. New skills, corrected identities, proposed matches, updated registries. A system that consumes context but never returns to it degrades; one that writes back compounds.
Made's write-back path is unusually disciplined, and it is worth naming. The entity-resolution ring writes propose-only: RESOLVER and MADE-ID CUSTODIAN land candidates in er_identity_proposals / er_account_census and a human promotes them. Nothing silently edits canonical companies. That is the same propose-then-confirm rule the methodology asks for, already implemented.
Read this first
The Outbound Engine, end to end
The canonical narrative for the whole commercial engine — Parts A–D, sections 0–27, including the gap register and status tracker this page reads from.
The front door
Read →
Before building
The app-factory workflow
Define the job in one sentence → pick the smallest pattern → check the skill exists → key everything by made_id → keep writes propose-only → log a heartbeat.
6 steps, in the harness menu
Open the workflow →
The map
Wiki index
The linked expansion of the spine: 38 systems, 20 concepts, 4 entity registries, and the reference tree. 4 brand packs sit underneath it.
92 markdown files
Open the index →
Section 2

LLM as Processor — Three Access Patterns

These are access patterns, not product tiers. A "real agent" is not better than a one-shot — it is more expensive and less predictable. Choose the cheapest pattern that closes the task.

PatternWhat it isUse whenLive at Made
One-shotSingle pass in, structured output outThe task is a function: classify, extract, render, scoreSCOUT — the scout-research Edge Function, one Claude call, about $0.10 a run
LoopIterate until a breaker firesThe first answer is usually wrong and there is a way to check itFORGE — overnight Claude Code review loop · BIBLIOGRAPHER with citation and brand-voice gates
AgentReasons over tools, chooses its next step, holds stateThe path cannot be enumerated in advanceCHIEF — the FastAPI conductor at /opt/made-chief that routes to the brain or proxies SCOUT
Depth and width are different axes. Loop = depth (does it iterate?). Swarm = width (does it parallelize?). Swarms help genuinely parallel work and degrade sequential reasoning badly; a single agent tops out around 10–15 tools. Default to a single one-shot; widen or deepen only with a reason you can state out loud.
A loop without codified breakers is not finished. Required whenever the shape is not one-shot: a max-turn cap, a per-run dollar cap, duplicate-call detection, a wall-clock timeout, and an explicit "I'm stuck" exit. Made already does this in the right places — BIBLIOGRAPHER carries a budget cap, the signal-desk pattern specifies bounded LLM triage nodes, and the regen-radar crons wrap every run in flock so a slow run cannot stack on itself.
Section 3

The MCS Spine — Git and SQL, on Purpose

The Modular Context System is the durable layer the fleet reads from. It exists twice, deliberately, because the two substrates are good at different things. The rule: author in files, retrieve and telemeter in a database.

Substrate A
Git — the authoring truth
Diffable, reviewable, replayable, and agent-native. Holds the spine narrative, the 92-file wiki, the skill definitions, and the brand packs. Git is the audit log.
Fails at: concurrent writes corrupt silently · grep degrades on paraphrase · no telemetry
Substrate B
SQL — the serving truth
Concurrency, row-level access, semantic search, per-invocation analytics. Holds the os_* registries, the er_* resolution tables, operational CRM state, and about 791K embedded chunks.
Fails at: opaque without tooling · awkward to review · drifts from authored truth
Why the projection matters here specifically. A skill row in os_skills carries both a git_path and a content_sha. That pairing is the whole idea: the definition is authored and reviewed in git, and the registry serves it with telemetry attached. When the two disagree, git wins and the row is stale — which is a detectable condition, not a mystery.
Skills by source repoCount
MadeSciComandCenter26
made-reporting-ux15
made-ai-os15
made-skills14
The real problem
Context scattered across repos
Made's work grew across several repos and databases at once, which is exactly why this page exists: to centralise the definitions so Joe, Brian, and the rest of the team read one map instead of three. The repo split above is the measurable version of that problem.
Consolidation is the point
Known drift
The made-ai-os registry freeze
A second agent/skill registry lives on the made-ai-os database and was frozen on 2026-05-06. os_* on Transfer is the live one. Two stores means reconciliation work, tracked in the skills-library note.
Read the reconciliation →
Section 4

Skills — What Made Knows How To Do

A skill is a packaged capability: how to do one thing Made's way, written down once and reusable. Every row carries its own classification — capability, domain, maturity, priority, and the harness it prefers — per the front-matter contract.

70
skills registered
24
capability domains
62
active
3
p0 core
58%
mean maturity
66
distinct data sources
How to read the maturity number. Mean maturity is 58% across the library, which is the honest signal that this is a working system rather than a finished one. Maturity is authored per skill, so it moves when the skill actually improves — not when someone updates a slide.
Top capability domainsSkills
design17
dev11
classification8
reporting7
integration3
proposal2
forecasting2
agentic2
pipeline2
competitive_intel2
Browse
Skills Library
All 70 skills, filterable by capability, domain, status, priority, maturity, and harness affinity — each showing the data sources it touches and the agents that load it.
Generated from os_skills
Open the library →
The contract
Front-matter contract
What every skill file must declare before it counts as registered: the classification fields, the trigger phrases, and the data sources it is allowed to touch.
Read the contract →
The split
Domain groups
commercial 37 · shared 33. `shared` skills are the ones any department can load; `commercial` skills belong to the outbound engine.
The gap worth naming here: 30 of 70 skills have no agent wired to them. A skill with no caller is documentation, not capability — valuable, but it is not running. Section 11 tracks this.
Section 5

Tools — the Fourth Piece

A skill says how. A tool is what it acts on: an external surface with an API, a credential, and usually a bill. Until 2026-08-04 Made had no tool registry at all — the surfaces were real and paid for, but nothing enumerated them.

20
tools registered
18
actively called
2
idle or dark
5
tool classes
Registered but not earning yet: clinicaltrials_gov, resend. Keeping these visible is the point of a registry — a credential you pay for and never call is a cost with no counterpart.
The honest framing, and it should stay consistent everywhere: the vendor tools are commodity subscriptions. Anyone can buy Clay, EmailBison, HeyReach, and Firecrawl. The edge is the custom interconnection built between them — the staging pipelines, the identity resolution, the classification, the message generation, the reply routing. The subscriptions are the cost; the wiring is the asset.
Tools by categoryCount
hosting4
intelligence4
build_tooling3
outbound3
crm3
model2
find_and_enrich1
Browse
Tools Library
Every tool by class, category, access surface, auth model, cost shape, and host — with the evidence trail for why each one is marked active, configured, or unused.
Generated from os_tools
Open the library →
Why this table exists
Seeded from evidence, not memory
Every row was seeded from something observable: a running container image, a cron command, a CRM table referenced by a skill, or an agent's declared platform. Nothing was added because it felt likely to be in use.
Seeded 2026-08-04
Section 6

Brand & Content Spine

The brand bible is the immutable layer: tools and skills change constantly, the brand does not. Made runs 4 packs — not one per client, because Made is a single company, but one per audience surface. A content skill is correct only when it loads the right pack through the standard contract rather than hardcoding a colour.

4
brand packs
4
complete packs
17
design skills
Design tokens
Immutable truth — colour, type, spacing, components
→
Brand pack
Per-surface routing — which identity applies
→
Content skills
Brand-pluggable, never brand-hardcoded
→
Channels
Where it ships
Default
made-scientific
The primary Made Scientific identity. Carries the v2 token lock the whole system themes from — including this page.
complete — brand.json + design-tokens.json
Public site
made-original
The public-facing web identity, kept distinct from the internal application surfaces.
complete — brand.json + design-tokens.json
Portfolio
made-regen
The regenerative-medicine portfolio identity used by the Regen surfaces and the longevity briefs.
complete — brand.json + design-tokens.json
Unbranded
partner-neutral
Deliberately neutral output for partner-facing documents that should not carry Made's identity.
complete — brand.json + design-tokens.json
This page is its own proof. Every colour above was read from brands/made-scientific/design-tokens.json at build time rather than typed into the generator. Change the token, rebuild, and the page changes with it — which is the only version of "on brand" that survives contact with a system.
The standard
Design framework
The brand bible source of truth: the v2 token system and the prompt packs the asset-generation skills read.
Read the standard →
Browse
Brand Spine Matrix
Every pack graded against the standard — required files present, token completeness, contrast pass or fail, and which content skills each pack can actually feed.
Computed from the packs themselves
Open the matrix →
Section 7

Harnesses & the Fleet

Once you know the context, skill, tools, and shape, the harness is the environment that runs it: process model, state, retries, credentials, observability, cost. Made keeps a menu of nine patterns and picks the smallest one that fits, rather than inventing a shape per agent.

9
harness patterns
49
agents registered
15
live today
8
harnesses in use
9
fleets
PatternShapeMade example running todayWhen to pick
Edge Function + 1 LLM callone-shotSCOUT — Brave + Firecrawl + ClinicalTrials + one Claude callOn-demand research or a single structured output, cheap
Runner + eval gateslong researchBIBLIOGRAPHER — RAG-grounded, citation + brand-voice gates, budget capDeep multi-source reports where grounding and quality gates matter
Propose-only cronscheduled enrichmentRESOLVER, MADE-ID CUSTODIAN — write to er_*, a human approvesRecurring cleanup on shared data that must stay human-gated
FastAPI conductorrouter / dispatcherCHIEF — /opt/made-chief, routes to the brain or proxies SCOUTOne front door that observes agents and runs the safe ones
brain-api /chatgrounded Q&AMADE BRAIN — over roughly 791K RAG chunksAnswer questions from Made knowledge, with citations
n8n workflowvisual DAGPULSE, KFSH EXECUTIVE TRAINER — the twng tenantScheduled integrations non-engineers can edit
Claude Code on the VPSautonomous codingFORGE — overnight review loop on bc-madeLong builds, editing agents and workflows live
LiteLLM proxymodel routerlitellm-made — one model surface for the fleetSo agents never hard-code a provider
Multi-source signal deskrecurring monitorREGEN-RADAR — adapters, prefilter, bounded triage, curated feedMany feeds into one gated, curated vertical feed
The principle behind the menu. Default to strong, boring, well-supported building blocks — Edge Functions, Postgres, FastAPI, LiteLLM, n8n — and refine one consistent Made method instead of chasing every new framework. Six months is an eternity in this space, so the menu is deliberately short and every addition has to earn its slot.
Agents by fleetCount
knowledge-platform12
commercial12
growth7
research6
ceo-office5
training3
bd2
made-os1
scientific1
Browse
Fleet Library
All 49 agents with harness, archetype, trigger, owner, host, and live health — joined to the runtime sweep so registered state and running state sit side by side.
Generated from os_agents x os_runtime_bindings
Open the library →
Browse
Methodology Map
The narrative plus the full harness menu, the decision tree, the loop and swarm vocabulary, and the app-factory workflow.
Open the map →
The menu
Harness menu
The authored source: nine patterns, a 60-second decision tree, and the rule that inventing a new shape requires writing it down first.
Read the menu →
34 of 49 registered agents are not live. That is not a failure — a registry that only lists what already runs cannot be used to plan. But it does mean the fleet count is a roadmap, and the number that describes today is 15.
Section 8

Retrieval & Graph

The 2026 consensus is that retrieval is a three-stage pipeline — retrieve (keyword + dense) → fuse → rerank — and that a graph earns its place only when questions are genuinely multi-hop. Made is further along here than most builds of its age, so this section is less apologetic than the equivalent one elsewhere.

~791K
embedded chunks
voyage-3
embedding model
rerank-2
reranker
4
graph traversal RPCs
Works
Grounded Q&A Live
The RAG brain serves roughly 791K chunks with voyage-3 embeddings and a rerank-2 reranking stage. MADE BRAIN and CHIEF both answer over it with citations.
RAG Content DB · fdeyctgjudypbcqnmagw
Works
The canonical graph Live
Monocle links account, contact, campaign, and opportunity, keyed by made_id, with four bidirectional traversal RPCs. The relational questions a vector search cannot answer have a real path.
Keyed by made_id, not by name
Design only
The dual-corpus rollup Not built
Splitting commercial and scientific corpora with change-safety zones is specified but not implemented. Today it is one corpus with mixed domains.
wiki/systems/brain-domain-architecture.md
Reranking is the single highest-leverage retrieval component, and Made already has it. That is worth stating plainly, because it is the piece most builds skip. The reranker is what turns "the right document was somewhere in the top 20" into "the right document is first".
The honest limitation is entity resolution feeding the graph, not the graph itself. Monocle's traversals are only as good as the made_id keys underneath them, which is exactly why the resolution ring is propose-only and still draining a backlog. A graph over ambiguous identities returns confident nonsense — so the sequencing here is correct even though it is slower.
Reference
The RAG brain
How the corpus is built, chunked, embedded, and served — plus the build plan for what is next.
Read the reference →
Reference
Monocle canonical graph
The account↔contact↔campaign↔opportunity graph and its four traversal RPCs.
Read the reference →
Section 9

Tech Stack & Infrastructure

For an agent to have a place to live, be hosted, and hold a domain, there has to be a server. Made runs on one: bc-made. Everything below is that answer, plus the database estate behind it.

1
VPS
44
live runtime processes
22
catalogued
22
uncatalogued
What is actually running right now: 19 web · 15 cron · 8 container · 2 n8n. That inventory is not typed here — it comes from a sweep of the host that refreshes every 30 minutes, so this section is accurate as of the build rather than as of the last time someone remembered to update it.
LayerWhat runs thereNotes
bc-madeThe whole Made estate — CHIEF, MADE BRAIN, the SSO agent, the resolution ring, the signal desks, every static surfaceTraefik terminates TLS for every *.srv1472429.hstgr.cloud host
litellm-madeThe model router — one surface so no agent hard-codes a providerPort 4000. Not itself catalogued as an agent
n8n (twng tenant)The non-reasoning glue: polling, routing, syncs, notificationsSelf-hosted with its own Postgres. Not the agent runtime — that is section 7
Primary
Transfer DB
Canonical companies, leads, campaigns, outreach messages, the er_* resolution tables, and the os_* registries this page reads.
jrfcfayphcmaxsixxupu
Primary
Reporting DB
External CRM truth — Salesforce and HubSpot accounts and contacts, Monday, PandaDoc sync.
xyopyttkhoxvnyeyijzb
Primary
RAG Content DB
The brain corpus: roughly 791K chunks, voyage-3 embeddings, rerank-2 reranking.
fdeyctgjudypbcqnmagw
Primary
GlobalData / SEC
Market intelligence and filings reference.
hcyqnlyseunynswgtwax
Primary
Demand + Revenue
Capacity planning and revenue forecasting for commercial operations.
lyxvgbavbthyggeutzru · iyibciagadgbjuphzjvr
Registry
made-ai-os
The earlier mission-control registry. Frozen 2026-05-06 — os_* on Transfer is the live one.
dgqkniflkzhvivczcung
One external dependency worth being explicit about. The Central Hub database is managed by the consulting team, and Transfer caches from it nightly rather than reading it live. That boundary is deliberate: Made's estate stays functional if the upstream is unavailable, at the cost of the cache being a day old.
Reference
Database atlas
The full estate with per-database roles, project IDs, and which application client reads each one.
Open the atlas →
Section 10

Process Traces

Worked end-to-end paths through the system — the methodology above, instantiated on Made's actual data. Each trace names the real Edge Function, RPC, or cron at every step, which is what makes them reviewable rather than decorative. Most follow the data; MADE-ID Custodian is the one that follows ownership and rule — who is allowed to decide two records are the same thing, and on what evidence.

Live diagram
Account & contact lifecycle
Six phases, thirty stages: intake → account classification and the enrichment ladder → MADE-ID identity → contact classification and reachability → scoring, flags, relationship state → the SSO handoff. Every stage traced to its real function, with live coverage percentages.
The most complete trace Made has
Open the diagram →
Live diagram
Data & systems inputs map
The database estate and twenty-six input channels in five swimlanes: upstream hub, CRM and business systems, enrichment providers, life-science intelligence, and channel feedback.
Where everything enters from
Open the diagram →
Live diagram
CRM mapping
How Salesforce and HubSpot records reconcile against canonical Made records — the field-level crosswalk and the matching path.
The SFDC / HubSpot question
Open the diagram →
Live diagram
MADE-ID Custodian
The canonical ID system, and the agent that runs it: the custodian's six lanes and run ledger, Greg Shell's three-axis corroboration model and why absence caps a score's ceiling, where an ID is minted for a company, person, opportunity or campaign — and the human gate every account match must pass. Companion to CRM mapping: that page is what arrives, this one is who owns resolving it.
One ID, mapped to every external one
Open the diagram →
Live diagram
Science mapping
Where every scientific fact on an account comes from — nine origin systems, six field families, the gold-sheet resolution, the provenance dot, and five measured conflicts. Includes the HubSpot modality values that never reach the engine and the trust tier that is ranked backwards.
Provenance, end to end
Open the diagram →
Live diagram
Account filters & the visible universe
Why the account page shows only a fraction of all accounts: four predicates baked into the view, one default applied by the app, and the accounts with real Salesforce opportunities that cannot be found. Every filter key mapped to the column it hits.
The visible-universe question
Open the diagram →
Live diagram
BEACON build map
The inbound lead agent traced stage by stage: a form fill on the Made site → a junk and qualify gate → do we already know this person and company → the same enrichment and classification ladder every other record runs → territory and owner → an SSO-ready picture, and only then a decision about what to do. Nine phases, 46 stages, each naming the real function behind it and whether it exists, is stale, or was never built.
The first agent built together
Open the diagram →

Where a trace follows the data, an anatomy follows one agent all the way down — its prompt, its tools, its budget, its failure paths. Three exist, and the third describes an archetype rather than a single agent. They are the most detailed pages on this site, and all three are hand-authored rather than generated, because the interesting parts are in the source, not the registry.

Agent anatomy
SCOUT
The on-demand research agent, read out of scout-research/index.ts: the constants, the Brave and Firecrawl calls, the ClinicalTrials lookup, the budget guard, and every error path. The worked example of the cheapest harness on the menu.
Edge Function + one LLM call
Open the anatomy →
Agent anatomy
SSO AGENT
The segment–signal–offer matrix that turns a resolved account into a specific message, and the architecture behind it. The convergence point where enrichment, identity, and classification finally pay off.
The matrix, end to end
Open the anatomy →
Agent anatomy
SIGNAL DESK
The one anatomy that documents a pattern rather than an agent: a recurring multi-source monitor that discards what is off-topic before spending anything, structures what survives, and publishes only what a human approved. It earns the word archetype because Regen Radar and CGT Radar are the same Python package pointed at different namespaces by an environment overlay, with no fork between them.
Instantiated twice from one codebase
Open the anatomy →
Course
Commercial OS Academy
The nine-deck walkthrough of the commercial operating system — the narrative companion to this site. Served separately at made-academy.
Nine decks
Open the academy →

The traces below are authored in the wiki and are the next candidates to become diagram pages. They are listed here because the written version already exists and is accurate — the visual is the missing half, not the understanding.

Trace
Account enrichment ladder
How a thin company record becomes an enriched one: the ordered rungs, what each provider is asked for, and where the spend gates sit.
Read the trace →
Trace
MADE-ID entity resolution
The matching ladder — negative check, alias, rule, domain, name, trigram, LLM, mint — producing a candidate set rather than a pre-picked winner. Match before mint; never silently discard.
Read the trace →
Trace
SSO matrix → message
The convergence point: how segment, persona, and signal resolve into a specific outreach message, and the hard rules every message obeys.
Read the trace →
Trace
Reply handoff
The four reply outcomes, the territory-rep dossier that goes with each, and the suppression and re-engagement rules.
Read the trace →
Trace
CRM field map
The field-level crosswalk between Salesforce, HubSpot, and Made's canonical schema — the written source behind the CRM mapping diagram.
Read the trace →
Trace
Campaign intake
The campaign design worksheet: the human front door that feeds the list builder, then SSO, then the sending channels.
Read the trace →
Section 11

Gaps — What Is Not Built

An explicit list, mostly computed rather than typed. This section exists because a map that only shows what works is a brochure. The audience is internal, so everything below is real.

Most of this table regenerates itself. The counts come from reconciling os_agents and os_skills against os_runtime_bindings — a sweep of bc-made that refreshes every 30 minutes. A gap register that is generated cannot quietly go stale the way a hand-maintained one does, which is the failure mode this section is designed to avoid.
GapWhy it mattersState
22 of 44 running processes are not registeredAnything not in os_agents has no owner, no documented purpose, and no one accountable when it breaks. Breakdown: 16 web · 2 n8n · 2 container · 2 cronReconcile
5 agents marked live have no matching green process — EVENT-SCRAPER, FORGE, KFSH EXECUTIVE TRAINER, RESOLVER, SCOUTEither the agent is not actually running, or its runtime label does not match its registry name. Both are real problems and they look identical from hereInvestigate
RESOLVER's runtime is still labelled RALPHThe agent was renamed from Made-Ralph, but the nightly cron at /opt/made-ralph still reports as RALPH — which collides with the separate RALPH contract-QC agent. Two different things answer to one nameName collision
30 of 70 skills have no agent wiredA skill with no caller is documentation rather than capability. Useful for humans, but it is not doing workIn progress
1 live agent declares no harness — RALPHWithout a harness the agent's process model, retry behaviour, and cost profile are undefined, so it cannot be reasoned about or safely changedClassify
Two registries still exist — os_* on Transfer and the frozen made-ai-osFrozen 2026-05-06 but not retired. Any reader who finds the old one first gets stale answers with no warning that it is staleReconcile
The dual-corpus brain split is design-onlyCommercial and scientific knowledge share one corpus, so a commercial question can retrieve scientific context and vice versaNot started
Entity-resolution backlog still drainingThe graph is only as trustworthy as its made_id keys. Propose-only is the right call, but it means a human is the rate limitDraining
2 registered tools are idle or dark — clinicaltrials_gov, resendA credential that is paid for and never called is pure cost. Resend in particular is wired but ships dark pending a go-live checklistDecide
No per-skill invocation telemetryThe Skills Library shows inventory, not usage. We cannot yet tell which of the 70 skills are actually earning their placeNot started
Where the authored backlog lives. This table is the machine-checkable half — what the registries can prove is missing. The judgement half — sequencing, ownership, what is blocked and on whom — is the Work Board, which is now the single register for every tracked item in the engagement.
The register
Work Board
Every tracked item, bucketed by program and workstream, with the verified state and date on each row. Generated from the Hub master.
Open the board →
The narrative
Outbound engine spine
Sections 26 and 27: the long-form reasoning behind the sequencing. Narrative context, not the tracker.
Read the spine →