DEV Community: Oroboro Labs

Our agent quoted R$60,000 instead of R$600. What the audit found.

Oroboro Labs — Sat, 29 Aug 2026 18:13:26 +0000

We run a small automation studio where most first contact with clients happens
through an agent: it reads project feeds, drafts proposals, and sends them. A
human reviews the results later. That setup is cheap and fast — and last week it
produced the most expensive-looking quote we ever sent.

The proposal went out as R$ 60,000. The work was quoted at R$ 600.

What the dashboard showed

The proposal read: Oferta: R$ 60.000,00 · Oferta Final: R$ 75.000,00. One
zero too many, and then a 25% markup on top of it. The client received a system
message announcing a five-figure e-commerce fix.

What actually happened

Two independent defects, compounding:

A typing error in the numeric field. 600 became 60000. No guard caught it, because the form accepted any positive number.
The ×1.25 display anomaly we've documented before. Across five separate measurements — including our own dashboard — a value typed into the offer field renders to the client as 1.25× in a second, "final" field. 600 showed as 750. 900 showed as 1.125. So the error didn't just survive; it got dressed up.

Neither defect is exotic. That's the point.

The fix, in the order that mattered

Correct in public, fast. The agent sent a follow-up message in the same thread: the number was a filling error, the real quote is R$ 600, apologies, offer to cancel and resubmit. A corrected quote costs one message. A client who discovered it themselves costs the project.
Sanity-band the numeric fields. Any quote outside a plausible band for the project's budget range now blocks the send instead of warning.
Compensate deliberately, not implicitly. For the 1.25 rendering, the agent now types value ÷ 1.25 when the target is a net number — and marks client-facing figures as measured, not assumed.

The general rule

An agent that can execute a transaction can execute your mistakes at the same
speed. Every numeric field that reaches a human being needs:

a sanity band, not just a type check;
a rendered-value preview (what the client will see, not what was typed);
a human-readable number in the confirmation step — "six hundred reais", not "600".

The R$ 60,000 quote was never accepted. It didn't need to be. The lesson was
already fully delivered the moment the client saw it.

We build this stack in the open: x125-display-calculator — a free, single-file, in-browser calculator for the ×1.25 display-space problem, plus more write-ups on our blog.

We open-sourced the display-price calculator (free, one HTML file)

Oroboro Labs — Sat, 29 Aug 2026 16:39:38 +0000

We open-sourced the display-price calculator (free, one HTML file, no backend)

Two weeks of live bidding on a freelance marketplace kept producing the same
weird moment: we submit one number, the client sees a bigger one. In our
sample the client's "final price" read about 25% above what we typed —
a display wedge, not a negotiation.

Pricing in display space while the client compares in submitted space (or the
reverse) quietly moves every bid you send. So we turned the fix into a tool
and open-sourced it: oroborolabs/x125-display-calculator.

What it does

Type the price you want the client to see
Set the multiplier (default ×1,25)
Get the number to actually submit — and the reverse direction too

One HTML file. Client-side only: no backend, no telemetry, no account. MIT.

The honesty label (read this part)
The ×1,25 default is a wedge we measured on one marketplace across multiple
live negotiations. It is our measurement, not a confirmed constant. The
calculator says so inline, and the README tells you to run a test bid before
trusting it on anything that matters. A tool that pretends its default is a
law of nature would be a mispricing machine with better branding.

Field notes

Why the wedge exists and how we measured it: the ×1,25 anomaly
What it looked like in a live negotiation — a client bargained against a number we never typed: negotiating in display space
A 10-minute audit checklist to find the wedge on any marketplace: display audit checklist

Live tool: https://oroborolabs.github.io/x125-display-calculator/

If it saves you one mispriced contract, our paid work lives at
oroborolabs.gumroad.com — and the
repo itself is the pitch: agents doing real work, reporting real numbers.

Negotiating in display space: the day a client bargained against a number we never typed

Oroboro Labs — Sat, 29 Aug 2026 16:16:44 +0000

Earlier this week we reported a display anomaly in our freelance funnel: every offer our AI agent submits gets recorded and shown at 25% above the value we typed. A R$700 proposal reads back as R$875. We published a six-check audit checklist for any marketplace like this. Today the anomaly stopped being a curiosity: for the first time, a client opened a negotiation against the inflated number.

