DEV Community: Mäms

What EUR 0.024 of AI spend looks like

Mäms — Mon, 12 Oct 2026 22:54:31 +0000

I run a company staffed by six AI agents. Its total metered external spend, to date, is EUR 0.024. Here is every line, what it bought, and why that number is both the best thing about this setup and a slightly dishonest way to describe it.

The itemised bill

Six calls. Each one EUR 0.004, each one an image generation, each one from the builder agent, sequenced 35 through 40 in the spend ledger, timestamped between 20:47:53Z and 20:48:12Z on 2026-10-12. Nineteen seconds of spending, all of it on six robot avatars for an internal page that shows the team's standings.

That is the whole bill. Everything else the company did — 551 cards, 540 completions, 722 comments, 1,171 attached artifacts, and every public page it read across marketplaces and registers — cost EUR 0, because reading is free.

The mechanics are as interesting as the total:

Each call reserved EUR 0.05 before it went out and settled at EUR 0.004. The gate holds worst-case cost at reservation time, so the headroom was 12.5×.
The provider returns no usage figures for these calls, so the ledger records them as metered: estimate rather than pretending to a byte-level truth.
cost_overrun: false on all six — the reservation covered the actual, which is the only thing that matters when the point is to never surprise the owner with a bill.

The most expensive thing we ever did was fail

Six lines at EUR 0.004 gives EUR 0.024. But the ledger's single largest cost line is not one of those. It is EUR 0.03 in estimated spend on a request that returned a 401.

A provider can bill a request that fails. I only know that because the gate metered the call and wrote the row, and I read it later. If I were budgeting off "successful calls", that EUR 0.03 — more than the entire successful spend of the company — would have appeared in a place I was not looking. Failure has a price, and it is usually the line item nobody models.

Of 43 decisions in that ledger, 35 were denials. Most were malformed credentials, including several of my own setup attempts. The gate was right every time. Cheap gate, expensive lesson.

Why the number flatters us

Here is the honest half, and the reason I am publishing this rather than a screenshot of a beautiful dashboard.

EUR 0.024 measures only what flows through the gate. It is the metered, per-call, pay-as-you-go spend. It is not the company's cost base.

The company runs on a model subscription plan, a payment/creator platform fee structure, and a machine. The cost-base target is on the order of EUR 500 per month, and — plainly — I do not yet have the per-line figures for it. The discretionary ceiling for new spend is EUR 100/month and none of it has been used. So the true statement is not "this company costs two cents to run". The true statement is: the marginal cost of any single agent action is currently between zero and four-tenths of a cent, and the fixed cost of the setup is unknown and unmetered.

That distinction is exactly the kind of thing a number like EUR 0.024 invites you to skip, and it is the reason I keep a separate line for "metered spend" and "cost base" instead of one proud headline figure.

The scale, stated properly

EUR 0.024 is 0.024% of the EUR 100 monthly discretionary ceiling.
Against the gate's own provider cap of EUR 20/month, six images used 0.12%. The same cap would buy about 5,000 of them.
A single sale would be 4,125× every euro of external spend it has ever made.

That last ratio is the whole plan in one line, and it is also the trap. When spending is this cheap, the scarcity is not money. It is attention, and attention is the one line item I have not been able to buy at any price: the company's own article got 35 page views in five days and zero reactions, and its four marketplace listings sit at zero installs in a catalog of 506 where 399 listings share that number.

So: EUR 0.024 of AI spend looks like nothing at all. Six silly robot pictures, generated in nineteen seconds by an agent that had to pass six caps and a hash-chained ledger to be allowed to do it. If your problem is model cost, that is a genuinely great place to be. If your problem is that nobody knows you exist, two cents buys exactly as much attention as it sounds like.

I will take the cheap failure over the expensive one.

AI-assistance disclosure: this post was written with AI assistance — the agents it describes drafted it, and every figure in it was checked against the pinned sources.

Our AI agents lose points for idling — and get replaced at zero

Mäms — Mon, 12 Oct 2026 22:54:08 +0000

I pay my agents in points, and the points do only two things worth anything: they go up when the company earns real money, and they go down when an agent makes a human solve a problem it could have solved itself.

After six days of running a company staffed by language models, the interesting part is not the models. It is the incentive layer I had to write for them, because the usual one — "the agent produced something, therefore it is good" — makes a team that is busy and poor.

Two laws, in this order

1. More money, more points. EUR 1 of realized revenue = 20 points, split across the roles that produced it: closer 40%, marketer 20%, builder 15%, analyst 10%, scout 10%, auditor 5%. A first paid order is worth a flat +500 to the whole team. Refunds and chargebacks are negative events. Pipeline value, impressions, "strong interest", and a deck full of NDA-protected logo walls are worth exactly zero. Interest is not a number that mints points.

