Four things, in a fixed order. Context grounds everything. Skills are the execution units — one skill, one job, written down. Agents wrap a skill in a trigger, a schedule, an owner and a kill-switch. Tools are what they all run on. A fifth layer, method, is how any of it gets built without becoming a pile of one-offs.
This site is the honest version. It counts what is actually running on bc-made — not what the roadmap says — and it separates two kinds of gap that are usually filed together and should never be.
os_* registry. 4 red findings — see below.
Both get called "a gap," and that is how the first kind hides inside the second. So on every page in this site they are drawn differently and they are never mixed in the same list:
| State | Means | Urgency |
|---|---|---|
| Broken | We believe this works. It does not. The registry says live, a doc quotes it as fact, or a dashboard shows it green — and the sweep says otherwise. |
Now. Someone is relying on it. |
| Future | Known, named, scoped, not built. 32 agents sit here on purpose. | Roadmap. Not a problem. |
A dead agent flying a live flag is worse than an agent nobody has started, because the second one is honest. Everything red on this site is red for that reason.
Every number below was re-queried on 2026-08-04 against the Transfer registry (jrfcfayphcmaxsixxupu) and a live SSH sweep of bc-made. Where the registry and the machine disagree, the machine wins and the disagreement is recorded as a red finding.
The order matters and it is not decorative. A skill written without context produces confident nonsense. An agent built without a skill is a prompt with a cron job attached. And a fleet built without a method becomes 49 unrelated scripts that only one person understands — which is the failure mode this layer exists to prevent.
Every agent, its harness, archetype, trigger and host — grouped by whether it is verifiably running, believed-running-but-isn't, or deliberately not built yet.
62 active skills — the execution units. One job each, written down, versioned, and reusable by any agent or any human in a chat window.
The stack the fleet runs on, by layer — frontend, backend, AI, infrastructure, observability, external. What each is for and whether it's healthy.
The grounding layer — the databases, the company brain, the wiki, the brand pack. Authored in git, retrieved from Postgres, and the reason answers are specific.
How an agent gets made: pick a shape, pick a harness, write the skill, set the trigger, define the stop condition, register it. The part that makes the fleet compound instead of sprawl.
Three agents documented end to end at full depth — every stage, every dependency, every guardrail, every honest limit. SCOUT and SSO AGENT are live; BEACON is a pre-build map.
These are the only red items on this site. Each one is a case where a system of record says a thing is live and the machine says it is not — which means somebody, at some point, will make a decision on a false premise. Full detail and evidence on the Agent Fleet page.
/opt/made-forge exists with a review plan, prompts and a cloned repo. Its last written output is dated 2026-06-11. There is no cron entry under any user, no systemd timer, no container, and no log directory. Nothing on the box will ever start it.
Why it mattersFORGE is the overnight hostile code-reviewer for the reporting-ux app — the thing that is supposed to be catching regressions tab-by-tab while nobody is watching. Believing it runs means believing the app is under continuous review. It is not, and has not been since June.
paused. Both are honest. Leaving it live is the only wrong answer.Decision neededSchedule it, or demote it. Not a build task — a five-minute integrity task.
/opt/made-ralph/nightly.sh to the agent slug RALPH. But RALPH in the registry is a legal-language concept that was never built — its own description says so. The real nightly entity-resolution agent is RESOLVER, which also claims /opt/made-ralph as its repo path.
Why it mattersAn automated binder running every 30 minutes is confidently attributing real production work to an agent that does not exist, while the agent doing the work looks unbound. Any health rollup built on those bindings is wrong, and it is wrong in a direction that makes things look fine.
/opt/made-ralph20 9 * * * running nightly.sh, and claude-user cron 0 7 * * * running run.sh. The wiki documents only the 07:00 one. Nobody wrote down the 09:00 one.Decision neededRename the concept agent, or give the binder an explicit slug. Then reconcile the two schedules — or confirm both are intended.
/opt/made-pulse/pulse_monitor.py at */15, :17 hourly and 06:40. The fleet reporter binds all three to PULSE. The wiki says those crons are MEDIC and that PULSE is a separate n8n build still being refined. Both are live in the registry.
Why it mattersOne of these two agents is a phantom, and the live count is inflated by one. Worse, if PULSE-the-n8n-workflow was ever genuinely intended as a distinct thing, nobody can now tell whether it exists, because its name is already answering to somebody else's cron.
Decision neededPick which one owns /opt/made-pulse. Retire or rename the other.
/opt/made-fleet — os_fleet_report.py every 30 minutes and os_provision_worker.py every 10. Neither appears in os_agents. The reporter's own output flags them as catalogued: false: it is reporting itself as drift.
Why it mattersEvery run reports drift_count: 22 and has done so continuously. Most of those 22 are client microsites that are legitimately not agents — so the number never moves, and a signal that never moves gets ignored. That is how ORPHAN-SEEDER ran unregistered for months before July. Same failure, still open.
Decision neededRegister the two fleet crons, then add an explicit not-an-agent classification so drift can actually reach zero and mean something.
probed=13 ok=11 down=2 key_failing=['svc_n8n_made']. The n8n service on bc-made is a failing key target — and n8n is the harness candidate for roughly fourteen of the planned agents. Worth knowing before that roadmap gets committed to.
This is the healthy list. Every one of these is named, assigned an archetype, given a candidate harness and a priority, and left alone until it is worth building. Nothing here is a problem — it is a queue, and the point of writing it down is so that "we should build a thing that does X" is answerable with "yes, it's called MOSAIC, it's p2, here's the harness."
The specialist ring under DAYBREAK — daybreak, DOSSIER, PERISCOPE, trialwatch, sentinel — plus huntsman (BD), margin and redline (commercial QC), and BIBLIOGRAPHER in testing.
GateDAYBREAK requires 10 consecutive clean business days from a specialist before it promotes. That gate is the method working as designed.
Named and shaped, not scheduled. Includes BEACON — which already has a full pre-build map precisely because doing the discovery before the build is cheaper than after.
Why write them down at allAn unnamed idea gets rebuilt three times. A named draft gets built once.
Agent Cost Ledger — per-run cost tracking, currently absent, which is why cost caps are enforced per-agent rather than centrally. Langchain — under evaluation for RAG, not adopted.
NoteThe cost ledger is the one future item with a live consequence: without it, spend is visible per agent but not in aggregate.
Everything here is read-only and BC-owned. The site reads the Transfer os_* registry and the bc-made machine. It writes nothing, triggers nothing, and never touches Joe's made-ai-os authoring loop — that stays canonical.
The working cockpit is still the reporting-ux app (/made-os, /agents-os, /skills-library, /heartbeat). This site is the narrative layer over the same truth: shareable by URL, readable without a login, and blunt enough to be useful in a planning conversation.
RED line, unchanged: nothing in the OS writes Salesforce, pipeline, price or revenue.