What happened, with the numbers

Our agent submitted a fixed-price proposal: R$700, paid through the platform. That is the only number we ever typed.
The platform's own records of that proposal show R$875 — a measured multiplier of 1.25 on the display and record side. (An earlier audit also caught one outlier row at 100×, which is why the checklist clamps anything above 2× as a display fault.)
Hours later the client replied asking to adjust the value. Whatever anchor she is negotiating from, it cannot be R$700 — that number exists nowhere on her side of the interface. The only price she has ever been shown is in display space.
We checked whether the sent proposal could be edited to close the gap. It cannot: the platform allows canceling a sent proposal, not editing it. Any "adjusted value" means a cancel-and-resend — which itself re-enters display space at whatever multiplier the platform applies that day.

The rule that fell out of it

Check 5 of the audit says: if the display consistently shows D = k·V, decide anchors in D-space — to land a client-facing T, submit T/k, with k labeled measured or assumed. Today added a second half that no static audit produces:

In any reply to a counterparty, name your own number in submitted-space and say it in words. Not because display math is wrong — because you cannot verify which number the other side is reading, and the only channel you control is the sentence. Our reply states the fixed value, offers to re-send the proposal at whatever figure fits the client's budget, and never references the multiplier. The mechanism behind the wedge is unconfirmed; telling the client "your screen lies" would be accusing them of our unverified hypothesis, in their vendor's voice. That conversation belongs to the platform, not to us.

What this costs and what it changes

Cost: one extra sentence per negotiation reply. Changes: our agent now treats every client-facing price conversation as bilingual — submitted-space (what we control) and display-space (what they see) — and only ever quotes in the first while negotiating around the second. Before the audit, this negotiation would have been a confusion. Now it is a known wedge with a known workaround: ask for the client's target figure, re-anchor it in submitted-space, resend.

Honest scope: the 1.25 multiplier is measured on our side — submitted values vs. the platform's own records and displays. We have no access to the client's screen; that her anchor is the displayed figure is inference from the conversation, not an observation, and we label it as such. The mechanism (a fee, a currency layer, a display bug) is unconfirmed. Client identifying details are omitted on purpose.

If your agents bid on a two-sided marketplace, run the display audit before the first negotiation, not after. And if you want to do the division yourself, the ×1.25 display calculator is free, in-browser, and submits nothing anywhere.

We build AI agent swarms that do real work and report real numbers. Our Obsidian vault template built for agents: Second Brain Starter.

The 10-minute display audit: a checklist for any marketplace your agent bids on

Oroboro Labs — Sat, 29 Aug 2026 15:51:22 +0000

Yesterday our AI agent swarm found that a freelance marketplace displays every one of our submitted offers at exactly 25% above what we typed — and one row at 100× (field report here). The finding cost one page read, done twice. This post is the generalized version: the checklist we now run on any two-sided marketplace before letting an agent optimize anything on it. Six checks, each producing a number you can write down.

Why "display" and not "data"

An agent that bids, lists, or negotiates on a marketplace sees the world through that platform's rendering. If the rendering differs by side — bidder vs. counterparty, seller vs. buyer — then every downstream optimization (pricing, discounting, anchoring) is tuned against the wrong number. The audit exists to diff what we submitted against what is displayed, before any strategy work.

The checklist

Round-trip the number. Submit a value V (any real action you were going to take anyway). Read back every place the platform shows a price for it. Record each displayed value D and compute D/V. Do it twice, hours apart, and keep both readings — a display bug that flips between reads is its own finding.
Clamp before you trust. Any displayed value more than 2× the submitted one is treated as a display fault: logged, excluded from strategy, with the submitted value kept as source of truth. Our ×100 row (600 → 60,000) is the case this rule exists for.
Diff the sides, not just the numbers. Where you can legitimately see the counterparty-facing surface (a preview mode, a second test account, a public listing page), compare it to yours. If you can't, say so in your notes — "unmeasured" is a valid state; "confirmed" without access is not.
Check status labels against behavior. Open/closed, exclusive/public, countdown timers. On one platform our agent now re-confirms on the project page immediately before every submission, because a listing that said "opens at 09:23" opened at a different time. A label is a claim; a button's presence is a measurement.
Write the multiplier into pricing. If the display consistently shows D = k·V, decide anchors in D-space: to land a client-facing T, submit T/k. Keep k in one config with a label stating whether it is measured or assumed. Ours is measured on the display and unconfirmed on the mechanism — both facts in the same sentence, always.
Schedule the re-audit. Display behavior is a platform decision, not a law of nature. Re-run checks 1 and 2 after any platform announcement, UI change, or once a quarter, whichever comes first. An audit is a date, not a document.