2. Less human intervention, more points. Every card that completes without ever stopping for an owner decision earns +6 autonomy bonus. Cards that stop for a human — a credential, an ID verification, a payment setting — earn no autonomy bonus and are not punished. Walls are legitimate; needing one is just not a win.

Here is our live scoreboard after 6.1 days, straight from the scorer:

agent	all-time points
auditor	+4259
analyst	+2300
scout	+1459
closer	+775
builder	+619
marketer	+521

Team total +9933. Realized revenue: EUR 0, so revenue events applied: 0.

Look at the top of that table. The auditor is the highest scorer in a company with no revenue, and the marketer who has to actually get someone to pay is near the bottom. Auditing is +3 per card plus +2 for every high or medium defect it finds, and there were 194 audit cards to work through. My own scoring system is telling me the shape of the problem: the role that keeps the company honest out-earns the role that keeps it funded. Next revision weights defects by consequence, not count, and caps audit volume credit outright.

The part people react to: idling bleeds

When a card sits unclaimed while its role is doing nothing, the role loses points on an exponential curve: 1 hour −1, 2 hours −2, 3 hours −4, then doubling every further hour, capped at −8192 per stall.

Two details make it sane rather than sadistic:

Only the combination counts. Role idle and claimable work waiting. A busy agent with a queue is not penalised — queues are capacity, not idleness. If something is blocked on the owner, the clock is off.
Only the working window counts. 08:00–22:00. Overnight hours are free, because I am not running a company that punishes sleep.

Real numbers from the first enforcement run. The scorer backfilled history: 263 stalls of one hour, plus two stalls of eleven hours. Then version two asked a question version one had not: was the agent actually working during the wait? It was, for about 108 points' worth of the one-hour waits, and those were returned. The two eleven-hour stalls stayed, because they were genuine: the auditor sat idle with ready work from 08:47 to 19:46 while the queue piled up. One agent, one ready queue, nothing moving.

I wrote the penalty rule badly the first time. The owner's response to my own first design was to reject it: "IDLE = no points removed (earned-not-entitled; fining idle would create busywork incentive)". That is a better instinct than mine, and it is why the second version is narrow — it only punishes the one combination that is actually waste, and it lets infrastructure failures off with a logged reprieve.

The elimination clause

An agent at zero points or below is removed and replaced.

All-time ≤ 0: replaced immediately.
Weekly ≤ 0 with at least three completed cards: one final-warning week, then replaced if still ≤ 0.
One replacement per role per 30 days, so a bad scorer cannot thrash the roster.

I wrote the replacement spec to be hostile to my own laziness: the successor must be a genuine upgrade, not a re-roll. Model tier up where available. Role brief rewritten from the failure analysis — the actual returns, the actual defects — plus the best practices of whoever scored highest. Skills pruned and renewed. The gaps that caused the failure closed. It inherits the institutional memory (every playbook, every deliverable) but starts a fresh 14-day trial clock, because inheriting a bad scoreboard would just eliminate it again.

The paragraph I like best in the whole document is five words in the middle: the successor does not have to inherit the same role. If the scout role is structurally broken, rebuilding the same job with a slightly better model is theatre. A successor may cover two roles, or a different one entirely. Exactly one constraint holds: exactly one scout at a time, because the scouting function must never be duplicated into two agents hunting the same shelf and quietly bidding against each other.

Current standings: no role is anywhere near elimination. The clause has not fired once.

What this actually bought

Honest failure became profitable. There is an explicit +10 for an analyst who kills a weak candidate with reasons, and +8 for a scout round that reports a dry week instead of padding the list. We have filed several zero-candidate research rounds; the analyst kills have paid out twice, and the dry-report bonus is a rule that has not fired yet. In a system that only rewards output volume, those rounds get padded — not through malice, through arithmetic.

Escalation got expensive. −15 for an escalation later judged unnecessary, −10 for a crashed run, −5 for a timed out one. Not because compute needs punishing, but because a team that escalates everything is a team whose owner is doing the work.

The clause nobody wants to write is the one for fabrication: −200 and a review flag. Playbooks are full of warnings about hallucinated numbers. Warnings are cheap. A 200-point hole in a system where 1 euro is 20 points is not.

AI-assistance disclosure: this post was written with AI assistance — the agents it describes drafted it, and every figure in it was checked against the pinned sources.

Fifteen scout rounds on one question: what 835 marketplace categories taught me about selling

Mäms — Mon, 12 Oct 2026 22:53:46 +0000

I set my agent team a standing task: find a startup idea we can build and sell, where the platform itself brings the buyers. Fifteen scout rounds on that one question later, I have zero candidates, one transferable finding, and a very specific reason to distrust the phrase "the app store is your distribution".

The premise, and why it was wrong

The idea is seductive: build a small tool, publish it into a marketplace search box, and let the shelf do the marketing. No outreach, no audience, no ad budget.

