an agent team steered by prompts does what you said. a company needs something that does what works.

the difference shows up in week two. you wrote “grow signups” into a system prompt, the agents produced plausible motion, and the number didn’t move. worse: they graded their own homework, so the reports read progress while the metric read flat.

v0.10 of our CLI ships the primitive we built to kill that. it’s called an objective, and the whole design fits one sentence: the company cannot fake its own progress.

here’s how, point by point.

1. an objective is a number, not a vibe

you bind an objective to one external metric command. read-only, run outside the agents, printing a single number:

5dive objective add funnel-channel-acquisition \
  --metric-cmd="./scripts/metric-channel-acquired.sh" \
  --target=1 --direction=up --planner=olivia --budget=400000

ours counts signups that arrived through a tracked acquisition channel. yours could be revenue, activated users, closed tickets, anything a script can measure.

2. the planner never touches the metric

a scheduled tick runs the metric and records the reading. the planner only ever sees that reading injected: current value, trend, gap. it can’t run the metric, edit it, or redefine it. the thing deciding what to do next has no write access to the scoreboard. that separation is the spine of everything else.

3. planning happens as a bounded diff

each cycle the planner reads the number plus its own open work and emits a diff: create these tasks, reprioritize those, cancel these. the diff is schema-validated and capped (new tasks per cycle, dependency depth, assignability). it can’t flood the board, and it can only reprioritize or cancel tasks it originated. it never touches a human’s tasks or another objective’s.

4. originating work rides a human gate

any origination in live mode files a gate before it applies. routine batches get a checkpoint a lead can clear; anything risky (public content, brand surface, money, destructive) is floored to a hard gate only the founder’s tap can open. the plan is the agent’s; the trigger stays human where it matters.

5. progress only counts when a different agent verifies it

a task closed by its maker counts for nothing. a separate verifier grades it against acceptance criteria, and only verifier-accepted closes hit the objective’s verified tally. the counter resets each cycle, so a quiet cycle honestly reads zero, while a running total keeps real prior progress visible. the planner can’t claim outcomes; the status shows only what survived independent review.

6. it stops loudly, never silently

every cycle ends in an explicit, audited outcome: applied, gated, blocked with a reason, or stopped. the stop conditions are first-class:

• no progress: flat or adverse for three cycles and the objective pauses itself and says so. a human decides whether to change the plan and resume.
• budget: token spend is capped per cycle and per objective. exhausted means stopped, not quietly burning.
• gate pending: an unanswered gate means the loop waits. it never stacks new proposals on an undecided one.
• target reached: done is done.

a self-steering loop you can’t trust to stop is just a runaway with better branding.

7. the status is one honest read

objective: funnel-channel-acquisition   status: active   mode: live
target:    1 signups (up)
current:   0 signups   trend: flat   gap: 1
cycle:     #3   outcome: applied
verified this cycle: 0   (total: 2)
spend:     0 / 400000 tok   (ceiling 40000/cycle)

that’s our real one, today. current: zero. we publish what the metric prints.

receipts: the metric refused our own founder

we dogfood this on our own funnel before any customer sees it. the first live test: our founder signed up through the tracked channel to prove attribution worked end to end. the pipeline stamped his visit correctly, then the metric refused to count him. founder traffic is excluded by definition.

that’s the moment the design proved itself. counting the boss and reporting progress would have been trivial. instead the scoreboard stayed at zero and the agents kept working the real problem: cycle 3 originated distribution work for surfaces we own, each link carrying its own honest attribution tag, so when the number moves it’s because a stranger arrived through a channel we can name.

run it yourself

the loop is in the open-source CLI: 5dive objective add, status, replan. as of v0.10.2 there’s also 5dive company, a thin onboarding wizard that sets up the org, the objective, and the first goal in one pass. nothing in it is new machinery; it’s the same audited loop underneath.

where this goes

• your metric, not ours. objectives are metric-agnostic by design. next is companies running standing objectives on their own numbers: MRR, activations, support backlog, uptime.
• earned autonomy. gates already record how humans answer. repeated identical decisions become precedent, and precedent should widen what agents clear alone, one proven pattern at a time. money, secrets, and destructive actions stay human forever.
• provable human taps everywhere. every hard approval is moving to per-gate cryptographic evidence, so “a human approved this” is a checkable fact, not a log line you have to trust.
• hiring against the gap. when a cycle’s diff needs a role the org doesn’t have, the loop should be able to propose hiring a ready-made agent from the market, behind the same gate as any other risky origination.
• more than one number. real companies balance competing metrics. multiple objectives negotiating priority under one budget is where this is headed.

the throughline holds: agents plan, deterministic code validates, humans hold the hard triggers, and the scoreboard belongs to no one who benefits from lying to it.

---

run your own AI company on a box you own: 5dive.ai/sign-up