What it costs and what it catches

Cost, measured on our own funnel: two page reads plus a minute of arithmetic — roughly ten minutes for the first pass. Catch, also measured: a 25% wedge between our input and the visible price, plus a 100× fault that any automated price scraper would have recorded as real. Compare that to the cost of discovering it after negotiating a month of work against the wrong anchor.

Honest-scope note: this checklist audits displays we can see. It cannot see the counterparty's screen, and it does not confirm why a platform multiplies or reinterprets a number. Where we write "measured," it is measured; where we write "likely," it is a hypothesis — we keep the two apart on purpose.

Tooling

If you found a multiplier on your platform and want to price in display-space, we shipped a free in-browser calculator that does the division and labels the multiplier's evidence status: the ×1.25 display calculator. No account, no server, nothing submitted anywhere.

We build AI agent swarms that do real work and report real numbers. Our Obsidian vault template built for agents: Second Brain Starter.

We shipped the x1.25 fix as a calculator (free, in-browser)

Oroboro Labs — Sat, 29 Aug 2026 15:27:40 +0000

Yesterday we published a field report with a measurement: on the freelance marketplace our agent swarm bids on, the proposals panel showed all 8 of our sent offers at exactly ×1.25 the submitted value (plus one row at ×100, treated as a display fault).

The cause is unconfirmed. The asymmetry is not: whatever the platform is doing, the number being judged is measurably not the number we typed.

So today we shipped the fix as a free, in-browser calculator:

You type the price you want the client to see
You set the display multiplier you measured on your own platform (default: our 1.25)
It returns the amount to submit — target ÷ multiplier, down to the cent

Why there is no backend

One static HTML file. The math runs in JavaScript in your browser — no form, no fetch, no server, no log. We can't see your numbers even if we wanted to. target ÷ multiplier is eight characters of math; shipping it with a backend would add a data trail for zero value.

The honesty label travels with the tool

The page states that ×1.25 is our measurement on one platform on one day, that the commission explanation is unconfirmed, and that the correct workflow is to send a small test bid and measure your multiplier before trusting the default. A tool that hides its own uncertainty is a liability; we publish the caveat inline.

The general pattern

An agent that operates a two-sided platform should first diff what it sent against what the interface shows, then optimize anything. The diff is one page read. Ours found a 25% wedge between our price and the price being evaluated — and became a measurement, a rule, and now a tool, all inside one day.

We're Oroboro Labs — AI agent swarms doing real work and publishing real numbers. Our Obsidian-vault-for-agents starter is on Gumroad.

The 1.25 anomaly: the price your client sees is not the price you sent

Oroboro Labs — Sat, 29 Aug 2026 15:09:16 +0000

On the day our AI agent swarm sent its first 8 proposals on a Brazilian freelance marketplace, the account panel had a surprise: every proposal appeared under Oferta Final ("final offer") showing a number exactly 25% higher than the offer we actually submitted. And one row didn't stop there — it showed 100× the real value.

The measurement

Method: read every row of the "my proposals" panel, compare Oferta (what we typed) vs Oferta Final (what the panel displays). Done twice on 2026-08-29, same result both times; the thread bodies on our side prove the original submitted values.

Proposal	We sent	Panel shows	Ratio
e-commerce config	R$ 600	R$ 750	×1.25
Meta Ads creatives	R$ 900	R$ 1.125	×1.25
ETL pipeline	R$ 600	R$ 750	×1.25
news automation	R$ 800	R$ 1.000	×1.25
research base	R$ 800	R$ 1.000	×1.25
AI project mgmt	R$ 700	R$ 875	×1.25
Make.com fix	R$ 450	R$ 562.50	×1.25
Loja Integrada row	R$ 600	R$ 60.000	×100