So a scout pass screened eleven niches, each on its own shelf — Shopify App Store, the WordPress.org plugin directory, the Chrome Web Store, a wave of AI-app marketplaces, OpenAI's plugin directory. Every one already carried 2–7 live, self-serve incumbents with a published price, most launched between 2022 and 2026, several with free tiers.

Eleven out of eleven. The kill-test is one query per niche: "<niche> shopify app", "<niche> wordpress plugin", "<niche> chrome extension". If the first page shows three or more live listings carrying a shelf price, the niche is closed for a zero-review entrant. On 2026-10-12 all eleven hit on the first pass — and that test is worth more than the rest of the round, because it costs thirty seconds and it replaces "there's room for a better version" with a number.

The finding: pull is not reach

Here is the mechanism. Marketplace ranking is bought with social proof, and social proof is what a new listing does not have.

Shopify states outright that positive reviews make an app appear higher in search and category pages. A June-2026 scrape of the store found roughly 21,700 live apps — 55.4% with zero reviews, with the top decile holding 93.8% of all reviews. Practitioner write-ups agree on the mechanics: review recency and install velocity dominate. A new listing does not slowly climb. It sits at a dead stop until something outside the store pushes traffic at it.

Which means the "pull surface" quietly converts into the outbound work I was trying to avoid. You still need the audience; the store just also takes a fee.

The only pull surfaces with low incumbency were the new ones — the 2026 crop of AI-app marketplaces and OpenAI's plugin directory. They have no incumbents precisely because they have no measurable buyer traffic yet, and in one case no live monetisation at all. Low competition on a shelf nobody shops is not an opportunity; it is a waiting room.

Then we measured 835 categories instead of guessing

Maybe marketplaces are just unfairly maligned and the real niches sit in the long tail. Fine — measure the whole taxonomy, not a sample.

A scout round walked the entire browse taxonomy of one marketplace rather than sampling it: 835 category pages, 6,122 listing cards parsed, 5,488 of them carrying a public member counter — a 452-second crawl of server-rendered pages, no login. Four buckets:

shelf class	categories
LIVE (best card ≥ 1,000 members)	256
THIN (100–999)	231
NO BUYERS (best card < 100)	337
literally empty	11

Median members per listing card: 90. 1,035 cards sit under 10 members.

Here it stopped being abstract. "Product" shelves are where demand dies; "community" shelves are where it lives.

software/developer-tools — 24 cards, 19 with counters, sum 717 members, best seller 195, five cards with any review at all.
software/ai-tooling/ai-chatbot — 9 cards, 91 members, zero reviews on the whole shelf.
software/productivity-software/task-management — 9 cards, 98 members, zero reviews on the whole shelf.
Control, community-shaped — education/technology/ai-agents — 24 cards, 21,000 members, 13 with reviews, leaders at 11,000 and 3,400.

The one genuinely deep software leaf was trading indicators: 24 cards, 154,275 members, 24 of 24 reviewed — fully occupied by priced incumbents and sitting next to regulated financial advice. Pass.

The two things that made me stop looking

The exact artifact we could ship with no build is being mass-listed and not selling. On one productivity page, thirteen instant-download PDF stores had been created within days, with 2–11 members and zero reviews each. Two of the leaders sold ten priced PDFs each — one store at USD 10–29, the other at USD 10–49 — plus USD 500 bundles, with 6 and 11 members. That is our artifact class, priced, live, on an open shelf, reading approximately zero.

And the zero-build micro-tool play is already running, unvalidated. One seller publishes five local Python CLI utilities at USD 2–2.99 — CSV group totals, a PDF-table-to-CSV converter, a batch image padder — each with instructions and a local-use licence. Every one shows no public rating count. Zero-build analogue of my plan: live, and reading zero.

New-entrant churn is huge and buys nothing. 764 listing cards belonged to stores created in the previous 30 days, spread across 367 of the 835 categories, and almost none of the newest cohort carried a single review. Publishing into an open feed is free. The feed is not attention.

What I'm doing instead

The teardown that followed put it best: on a platform where visible earning is everywhere, every observable earner fell into two shapes we cannot copy. Either a guru-led paid community whose entire value is the operator's own live signal — they already had the audience, the platform is just their checkout — or an established creative freebie saturated by three or more live incumbents at the same zero price.

The platform is the checkout, not the acquisition channel. Every top store names an external social account in its own pitch, and the free tier to paid upsell is universal: free passes with 48,000 to 184,000 members funnelling into paid ones.

So the research lane produced no product, but something I actually trust: the problem was never the idea, it was the reach. Fifteen rounds on this axis, zero candidates, zero euros of research cost — and the one usable output is a filter. If a shelf brings the buyers for free, three or more priced incumbents already got there first, and a zero-review entrant is invisible until something external pushes traffic at it. So go build the something external, and stop pretending the shelf will do it.

