How an agent gets built here — deliberately, in a fixed order, with a stop condition written down before anything runs. This is the layer that decides whether the fleet compounds or becomes forty-nine unrelated scripts that one person understands.
Skipping a step doesn't save time; it moves the cost later. Most bad agents are the result of answering question 4 before question 2 — picking a framework before knowing what "done" means.
monocle_* and the brain — never build a parallel graph.os_agents with harness, archetype, trigger, owner, host and kill-switch — or it will be discovered by a manual sweep instead.These get used interchangeably and they are not interchangeable. Getting the words right is not pedantry: it's how two people agree on what they're building before they build different things.
The same work attempted repeatedly until a verifier passes. Maker plus checker, with a cap. Depth over one problem.
In the fleetFORGE — the overnight code reviewer. Iterates on one slice per run.
Cost profileUnbounded if uncapped. Always cap.
Different work done in parallel, then joined. Width over many problems.
In the fleetDAYBREAK, when built — five specialists produce independently, one composer joins.
Why it's tempting and riskyParallelism multiplies cost immediately and linearly. Five agents is five times the spend, whether or not the output is five times better.
Cost profilePredictable, but multiplied. Budget before fanning out.
Neither depth nor width — the thing that runs the agent and enforces its guarantees. Scheduling, retries, secrets, logging, the cap.
Why it's step 3, not step 1The harness is a consequence of the shape. Choosing a framework first is how you end up bending the problem to fit the tool.
In use hereEight. Listed below.
Pick from this list. A ninth harness needs a reason that none of these eight can serve, because every new one is a new deployment story, a new secrets story and a new debugging story for whoever is on call.
| Harness | Best for | Don't use when | Live examples |
|---|---|---|---|
| edge-functions | On-demand, request/response, sub-minute. A user clicks and waits. | Long-running work, or anything needing more than a few minutes. | SCOUT, BIBLIOGRAPHER |
| fastapi-litellm | An always-on service with its own state, health check and cost caps. Called by other systems. | Something that runs once a day — a cron is simpler and cheaper. | SSO AGENT, parley, ORPHAN-SEEDER |
| cron-worker | Scheduled, deterministic, mostly-SQL work. The plainest thing that works. | Anything needing to respond to an event within minutes. | MADE-ID CUSTODIAN, MEDIC |
| claude-agent-sdk | Multi-step reasoning with tool use where the path isn't known in advance. | The steps are known — then it's a chain, and a chain is cheaper and auditable. | CHIEF, RESOLVER |
| n8n | Visual workflows a non-engineer can read and modify. Integration glue. | Anything needing version control and code review as a first-class concern. | MADE BRAIN, KFSH TRAINER · currently a failing key target — see R-05 |
| claude-code-loop | Verify loops over a real repo — make, test, retry, escalate at the cap. | There is no automated verifier. Without one this is the quiet-failure pattern. | FORGE · unscheduled — see R-01 |
| signal-desk | Recurring multi-source monitoring: adapters → prefilter → bounded LLM triage → curator → gated feed. | A single source with a clean API — that's a cron-worker. | REGEN-RADAR · planned: sentinel, trialwatch |
| cascade-workflow | Human-in-the-loop authoring: docs, decks, images, diagrams, this site. | It must happen unattended. A human-triggered workflow is not an agent. | Most design + delivery skills |
These are not per-agent decisions. They are the defaults, and departing from any of them requires a stated reason recorded against the agent.
Anything touching canonical data writes a proposal; a human confirms. RESOLVER, MADE-ID CUSTODIAN, the Atlas status mapper and CHIEF's dispatch are all propose-only.
Accepted cost2,335 unreviewed proposals. That backlog is the price of the guarantee, not evidence against it. The fix is a faster review surface — never auto-confirm.
TestCan a wrong output be undone by ignoring it? If not, it must be a proposal.
Generation and judgment are separated. A Sonnet-class model produces; a cheaper Haiku-class model, which did not see the generation prompt, grades it and can reject.
LiveSSO AGENT returns a hard failure on validator rejection — a refusal to send is a success of the design. parley, margin and redline use the same shape.
TestWould you publish this output unread? If not, it needs a validator.
Every agent doing model work has a spend or iteration ceiling: SSO AGENT daily + monthly, FORGE $15/month, SCOUT a per-run budget guard. At the cap it stops and escalates — it never degrades silently.
Known limitCaps are enforced locally, not centrally — the Agent Cost Ledger is still planned. Fine for 12 agents; not fine once the specialist ring adds five scheduled ones.
TestWhat is the worst-case bill for one bad night? If unanswerable, the cap isn't real.
No agent writes Salesforce, pipeline, price or revenue. Ever. The OS reads them and writes proposals, briefs, messages and notes alongside them.
Why absoluteA hard business rule enforced by a probabilistic system is not a hard rule. The only reliable enforcement is an architectural boundary — so the boundary is architectural, not a prompt instruction.
TestNot applicable. There is no exception process.
live meaningSix stages. The only interesting transition is the last one, because that is the one this fleet has historically got wrong.
DAYBREAK's specialists cannot reach live by running successfully once. Ten clean days first. That rule exists because the alternative already happened: FORGE is marked live and has not run since 2026-06-11, and nothing on the box would ever have told us.
Promotion also requires a passing evaluation run — never an agent promoting itself. In the reporting-ux lifecycle surface, promotion into evaluated is gated on the latest eval status being passed, and the promote action is a reviewer's click.
The change this site argues for: make live require a found trigger, not a typed status. /opt/made-fleet/os_fleet_report.py already walks containers and crontabs every thirty minutes and already knows the answer — it just has nowhere authoritative to write it. Give it a runtime_state column and the disagreement between intent and reality becomes the alert, automatically. Then this site's red section is generated instead of hand-swept, which is the only version that stays true.
Not hypothetical. Each of these is visible somewhere in the current fleet or was avoided by a deliberate decision.
| Anti-pattern | What it looks like | Where it shows up here |
|---|---|---|
| A directory is not an agent | Something exists at /opt/thing, so it's assumed to run. Nothing schedules it. | FORGE — R-01. Eight weeks dark while reading as live. |
| Two things, one name | A name gets reused, an auto-binder picks the wrong one, and production work is filed under a concept. | RALPH / RESOLVER — R-02. PULSE / MEDIC — R-03. |
| An alarm that never changes | drift_count: 22 on every run forever, so nobody reads it. | made-fleet — R-04. Needs a not-an-agent class so zero is reachable. |
| Half a loop | The capture side is built and the promotion side isn't, while the docs describe a closed loop. | 1,778 decisions, 0 learned rules — R-06 on the Context page. |
| Building on an unhealthy harness | Committing a large roadmap to a component that is currently failing its own probe. | 14 planned agents on n8n, which is MEDIC's failing key target — R-05. Avoidable if sequenced. |
None of the red findings on this site is a hard technical problem. Nobody chose the wrong model, wrote a bad classifier, or picked an unworkable architecture. The skill library is genuinely well-engineered — three p0 identity skills with 31 unit tests, negative priors and documented bugs.
What is missing is the discipline that live is a claim requiring evidence. That is a one-column change plus a rename, and it converts this entire method page from aspiration into enforcement.
Which is the actual argument of this whole site: a fleet doesn't fail because its agents are bad. It fails because nobody can tell which ones are running.