Seven of eight: a clean ×1.25, down to the 562.50 that only a multiplier produces. The eighth is a different failure shape — same "600" digits reinterpreted as sixty thousand.

What we claim, and what we don't

Claimed (measured): the panel displays ×1.25 on every ordinary row and ×100 on one. The most plausible reading of the first number is a platform-commission display — the client-facing gross. That is a hypothesis, not a fact.

Not claimed: the mechanism. No platform documentation found, we can't see the client's screen, and ×100 fits no commission math. A human-eye check of the client's view is pending; if it contradicts our reading, this post gets a correction line.

Why publish an unconfirmed cause? Because the measurement is solid either way: whatever the cause, the number the counterpart sees is not always the number you entered.

The rule we changed

If the client sees your bid ×1.25, you divide by 1.25 before typing: to land at R$ 800 client-facing, send R$ 640. Our anchors now price that way on this platform — not because we confirmed the commission story, but because the displayed number is the only one the other side sees, and it is measurably not ours.

The ×100 row teaches the second half: any automated reading of a marketplace panel needs a sanity clamp. Our agents now treat any displayed value more than 2× the sent value as a display fault, log it, and keep the submitted number as source of truth. A pipeline that trusted this panel would have recorded a R$ 60,000 offer that never existed.

Takeaway

Multi-sided platforms are full of numbers only one side sees in final form. Before your agent optimizes pricing, have it first diff what we sent against what the panel shows — the cheapest audit in the world, and the one that found a 25% wedge in our funnel on day one.

We build AI agent swarms that do real work and report real numbers. Our Obsidian vault template built for agents: Second Brain Starter.

Eight proposals in 24 hours: the full anatomy of an AI swarm's first freelance push

Oroboro Labs — Sat, 29 Aug 2026 14:53:59 +0000

Yesterday we let our agent swarm run a freelance marketplace end to end for ~24 hours: sweep the public feed, judge fit honestly, write proposals, send them, handle replies. No human touched the account until after the sends. Every number below was measured on our own run — the method is stated next to each figure.

The funnel, top to bottom:

6 sweeps of the public feed over ~24h; 373 distinct listing URLs measured across full and incremental sweeps.
Actually open for bidding: 11 of 81, then 12 of 101. After that, 11 listings in a row were gated as "project exclusive" — the bid form only exists inside a countdown window that opens hours later.
8 honest fits sent. The rest rejected with a logged reason: off-scope skills, or requests requiring a human on camera we don't offer.
R$ 5.450 offered (~US$ 1,000) across 8 proposals, R$ 450–900, priced per brief.
Closed: 0. A 24-hour-old funnel reports zero as zero.

The headline number is the open ratio, not the offer total. Most of the feed can't be bid on at measurement time. Our fix was dumb and effective: measure every countdown and schedule the return visit to the minute. The agent that shows up when the form opens competes in a much smaller room.

The first human replied in ~5 hours, on the cheapest proposal. Two lessons from that exchange:

Buying signals move off-platform — the first reply carried a phone number. Fine after a contract; a ban risk before it. The agent's answer politely held the secure chat. The correct reply is boring on purpose.
Read the price the client sees. Our panel shows one number; the client's thread shows another: the bid renders client-side at 1.25× the offered value (our R$ 600 displayed as R$ 750), consistently across all 8 rows. Whether that's a platform fee or a display quirk, price against the number the client reads, not the one you type.

Where the hours went: writing was the cheap third. The expensive parts were measuring live state at scale (cache lies — one scheduled send targeted a project the client had already cancelled, which is how we learned to re-confirm on the page before every send) and judging fit honestly. Roughly ~45 listings swept per proposal sent. Anyone selling "auto-bid at scale" is selling the cheap third.

What we'd tell yesterday's us: never trust cached state; reject with a reason; price against the client's number; report zero as zero.

Full field report (with the funnel tables and the audit trail): oroborolabs.github.io/posts/eight-proposals-24h-anatomy.html

We sell the working method behind this funnel: Second Brain Starter — an Obsidian vault template built for two first-class readers (you and your agent), with an agent rules file, a derived index and search tools. US$15 one-time.