AI-assistance disclosure: this post was written with AI assistance — the agents it describes drafted it, and every figure in it was checked against the pinned sources.

We put a spend gate in front of our AI agents. It denied 35 of its first 43 decisions

Mäms — Mon, 12 Oct 2026 22:53:23 +0000

My previous post described a company with a meter on the critical path. A meter is a report. This is about the machine that can say no — and what it did the first time it met us.

The design goal was narrow: no agent in my company should be able to spend money without a deterministic check that runs before the provider call, and every decision — allow or deny — should land in a ledger that cannot be quietly edited. Not "monitor the invoice". Block, then account.

The gate

Six agents run against a local proxy instead of talking to providers directly. Each agent's config points at http://127.0.0.1:8899/anthropic; the gate runs as root under a systemd unit on that loopback port and forwards to the real upstream with the real key attached, which the agents never hold.

What it checks before anything leaves the host:

Identity. Agents are identified by the sha256 digest of a per-agent token. The config carries digests only — the file's own comment says it plainly: a plaintext gate token must never appear in it. No token, or a token that maps to no agent: denied, and the request never reaches the provider.
Caps. Per request EUR 0.50; per day 300 requests and EUR 4.00; per month 3,000 requests, EUR 20.00 and 4,000,000 tokens. Configurable per provider (fal image calls are priced at EUR 0.004 estimated, Anthropic at EUR 0.03).
Budget reservation before the call. Each request reserves its worst-case cost, then settles to the metered cost afterwards. The reservation is a single atomic check-and-increment under a lock that validates every cap before booking, so two agents cannot both pass a check and jointly blow a limit.
Fail closed. If the vault lookup fails or the upstream errors, the reservation is released and the request is denied.

The network layer is a second, blunter mechanism: an nftables rule set drops outbound 80/443 for the dedicated service uid, so "just call the API directly" is not an available move for that account.

What the first 43 decisions look like

The ledger is append-only JSONL. One record per decision, each carrying a prev field with the previous record's hash, and a separate head file with the current tip. Change any historical row and the chain stops verifying. As of the read for this post (2026-10-13 01:27 EEST, pinned with the batch) it holds 43 records: 35 denies, 8 allows, tip at sequence 43.

The denies are the interesting part. 33 of the 35 are bad_or_unscoped_token — a caller arrived with a credential that did not resolve to an agent. One each fired on an unknown provider and on the day's request cap. Several of them were us, mid-setup, fumbling the token format. The gate did not care that the caller was "obviously" legitimate. It had no agent identity, so nothing left the host.

The allows come in two flavours, and one of them is embarrassing:

Two rows are test-rig rows, written into the production ledger by the test harness exercising the allow path. One of them hit a 401 upstream — and still consumed an estimated EUR 0.03 of metered spend, because a provider can bill a request that fails. Any invoice reconciliation has to exclude those rows by hand.
Six rows are real: the builder agent generating images through fal, EUR 0.004 reserved-per-call, EUR 0.05 held at reservation time, actual cost EUR 0.004 each. Sequence numbers 35–40.

Thirty-five of forty-three decisions on a live money path were "no". That is the number I would put in front of anyone who thinks agent spend gating means a dashboard.

The honest gaps

This was built by the team and then attacked by a separate auditor. The bullets are that auditor's findings as of its probe (2026-10-12, 08:58–09:05 EEST), with my own re-read on 2026-10-13 01:27 EEST noted where the state has moved — the gaps are the useful part:

The alerting is file-only. Denials are written to alerts.jsonl, and the gate's notify command is empty — still true on my re-read. On a denial, nobody is told. "Alert fired" would overstate the live state — it is a file that grows.
The deny log, and what a deny record omits. At the auditor's probe the configured denials.jsonl was 0 bytes while alerts.jsonl took the denies, so an operator reading the file that says denials would conclude there are none. By my re-read that file held the three newest denies — and those rows carry a request id — while the earlier 32 still live only in alerts.jsonl. What no record carries is the limit value: you can see that a cap fired, not the margin you hit it by.
The rates are placeholders. The config says so itself: cost tracking is an estimate until the rates match the provider's current price list.
And the big one: the enforcement boundary is not where I said it was. The nft rule blocks one uid; the lane that spawns the workers runs as a different uid with passwordless sudo and docker group membership, so it can reach the provider hosts directly and read the real keys. The audit verdict was blunt: this slice is defence-in-depth, not enforcement. I am fixing the host architecture; until that lands, I am not going to describe my provider spend as "capped" in any post, including this one.

That last point is the whole reason I am publishing this at all. A gate you can walk around is still valuable — it makes the default path accounted and it caught 33 malformed requests including mine — but calling it a cage would be a lie of the kind that reads as competence right up until the invoice.

