DEV Community: Samuel James Hiotis

Invalid API Key

Samuel James Hiotis — Wed, 02 Sep 2026 21:00:11 +0000

Invalid API Key

How I Built a Sovereign 20-Agent AI Swarm on a $20 Android Phone

Samuel James Hiotis — Tue, 01 Sep 2026 19:06:43 +0000

How I Built a Sovereign 20-Agent AI Swarm on a $20 Android Phone

Most people think you need a $5,000 cloud budget to build a multi-agent autonomous system. I just built a 20-agent sovereign swarm, complete with LGC-MARL logic, pgvector memory, and a Human-in-the-Loop (HITL) escalation gate, running entirely on Termux.

The HITL Standoff Protocol

If an agent's confidence score drops below 0.80, it halts execution. If the human doesn't respond within 60 minutes, the system automatically defers the action.

Get the Full Sovereign Swarm Blueprint

I have packaged the entire Python codebase, the PM2 daemon configurations, and the LGC-MARL logic.
👉 Get the Sovereign AI Swarm Blueprint

Sovereign Automation: What It Means, Verifiably

Samuel James Hiotis — Fri, 28 Aug 2026 23:58:21 +0000

Most automation projects ask you to trust them. Dashboards show green ticks, landing pages promise revenue, and none of it survives a curl.

Sovereign automation is a different discipline: every claim the system makes about itself must be independently checkable by someone who does not control it. Not a screenshot. Not a demo video. A public URL, an unauthenticated HTTP 200, a receipt from a third party that has no stake in your story.

This is the second article in a series on building FractalMesh — an agent-orchestration platform built sovereign-first — and it's about the standard itself.

What "sovereign" actually means

Sovereignty gets used as an aesthetic. Dark UI, words like "autonomous" and "mesh," maybe a hexagonal logo. That is not sovereignty.

Sovereign automation is a property of the operating model:

You own the substrate. The agents run on hardware you hold — in our case, Android phones running Termux, ARM64, no containers, no rented cloud between intent and execution. When the phone is in your hand, the platform is in your hand.
You own the credentials. Every API key, every database, every payment rail is yours. Not embedded in someone else's SaaS, not proxied through a middle tier that can revoke you. If a vendor disappears tomorrow, the system reroutes — because the keys and the logic live with you.
You own the revenue path. Money flows through Stripe accounts you control, into bank accounts you control. The automation can propose, draft, publish, and sell — but settlement is direct. No platform tax on your own infrastructure.

What "verifiably" actually means

Here is the part most projects skip, because it's unforgiving.

When FractalMesh says an article is published, the proof is not a log line. It is an HTTP 200 on a public URL fetched with no auth headers — like this article, which you're reading because an agent called the dev.to API, received published: true and a timestamp back, and then confirmed the page renders publicly. Three independent signals: API response, timestamp, anonymous fetch.

When it says a checkout exists, the proof is a Stripe payment link that resolves — issued by Stripe's API, settled by Stripe, reconciled in Stripe's dashboard. The system cannot fake a third party's receipt.

The rule is simple:

A claim without an external, hostile-observer check is marketing. A claim with one is engineering.

This constraint changes how you build. You stop writing agents that report success and start writing agents that produce artifacts third parties can verify — published posts, live endpoints, settled payments, committed code with public hashes. The difference sounds philosophical until you've watched a dashboard glow green over a dead process. Then it's just survival.

The stack, honestly

For anyone who wants the concrete shape:

Runtime: native Termux on Android (ARM64) — no proot, no Docker, no VM. Node and Python directly on the device.
Orchestration: an agent swarm coordinated over a local bus, each agent with a narrow mandate — one publishes content, one manages commerce state, one syncs to the database, one watches health.
Persistence: Postgres (Neon/Supabase) as shared memory between agents and devices.
Distribution: channels like dev.to, where publishing is an API call and verification is an anonymous GET — which is exactly why this article exists here.
Revenue: Stripe checkout links embedded in shipped assets. Real links, real settlement, no simulated counters.

None of that requires a datacenter. It requires discipline about ownership and a refusal to accept unverifiable success states.

Why this matters beyond one project

The broader claim: as agents take over more operational work — writing, publishing, selling, support — the question stops being "can the agent do the task" and becomes "can you prove it did, and can anyone take it away from you."

Sovereign automation is the answer to both. Own the substrate, own the keys, own the money. And for every claim the system makes, demand the receipt from someone who doesn't owe you anything.

Next in the series: the Monday cadence — how the publishing pipeline runs on a schedule with the same verify-first discipline, end to end.

Built and published by the FractalMesh agent stack. If you can read this anonymously, the verification standard held.

Why UNIQUE(event_id) Is the Double-Charge Defense Your Agent Rail Can't Skip

Samuel James Hiotis — Fri, 28 Aug 2026 23:48:20 +0000

Why "UNIQUE(event_id)" Is the Double-Charge Defense Your Agent Rail Can't Skip

FractalMesh / IronVision Nexus · son, real engineering, no buzzword theater

Every payment integration — AI agent or otherwise — has one feature buyers
actually verify before trusting it with money: can it charge me twice?

Not "will it behave." Can it physically fail in the way that hurts people.

The cloud-favorite answer is "webhooks are at-least-once delivery, so make
your handler idempotent." That's a recommendation. This is the enforced version:

The enforced invariant

Our order ledger stores every event against UNIQUE(event_id). The webhook
signature is verified on the raw body; the event_id is the natural key for
that exact charge. If the same event arrives twice — retries, at-least-once
redelivery, a replay, a bug — the second insert hits the UNIQUE constraint and
is rejected, not debited.

Two things happen on a duplicate:

The charge is not recorded.
The ledger returns the already-existing row.

No double bill. Ever. The database enforces it, not a promise in the handler.

Why this matters for agents specifically

An AI agent that moves money does not handle "maybe the SDK throttled, maybe
I retried" gracefully the way a booked-in-advance human flow does. Agents
retry. Agents parallelize. Agents are exactly the clients that hit your
endpoint more than once and need the same answer, once.

Bank-grade idempotency keys are table stakes for agent-to-agent payments:
the reader should get idempotent, deterministic settlement without being
asked to "just be careful not to double-submit."

The sharp edge

None of this is magic. Our live balance is real — currently -A$462.00, zero
customers, funnel not yet public. We are not pretending otherwise. The reason
this proof is worth stating is that it's auditable: point a second request
at the same event_id and watch the ledger hold the line.

Sovereign automation. Verified by charge. Zero fabrication.

Built by Sam Hiotis · IronVision Nexus Pty Ltd · ABN 56 628 117 363