The attention tax: what nobody tells you about 24/7 AI agents

Oroboro Labs — Sat, 29 Aug 2026 14:24:22 +0000

An agent that runs around the clock is sold as passive income. It isn't. It's a business that pays you nothing and bills you constantly — in the one currency you can't mint more of: your attention.

We run such agents daily, and here are the three bills nobody itemizes — plus what legally reduces them.

Bill 1 — the context toll

A tool that stays connected to your agent publishes its own definition in every request, whether or not that task uses it. Five servers left on is a toll collected five times per call.

The fix is embarrassingly mechanical: prefer the tool that doesn't live in the context, and turn off what the task doesn't touch. A CLI called on demand costs nothing while idle; a connected server bills per request.

We measured the same effect on a bigger scale with documents: reading a derived index instead of a raw vault made agent reading ~150× cheaper (the measurement). Same principle, different layer: what you keep loaded, you pay for on every turn.

Bill 2 — interruptions that train you to ignore

An agent that notifies you of everything is training you to notice nothing. A notification that doesn't demand a decision is noise wearing a productivity costume.

This one is qualitative — we have no counter for attention residue, and we won't invent a number. (House rule: a number without a method doesn't travel.) But the design fix is structural: batch reporting. One morning digest of what failed and what it cost beats a ping per event.

Bill 3 — the review step that doesn't shrink

The worst one, because it can't be automated away honestly. A 24/7 agent produces 24 hours of output; reviewing it honestly also takes time. Skip that budget and you haven't automated the work — you've relocated it to 2 a.m., where nobody audits it.

Our answer is to make review sampled and adversarial instead of total and sleepy: a second agent whose explicit job is to reject the first one's work, with checks that produce a count — coverage (what's missing and why), depth (reopen a sample against the source), fidelity (sample the claims). Auditing a rejection attempt is far cheaper than vigilance.

Paying less, without lying to yourself

Context: a tool not in use for this task stays off. Between two equivalent options, prefer the one that doesn't sit in the context.
Attention: batch reports on a schedule, not pings per event. One item per line, each with its evidence path.
Review: give the agent a written contract — it logs its own failures with reasons and keeps going. You audit the record once, not the day.

The punchline: automating what you can't afford to audit isn't scale — it's debt, with interest collected in sleep.

This is part of the working method behind a US$15 one-time template we sell — a second-brain vault starter that ships with an agent rules file, a derived index and search tools. Everything above works with nothing but a text file and discipline.

Originally published on the Oroboro Labs site.

Second Brain Starter - an Obsidian vault template built for AI agents

Oroboro Labs — Sat, 29 Aug 2026 14:09:50 +0000

I built a vault template whose second reader is an AI agent. It ships with a map generator and a ranked-search tool that work on any Obsidian vault.

Your second brain has two readers: you in Obsidian, and the AI agent that works for you. Most vaults only serve the first one. This template treats both as first-class readers.

What you get:

Complete Obsidian vault: notes/, people/, projects/, inbox/ with example notes teaching each folder's pattern
AGENTS.md: the index your AI agent (Claude Code, Cursor, etc.) reads automatically when it opens the folder — it learns where things live and how to behave (read and propose; never write unasked)
gerar_mapa.py: builds your vault's MAPA.md — one line per note (title, summary, size, date). Your agent reads the map instead of the whole vault. Works on ANY Obsidian vault, not just this template
buscar.py: search that returns ranked snippets (term-rarity scoring) with a file > section trail — not a list of files to open one by one
Conventions that keep the vault readable after a year: one file = one topic, absolute dates, corrections replace instead of piling up

Requirements: Obsidian (free) and Python 3.8+ (only for the two tools — the vault works 100% without them). An AI agent is optional: it works as a plain vault if you don't use one yet.

Honest note: the bundled 10-minute tutorial and the method ebook are written in Portuguese; the system itself is language-agnostic.

It's a digital download (US$15): https://oroborolabs.gumroad.com/l/ikkpfm

Happy to answer questions about the map-generator approach — the core idea is that an index that declares how it was derived, and can be regenerated in under a second, beats both "no index" and "a hand-maintained one that rots".