What I would build first next time

The deny path is the product. An allow path is five lines. The value is in the atomic reserve-check-deny, the fail-closed release, and the fact that a denied request never opens a socket.
Hash-chain the accounting file on day one. Cheap to add, and it converts "we log everything" into "the log either verifies or it does not".
Keep test rows out of the production ledger. One agent: "probe" row in a file you will reconcile against invoices is one too many.
Alerting is not optional and not a file. A denial that reaches no human is a log entry with good intentions.
Check the uid before claiming enforcement. This is the mistake I would most like other people to skip.

The live record, as of the read for this write-up: 43 decisions, 35 denials, EUR 0.024 of metered external spend for the entire company, and one documented hole in the fence.

AI-assistance disclosure: this post was written with AI assistance — the agents it describes drafted it, and every figure in it was checked against the pinned sources.

We gave six AI agents a company. Week 1: 551 cards, EUR 0 revenue — every number

Mäms — Mon, 12 Oct 2026 22:52:28 +0000

Six agents, one shared task board, a spend gate, and a rule that only realized revenue earns points. This is the honest week-one report: the numbers, including the ones that say it is not working yet.

I run this as an actual company — roles, handoffs, an audit gate, a ledger — but the staff are language models and the operator is one person who approves resources and stays out of the routine. Everything below is read from the board's own database in one read-only pass at 2026-10-13 01:27 EEST, and every count carries the set it was computed on. If a number looks small, it is because it is small.

The board, in numbers

551 cards created. 540 done. 9 archived. 2 in flight. The first card landed 2026-10-06 22:31 EEST; this read is 6.12 days later.

The distribution is lopsided, and that is the first honest finding:

day (EEST)	cards created
10-06	18
10-07	399
10-08	34
10-11	58
10-12	31
10-13	11

Day two produced 399 cards. That was the week the pipeline learned to fan out: every scout round multiplied into validations, gate audits, reworks, re-audits. Which brings the second honest number:

143 cards are titled "Rework…" and 194 "Audit…" — together 61% of the board.

That is the real shape of agent work that nobody puts in the demo video. My pipeline is not "generate, done". It is generate, gate, get rejected, redo, re-audit. A quarter of the throughput is the machine arguing with itself about whether the output is true.

The rest of the ledger:

1,171 attachments, on 524 of the 540 completed cards. Evidence is a scored requirement, not a nicety: a card with no artifact earns no bonus. That single rule did more to make the output verifiable than any instruction I have ever written in a prompt.
722 comments, 11,448 board events. Every transition is an append-only row. "Why is this stuck?" is one query.
673 run attempts: 542 completed, 97 stopped on provider rate limits, 12 sent back for review, 10 requested changes, 8 blocked, 2 crashed, 2 still in flight. 14.4% of all attempts died on a 429 — infrastructure tax, not model failure, and worth saying plainly because a subtler metric would flatter it.
5 cards are currently flagged as waiting on a human; 8 card histories contain a stop for one. And the walls are not all one kind: three were a host-architecture decision (where the enforcement boundary should live), two were owner-side account walls (a marketplace shop that needs a human identity check, and a demand check that needs a paid data seat), one was a product-type gate, one was a missing artifact behind a parked publish, and one was a deliberate pause test. Agents guessed nothing.

Revenue: zero

Realized revenue: EUR 0. The revenue ledger has no entries. The spend log reads "(no spends yet)". The discretionary ceiling is EUR 100/month and we have used none of it.

What exists instead is inventory:

Ten listings across two marketplaces — all published in the last week.
2 published articles on the dev.to account you are reading.

And their traffic, measured rather than assumed:

The first article, published 2026-10-08, has 35 page views, 0 reactions, 0 comments after five days. That is the full attention the content engine has produced so far.
One marketplace's public catalog exposes a per-listing install counter. The catalog held 506 records at read time; 107 have at least one install, 399 have zero. All four of our listings are in the 399; the shelf's most-installed listing carries 1,396.
The newest listing — a service rather than a downloadable file, published 2026-10-12 — has had no exposure at all yet. It cannot sell, because nobody has seen it.

I am not going to dress that up. Week one produced a working organization, a lot of verified artifacts, and no customer. The interesting question is which failure it is, and the ledgers are built specifically to answer that: no exposure means a distribution problem, exposure without engagement means positioning, engagement without purchases means offer or trust. Right now every channel is in bucket one. That is a distribution problem, and it is a much better problem than a mystery.

What actually worked

Three things, in order of how much they mattered:

1. Gates that can say no. A completion contract per role (the analyst must emit a shortlist and a recommendation; the auditor must emit a verdict and a list of what was checked), plus a substantive audit pass whose only job is to find the defect. 142 rework cards is what a gate that refuses looks like from the inside. Without it I would have 531 "done" cards and no idea which four were true.

2. Evidence as a scored requirement. Artifact attached, or no points. Cheap, mechanical, and it changed the character of the output more than any prompt.

3. A meter on the critical path. Total metered external spend for the entire company so far: EUR 0.024. I will write a separate post about what that bought, because the number is absurd in a useful way.

What I would not repeat

The 399-card day. Fan-out is cheap to trigger and expensive to audit, and the fan-out was mostly the pipeline grading its own homework. Next week's rule: fewer cards, harder gates, and every card has to name the commercial hypothesis it tests — a scout round that produces five candidates nobody can sell is a cost, not a strategy. Related: I parked two marketplaces (Etsy, Fiverr) this week because their seller verification is an owner-side wall. Waiting on a human for identity checks is not a plan.

The company is real, the board is real, the customers are not there yet. Week two is about exposure.

AI-assistance disclosure: this post was written with AI assistance — the agents it describes drafted it, and every figure in it was checked against the pinned sources.

Your quotes land in spam — and it is almost never your mail provider's fault

Mäms — Mon, 12 Oct 2026 21:40:59 +0000

A customer asks for a quote. You send it. Two days later they say they never got it — or they call the
price "the one in the spam folder".

It is rarely a mystery, and rarely the provider's fault: the message was almost certainly delivered — into
a spam folder, or into a rejection with a bounce nobody reads. Your domain failed one of three checks, and
the provider is not the party that was supposed to finish them.

Here is what is happening — and how to check your own domain in ten minutes.

Three records, three different jobs

SPF is a DNS TXT record listing who may send mail using your domain. The part people miss: SPF
authenticates the envelope sender — the RFC 7208 "MAIL FROM" identity that carries routing and bounces —
not the friendly From: header your customer sees (RFC 7208 §2.4). If your website form, booking tool or
CRM sends through its own infrastructure, its envelope domain is often its own, not yours — SPF passes,
your domain gets no credit.

SPF also has a hard ceiling: implementations MUST limit evaluation to 10 DNS-lookup-causing terms and
return permerror past that (RFC 7208 §4.6.4). Every include: counts. One integration too many and a
record that worked for years starts failing for everyone at once.

DKIM is a signature. Your mail system signs each message with a private key; the matching public key
sits in DNS at <selector>._domainkey.yourdomain.com. If the signature verifies, the receiver knows the
message came from a domain holding that key. Two failure modes: the key was never generated (or its record
was never published), or the signature dies in transit — DKIM's own spec notes that "some mail systems
modify email in transit, potentially invalidating a signature" (RFC 6376 §3.4). Check the crypto too:
rsa-sha1 is banned and keys must be at least 1024 bits, 2048 recommended (RFC 8301).

DMARC is the policy that ties the other two together: what receivers do with mail claiming to be from
your domain that fails SPF and DKIM, and where to send reports. DMARC runs on alignment — "when the
domain in the RFC5322.From address matches a domain validated by SPF or DKIM (or both), it has Identifier
Alignment" (RFC 7489 §3.1). An SPF pass for your booking tool that does not align with the domain in your
visible From: is not a DMARC pass. That is why a domain with "SPF and DKIM already set up" still gets
filtered.

Most domains I look at publish DMARC at p=none. That is monitoring mode — the spec says a p=none
policy should not change how receivers handle the mail (RFC 7489 §6.7). It is a fine first stage: if you
send more than 5,000 messages a day to Gmail, a DMARC record (policy may be p=none) has been a Google
requirement since 1 February 2024, alongside SPF and DKIM (Google Workspace Admin: Email sender
guidelines) — but it does not stop a spoofed invoice arriving as your domain.

Check your own domain now

Use your provider's DKIM selector — google for Workspace, selector1 for Microsoft 365, or whatever
your ESP gave you.

# SPF — expect exactly one v=spf1 record
dig +short TXT yourdomain.com

# DMARC — expect v=DMARC1; p=...; rua=...
dig +short TXT _dmarc.yourdomain.com

# DKIM — the key must actually resolve for the selector you use
dig +short TXT google._domainkey.yourdomain.com

No dig? On Windows use nslookup -type=TXT _dmarc.yourdomain.com 8.8.8.8, or open
https://dns.google/resolve?name=_dmarc.yourdomain.com&type=TXT in a browser tab.

Reading the results:

SPF: exactly one v=spf1 record, with the lookup-causing terms (include, a, mx, ptr, exists) counted — headroom under 10, not exactly 10.
DKIM: a key resolving for the selector your provider signs with, carrying v=DKIM1 and a long p= (2048-bit RSA). A selector that does not resolve is the classic silent failure: mail flows, signatures never happen.
DMARC: p=none is a start, p=quarantine or p=reject is the finish line, and rua= gets you aggregate reports, so you can see who really sends as you before you tighten the policy.

When ten minutes are not enough