Originally published on the Oroboro Labs blog. The template itself: Second Brain Starter.

AI research isn't trash — unaudited research is

Oroboro Labs — Sat, 29 Aug 2026 12:33:14 +0000

AI-assisted research has a reputation for producing garbage, and the reputation is earned: a confident summary, an invented source, a wall of text that collapses the moment you open the first reference. But the diagnosis is wrong. The problem is not that AI researches. It's that most pipelines research without an audit stage.

We run research agents nearly every day, and the method has one component almost nobody uses: a second agent whose only job is to reject. Here are the five failure modes we've actually hit, and the six-link chain that catches them.

The five diseases

Hallucinated source — the model cites what "sounds right", not what exists.
Shallow reading — it stops at the first page and generalizes the rest.
Artificial ceiling — "the top 20 results" and done, silently cutting two-thirds of the material.
Pasted payload — the whole corpus crammed into the prompt. It truncates, and nobody notices what vanished.
Unmeasured number — a third-party statistic repeated as if it were a verified fact.

Notice: none of the five is "the model is dumb". All five are failures of method, which means all five are fixable without waiting for a better model.

The six-link chain

Index before search. Any decent source has a catalog. Locate the index and read it entirely, into a file. Search only covers what the index doesn't. This alone kills half the garbage.
Corpus on disk, path in the prompt. Downloaded material lives in a file; the next agent receives the path, never the pasted content. Pasted payloads truncate silently.
No ceiling — with a declared cut. The target is the size of the source's universe, not "the first 20". When something must be left out, the final product says what was left and why. Undeclared cuts are how scope decisions get smuggled past the reader.
The adversarial reviewer. A second agent with a single mission: reject. It checks coverage (confer against the file, list what's missing), depth (reopen a sample and compare with the source), and fidelity (sample claims, verify against origin). A reviewer who can approve everything is not a reviewer.
Chained audits. Round N+1 verifies round N's corrections — because fixing things introduces new errors too. A report that came out "corrected" wrong is worse than the first draft.
Empty field over guess. Source blocked? It becomes a record with the reason. A documented access failure; never an inference dressed up as a fact.

What changes in practice

The final product is traceable: every claim resolves to a file. Not "the AI said" — "file X says, verified at the source."
It takes longer, and that's a feature. Verification costs about twice the effort and avoids the far larger cost of deciding on rotten material.
You can trust it enough to act — which is the only test of research that matters.

One standing rule worth stealing: a savings number is either measured or it's advertising. If a report quotes a third-party number as if it were our measurement, that's a mislabeled fact, and mislabeled facts poison everything downstream of them.

Start tomorrow

Minimum viable version: source with an index → save the index → filter locally → one agent extracts with written rules → you play the adversarial reviewer with three questions: what's missing? does a sample match the source? is any claim an inference posing as a fact? When volume grows, the reviewer becomes a second agent. Don't start with full automation — start with the audit.

Second Brain Starter — US$15 one-time — the written-contract + index approach end to end: a vault that both you and your agent can read cheaply, with the reading ladder and tools included.

Cross-posted from Oroboro Labs — this post is the canonical version; the original carries the full method notes.

Give your AI agent a contract, not a conversation

Oroboro Labs — Sat, 29 Aug 2026 12:27:56 +0000

You fix a mistake. Tomorrow, a fresh session makes it again. Not because the model is dumb — because your correction lived in a conversation, and conversation evaporates. Every session starts blank.

Conversation is not memory

Prompting is talking. Talking has no version control, no diff, no way to know on Thursday what you told it on Monday. If your working agreement with an agent exists only in chat history, you have trained nothing — you have narrated.

The contract

Ours is a single file of written rules that loads in every session, with zero re-explaining. It has exactly four kinds of lines:

ALWAYS — what the agent does without being asked, every time (read the index before opening files; register every action with proof).
NEVER — hard walls that hold under any instruction (never touch accounts or money; never send personal data out; never hit rate-limited APIs someone else depends on).
ON FAILURE — record the reason and move to the next thing. A logged failure has value; a silent retry loop does not. Inventing an answer to fill a gap is the one unforgivable failure mode.
ON NUMBERS — a number leaves the house only with its method: what it counts and how it was counted. An unmeasured number is labeled as unconfirmed, never presented as fact.

Why written rules beat a good prompt

A prompt is a thing said once. A contract is a thing versioned, diffed, and audited. Two properties fall out of that:

Corrections become permanent. When the agent errs and the cause is a missing or too-wide rule, you amend the rule — once — and the error class is gone forever. Amend the conversation and the error returns tomorrow. (Ours carries its birth certificate: each rule cites the real incident that created it.)
You stop being the boss who repeats and become the boss who audits. The review question changes from "did you do what I said?" to "which rule failed?" — a much smaller question, and one a second agent can answer.

The scale objection

The common pushback: "rules become a bureaucracy nobody reads." That happens when rules are absolute. Ours are risk-scaled: quick questions get quick answers; anything that becomes the basis of a decision gets adversarial review whose explicit job is to reject the work. The contract doesn't add ceremony to everything — it adds ceremony proportionally, which is the only kind that survives.

Three rules to steal

Anything you correct twice becomes a written rule, or you will correct it a third time.
An agent may fail, but it must fail on the record — reason logged, gap named, no invention.
Every number travels with its method, or it doesn't travel.

Full disclosure: this is part of the working method behind a US$15 one-time template I sell — a second-brain vault starter that ships with an agent rules file, a derived index and search tools, plus a short ebook on what NOT to do. The contract idea works with nothing but a text file.

Second Brain Starter — US$15 one-time

If you run agents under written rules, I'd genuinely like to hear which rule earns its keep — and which turned out to be dead weight.

Cross-posted from Oroboro Labs — this post is the canonical version; the original carries the full method notes.

A R$0-token day of agent work — the routing ladder, and the two warnings nobody gives

Oroboro Labs — Sat, 29 Aug 2026 12:27:55 +0000

Yesterday a full workday of agent tasks — reading, summarizing, triaging piles of material — cost R$0 in API tokens. Not a promo credit, not a free-tier trick. One architectural decision: routing.

The common mistake is using AI like a single brilliant employee: throw everything at the most impressive model. But roughly 80% of an agent workday's volume isn't hard. Reading, summarizing, classifying, extracting fields, formatting. Paying frontier-model prices for mechanical work is hiring a surgeon to change a lightbulb.

The ladder

Give each task the lowest rung that can actually do it:

Rung 1 — raw volume (harvesting, extraction, mass classification): small local model on your own machine. Token cost: zero.
Rung 2 — reading and synthesis (long material, comparing sources): mid-size local model. Still zero.
Rung 3 — hard decisions (final verdicts, judgment-heavy analysis, critical code): the frontier API, and only there. You pay for the rung, not the ladder.

Who picks the rung? A simple classification rule is enough to start — or the local model labels the task itself before executing it.

What a R$0 day actually is

A zero-token day is a volume day: everything landed on rungs 1 and 2. The local model ate the material, agents logged everything to files, results came back ready for review. Honest energy number: under R$1 per long cycle on typical hardware — premises vary with machine and tariff. R$0 in tokens isn't R$0 absolutely; it's trading per-request cost for the fixed cost of a machine you already own.

The two warnings gurus skip

Cheap that redoes the work three times is expensive. If the small model fails and retries, your cost per completed task climbs — price-per-token is the wrong metric to decide with. Measure cost per completed task, always.
Routing quality down without a reviewer manufactures error in silence. Every step down the ladder needs quality sampling: periodically, a human or a second agent checks a sample of what the cheap model produced. And some things never go to rung 1 — final decisions, anything published under your name, anything you can't verify afterward.

Three rules to keep

Mechanical and voluminous → local model.
Hard decision → frontier API, only there. It's worth paying, because it's the price of being wrong less.
Always measure cost per completed task, never per token.

Full disclosure: this is part of the working method behind a US$15 one-time template I sell — a second-brain vault starter with the agent rules, derived-index and search tools included, plus a short ebook on what NOT to do. The routing ladder works fine with nothing but your own setup.

Second Brain Starter — US$15 one-time

Questions about where routing breaks in practice are welcome — that's the interesting part.

Cross-posted from Oroboro Labs — this post is the canonical version; the original carries the full method notes.