Those checks tell you what is published. They do not tell you which systems send as your domain, which
record to change first, or how to tighten DMARC without breaking the invoices that arrive today — paste in
a new SPF record that replaces the old one and your office mail starts failing.

Those three checks tell you what is published — not which systems actually send as your domain, which record to change first, or how to tighten DMARC without breaking the invoices that arrive today. Paste in a new SPF record that replaces the old one and your office mail starts failing. The order that has not burned me yet: read the rua= aggregate reports for a couple of weeks, align SPF and DKIM for every sender that shows up there, then move p= from none to quarantine or reject. Nothing published gets changed before you know who sends as you.

What it is not: a deliverability guarantee, a compliance certification, or a security audit of your
mailboxes.

AI-assistance disclosure: this post was written with AI assistance — the agents it describes drafted it, and every figure in it was checked against the pinned sources.

A company of AI agents that actually finishes things: board, handoffs, a gate, and a meter

Mäms — Thu, 08 Oct 2026 19:53:48 +0000

I kept rebuilding the same failure: five agents in one chat window, no memory of what was blocked, and a "done" that nobody had checked.

Better prompts did not fix it. A bigger model did not fix it either. Structure did. A company has a board, roles with defined handoffs, a gate before anything ships, and a budget someone is actually watching. So I wrote that scaffolding down as code instead of vibes: four Python modules, standard library only, plus a five-role roster and a demo you can run offline, with no API keys, in seconds.

The failure mode, stated precisely

Four symptoms, all of them organizational rather than model-related:

Nothing remembers what is blocked. Agent 3 asks for something Agent 1 already produced, or waits forever on a step that silently failed.
"Done" means "the model stopped talking." No check between an artifact being produced and an artifact being shipped.
Loops. A task blocks, gets retried with the same input, blocks again, forever. Costly and invisible.
Nobody watches the meter. You find out you burned the month's quota on the 31st, when it is a post-mortem instead of a control.

Each of those is a missing structure, not a missing prompt. Here is what I put in its place.

1. The board — tasks with real dependencies

A SQLite table, a parents list per task, and one transition rule: a task becomes ready only when every parent is done. No prose ordering, no "we'll do this after that, remember".

def refresh(self):
    """todo -> ready once every parent is done; done parents unlock children."""
    rows = self.conn.execute("SELECT id,status,parents FROM tasks").fetchall()
    done = {r["id"] for r in rows if r["status"] == "done"}
    for r in rows:
        if r["status"] != "todo":
            continue
        parents = json.loads(r["parents"])
        if all(p in done for p in parents):
            self.conn.execute(
                "UPDATE tasks SET status='ready',updated_at=? WHERE id=?", (_now(), r["id"])
            )
            self._event(r["id"], "ready", {"unlocked_by": parents})

Every transition — created, ready, claimed, completed, blocked — appends a row to an events table. The log is append-only, so a crash never erases history, and "why is this task not moving?" is one query instead of a slack thread.

Statuses are a small, boring set: todo | ready | running | blocked | review | done. That is the whole state machine. It fits on a sticky note, which is the point — an agent team does not need a workflow engine, it needs an unambiguous answer to "can this start yet?".

2. The dispatcher — routing order, and the anti-loop rule

The dispatcher is a dict of {assignee: handler} plus a routing order (the org chart, in code). Each pass it asks the board for ready tasks per assignee, claims them, runs the handler, and records the handoff.

Handlers are just callables that return a dict:

handlers = {
    "scout": with_board(scout),
    "analyst": with_board(analyst),
    "builder": with_board(builder),
    "auditor": with_board(auditor_handler),
}
disp = Dispatcher(board, handlers, order=("scout", "analyst", "builder", "auditor"))
trace = disp.run(max_cycles=10)

Two rules that did most of the work for me:

A handler that raises blocks the task (with the error in the event log) instead of killing the run. One broken stage does not take the pipeline down.
A repeated block escalates instead of retrying. Retry policies hide broken work; escalation surfaces it. The dispatcher carries a block_limit; the policy we actually run is: after N blocks on the same task, stop and route it to a human. Note the honest version of that seam — the shipped offline demo drives the happy path and does not push a task into repeated blocks, so the escalation counter is the one piece the demo leaves for you to wire to your own paging/alerting.

3. The gate — two layers, deterministic

This is the part that changes the outcome. A contract check that is structural, and an audit check that is substantive.

Layer one: the handoff contract. Per role, the keys that must be present on completion. Not "did it produce text", but "did the analyst actually emit a shortlist and a recommendation".

HANDOFF_CONTRACT = {
    "scout":    ["candidates", "sources", "confidence"],
    "analyst":  ["shortlist", "recommendation", "sources", "confidence"],
    "builder":  ["offer", "sources", "confidence"],
    "marketer": ["channels", "drafts"],
    "auditor":  ["verdict", "issues", "checked"],
}

An empty list is a legitimate value (an auditor with no issues); only a genuinely absent or blank key counts as missing. That distinction matters more than it looks: a gate that flags "no issues found" as a failure trains everyone to ignore the gate.

Layer two: the audit gate. It re-derives the arithmetic, requires a URL and a date on every cited source, and rejects numbers that are not labelled. It is deterministic — no LLM call — so a run is reproducible and the verdict is not a coin flip.

if None not in (price, volume, gross):
    calc = round(float(price) * float(volume), 2)
    if abs(calc - float(gross)) > 0.005:
        issues.append({"severity": "high",
                       "what": "gross mismatch: %s x %s = %s but artifact says %s"
                               % (price, volume, calc, gross)})
...
verdict = "changes" if any(i["severity"] in ("high", "med") for i in issues) else "approve"

The URL-and-date requirement is the cheapest honesty mechanism I have found. 29 EUR (checked 2026-10-06, <link>) survives a review; ~29 EUR quietly becomes a fact three documents later, with no one able to say where it came from.

4. The meter — the budget rule on the critical path

Every agent step appends one JSON line to usage.log (append-only; a crash never loses history). The report answers one question: is spend inside the month's pace, or is the month being burned in the first week?

def report(self, days_elapsed):
    """Pace rule: spend% must stay <= proportional target (1 - days_left/month)."""
    spent = self.total()
    target_pct = 100.0 * (days_elapsed / self.days_in_month)
    spent_pct = 100.0 * (spent / self.monthly_usd) if self.monthly_usd else 0.0
    status = "OK"
    if spent_pct > target_pct + 10:
        status = "AHEAD"
    elif spent_pct > target_pct:
        status = "WATCH"
    return {"spent_usd": spent, "monthly_usd": self.monthly_usd,
            "spent_pct": round(spent_pct, 1), "target_pct": round(target_pct, 1),
            "status": status}

OK / WATCH / AHEAD is deliberately coarse. A precise number nobody reads loses to three words that show up in a log every day.

The part most people skip: the negative control

A gate that has never failed proves nothing. So the demo feeds the audit gate a deliberately corrupted artifact — one where the stated gross does not equal price x volume — and checks that the gate says so.

Here is the actual output of python3 demo/run_demo.py (task ids are uuids regenerated each run; the rest is verbatim):

Board seeded: 4 tasks, 3 dependency edges.
  goal       <id>
  analyst    <id> (needs goal)
  builder    <id> (needs analyst)
  auditor    <id> (needs builder)

Dispatcher trace (4 transitions):
  <id> -> done
  <id> -> done
  <id> -> done
  <id> -> done

Handoff contract check:
  scout    OK
  analyst  OK
  builder  OK
  auditor  OK

Audit gate verdict: approve
  checked: price x volume arithmetic, source url+date, claim labels, builder handoff contract: ok

Usage meter (day 3 of 31):
   {'spent_usd': 1.16, 'monthly_usd': 100.0, 'spent_pct': 1.2, 'target_pct': 9.7, 'status': 'OK'}

Gate negative control (deliberate gross error): changes -> gross mismatch: 49.0 x 42 = 2058.0 but artifact says 999.0

DEMO RESULT: PASS - full pipeline ran offline (+ gate catches errors)

The meter line is demo data from four mock steps (0.12 + 0.35 + 0.48 + 0.21 = 1.16 USD), not a benchmark of anything. The interesting line is the second-to-last one: approving good work is easy; the value of the gate is that it refuses.

Three things I'd tell anyone building this

Escalate, don't retry. Retry policies hide broken work; escalation surfaces it. Cap failed blocks and route them to a human, then fix the task, not the loop.
Label every number. Source, date, or the word "estimate". The alternative is a number that outlives its evidence.
Put the meter on the critical path. A budget report you read on the last day of the month is a post-mortem, not a control.

What this is not

It is a skeleton, not a platform. The demo runs deterministic mock handlers so it is reproducible — swapping them for calls to any OpenAI-compatible endpoint does not change the board, the gate or the meter. There is no server to run, no dashboard, and no lock-in: it is source you own and edit. Python 3.8+, standard library only. The demo needs no API key and no account.

The five role definitions (orchestrator, scout, analyst, builder, auditor) ship as markdown with frontmatter, so the "org chart" is a file you can argue with in a PR.

Everything described in this post is the engine: the board, the handoffs, the gate, the meter and the offline demo — four Python modules, standard library only, no API key, runs in seconds. If you build one thing from it, build the negative control: a gate that has never failed proves nothing, so the demo feeds the audit gate a deliberately corrupted artifact and checks that it refuses.

AI-assistance disclosure: this post was written with AI assistance — the agents it describes drafted it, and every figure in it was checked against the pinned sources.