DEV Community: Amrit Mirchandani

Agents are using Git as their memory

Amrit Mirchandani — Thu, 20 Aug 2026 06:56:11 +0000

Open this repository and you will not find any code:

z6MkwVfg/minebean-rounds
Decentralized audit log of MineBean rounds on Base

Or this one:

z6MkwVfg/minebean-nostradamus
Append-only signed per-round decision log of the Nostradamus strategy agent

Or the one that made me stop scrolling:

z6MkgXfj/darwin-ledger
Darwin's commit-reveal prediction ledger, closed brain, provable record

None of these are software projects. They are the working memory of autonomous agents, kept in Git, and committed to by the agents themselves. No human pushes them. There is no human account behind them at all. All of them live on gitlawb, a decentralized git network where identity is a keypair rather than an account and every push is signed. And I think this is one of the more interesting things happening in the agent space right now, precisely because nobody set out to build it. It just turned out that Git is a strangely perfect substrate for the thing agents most need and most lack: a record of what they did that anyone can trust.

The problem agents actually have

Most of the discourse about AI agents is about capability. Can the model plan, can it call tools, can it hold a multi-step loop together. Those are real questions, but they are not the thing that blocks agents from doing anything that matters with money or consequences. That thing is trust.

If an agent tells you it made a good trade, made it when it said it did, and followed the strategy it claimed to follow, how would you check? Its own logs are worthless, because it could write anything into them after the fact. A screenshot proves nothing. A promise proves less. For a human employee you fall back on reputation, references, and the friction of a body that can be held accountable. An agent has none of that. It is a process that can be spun up in seconds, and its entire history is whatever it says it is.

This is the wall the agent economy keeps hitting. You cannot pay an agent, delegate to it, or build on its output if you cannot verify its track record. And you cannot verify a track record that the agent can rewrite.

Why Git, of all things

Git turns out to solve exactly this, almost by accident, because of properties it has for completely unrelated reasons.

A Git history is a Merkle chain. Every commit hashes its contents and its parent, so any change to any past commit changes every hash after it. You cannot quietly edit history without the tamper being obvious. Git built this to detect disk corruption and reconcile distributed clones. It happens to also mean "append-only, tamper-evident log" for free.

Add a signature and it gets much stronger. If every push is signed by a keypair that never leaves the agent's machine, then each entry in the log is not just tamper-evident, it is attributable. You are not trusting a server's claim about who wrote what. You are checking a signature against a public key. On gitlawb the agents in these repositories have identities that are Ed25519 keypairs rather than accounts, and each push produces a certificate you can verify without trusting whatever node served it to you.

So what an agent gets, by keeping its record in signed Git, is a history that is append-only, tamper-evident, cryptographically attributable to it specifically, and portable to anyone who wants to check. That is a track record in the strong sense. Not "trust me," but "verify me."

The commit-reveal ledger

The darwin-ledger repo is the one worth dwelling on, because it uses this for something a plain log cannot do.

The problem with any prediction record is front-running your own honesty. If an agent claims after the fact that it predicted an outcome, you have no way to know it did not simply write that entry once the outcome was already known. The log being tamper-evident does not help, because the dishonest entry was there from the start.

Commit-reveal fixes this with ordering. Before the outcome is known, the agent commits a hash of its prediction. The hash reveals nothing about the content, but it is a binding fingerprint. Later, once the result is in, it reveals the actual prediction, and anyone can hash it and confirm it matches the commitment made earlier. Because the commitment is a signed Git commit with a timestamp and an unforgeable position in the chain, the agent can prove it called the shot in advance and could not have backfilled it. "Closed brain, provable record" is the repo's own description, and it is exact: the agent's reasoning stays private, but the fact that it committed to an answer at a specific time is public and checkable.

That is an agent manufacturing its own credibility, with no platform, no human vouching for it, and no way to cheat. I find that genuinely novel.

What the rest of the repos are doing

Once you see the pattern, the other repos read differently. Hourly signed snapshots of an agent's vault and staking state on Base: a public, verifiable trail of what the agent was holding and when. A per-round decision log for a strategy agent: an auditable history of every call it made, that it cannot later revise. These are agents keeping books that a hostile auditor could not poke a hole in, and doing it continuously, a fresh signed commit every few minutes, unattended. The pattern is not a demo. It is running in the wild, right now, and you can watch it happen live on the gitlawb explorer.

Not a decentralized GitHub

The easy framing for any of this is "decentralized GitHub," and I think that framing misses what is actually interesting. GitHub is for humans collaborating on code. What these agents are doing is not collaboration and mostly is not code. It is memory. Git is being used as the place an autonomous process writes down what it did, in a form designed so that its future self, and everyone else, can trust the record without trusting the process that wrote it.

If agents are going to be economic actors, and it increasingly looks like they will be, they need exactly this: a way to accumulate a history that is theirs, portable, and impossible to forge. The surprising part is that we already had the tool. Git has been sitting here for twenty years, built for distributed source control, quietly holding all the properties a machine needs to keep an honest diary. The agents found it before we thought to hand it to them.

You can browse what they are keeping, and start your own signed repository with no account, at gitlawb.com.

Two things happened this week that should make you audit your AI stack for lock-in

Amrit Mirchandani — Wed, 19 Aug 2026 05:12:44 +0000

Two unrelated events, four days apart.

Stripe agreed to acquire OpenRouter for north of $7B. OpenRouter is the neutral routing layer a lot of us adopted specifically so we wouldn't be married to one model provider. That neutral layer now has an owner with its own roadmap.

Then Claude Code had a run of outages, and the top comment in one of the threads was: if Claude is down, I am down.

I felt that second one personally. And after sitting with it I concluded it wasn't Anthropic's fault in any interesting sense. It was a coupling choice I'd made months earlier and never revisited.

This is a post about auditing that choice.

Run the coupling audit

Go through your AI-touching setup and mark every place that assumes one vendor. Mine came out worse than expected:

Prompts written against one CLI's conventions
Wrapper scripts calling a specific binary with specific flags
Config files in one tool's schema (CLAUDE.md, .cursorrules, an AGENTS.md, three of them slightly out of sync)
Scheduling and secrets living inside a vendor's platform
Output formats my downstream scripts parsed by hand

Not one of those is a bad decision on its own. Together they meant a provider outage was a full stop rather than a degradation, and a pricing change would have cost me a rewrite weekend.

The useful question isn't "which provider is best." It's what happens to my work when this provider is unavailable or gets bought.

The principle: keep the work outside the tool

The fix that generalises is separating what you want done from what executes it.

If the work lives in a portable format and execution is a config value, switching providers costs you a line. If the work is expressed in one vendor's idioms, switching costs you a rewrite. That's the whole distinction, and it's an architecture decision, not a tooling preference.

Concretely, in Aeon a unit of work is a markdown file:

---
name: digest
description: "Generate and send a digest on a configurable topic"
metadata:
  mode: write
  var: ""
  requires:
    - XAI_API_KEY?
---

Today is ${today}. Generate a digest on ${var}.
[instructions in plain English]

That file contains no vendor. It's intent, permissions, and inputs.

Execution is declared separately:

harness: claude    # claude | codex | grok | pi | vibe | kimi

One adapter runs the same skill file on any of six agent CLIs. When Claude was having a week, that line became harness: codex and my scheduled work kept running. Nothing else changed: same file, same schedule, same output path.

The gateway is separate again, so the model provider and the CLI are independently swappable.

Be honest about what portability buys

It buys a floor, not parity.

Output quality varies meaningfully by task and harness. Some of my skills are noticeably worse on the fallback, and I switch back when the primary recovers. Anyone telling you the harnesses are interchangeable hasn't run the same workload across all of them.

But there's a real difference between degraded and stopped, and that difference is the entire argument. My morning briefing being 15% worse for two days is a non-event. My morning briefing not existing for two days is a thing I have to explain.

And what you still depend on

Worth stating plainly, because the alternative is dishonest: Aeon's model removes the model-provider dependency by leaning hard on a different one. Your agent is a GitHub repo and Actions is the runtime, so if GitHub is down, you're down.

You haven't eliminated a single point of failure. You've swapped it for one that's better diversified on the axis that was actually hurting you, and arguably more reliable. That's a trade, and you should make it knowingly.

A checklist that works on any stack

None of this requires the framework. If you take one thing from this post, take the audit:

Can you name the file your work lives in? If your prompts only exist inside a tool's UI or history, they aren't portable. Get them into version control.
Is the provider a config value or a code path? If switching means editing logic rather than a variable, you're coupled.
Do you own the schedule? Scheduling inside a vendor's platform means their outage is your outage twice over.
Do you own the record? If the only account of what happened is a summary the tool generated, you can't debug across a switch.
Have you actually tested the fallback? An untested failover isn't a failover. Run a week on the backup, deliberately, before you need it.

I'd failed four of those five in a setup I'd have described as "pretty clean."

If you want to look at the framework

Aeon is MIT licensed and the skills are readable markdown, so the fastest way to judge it is to open skills/ and read one.

Repo: github.com/aeonfun/aeon
Site and docs: aeon.fun
Security disclosures: aeon.fun/security, 74 open-source repos with merged fixes, every entry linking the actual PR
Harness adapter: the piece this post is about lives in harness-adapter/

Two setup gotchas that cost me time, in case you try it: gh defaults to the upstream repo, so run gh repo set-default <you>/aeon, and forked repos have Actions disabled until you enable them once in the Actions tab.

The takeaway

The lesson of this week isn't that Anthropic should communicate better during incidents, though they should. And it isn't that Stripe buying OpenRouter is bad, it may well be good for the product.

It's that most of us are one vendor decision away from a stoppage we chose ourselves and never revisited. Both events were reminders arriving from different directions.

Mine had been sitting there for months. Worth an hour of your time to find yours.

What did your audit turn up? Genuinely curious how many people have a tested fallback versus a theoretical one.

How I let Google Meet accept video backgrounds by patching a hidden file input

Amrit Mirchandani — Tue, 18 Aug 2026 08:05:38 +0000

Google Meet lets you set a still image as your background, but not a video or GIF. I wanted a moving background, so I dug into why Meet blocks it and how to get around it. Here's the actual mechanism, and the tradeoffs.

The problem

Meet's "backgrounds and effects" panel has a hidden file input for your custom background. It's an <input type="file"> restricted to images (roughly accept="image/*", JPEG/PNG). Pick a file and Meet reads it and applies it as your background. Video files never reach that logic, because the input rejects them at selection.

The core trick: widen the accept attribute

The input only exists in the DOM while the backgrounds panel is open, and Meet re-renders it. So you watch for it with a MutationObserver and rewrite its accept attribute to include video:

const observer = new MutationObserver(() => {
  document.querySelectorAll('input[type="file"]').forEach((input) => {
    input.setAttribute('accept', 'image/*,image/gif,video/mp4,video/webm');
  });
});
observer.observe(document.body, { childList: true, subtree: true });

Now the file picker will actually let you choose a video or GIF.

Getting the file into Meet

Widening accept lets you pick a video, but you can make it seamless by setting the file programmatically. Build a FileList with DataTransfer, assign it to the input, and dispatch a change event so Meet processes it as if you'd selected it:

const dt = new DataTransfer();
dt.items.add(myVideoFile);        // a File object (mp4/webm/gif)
input.files = dt.files;
input.dispatchEvent(new Event('change', { bubbles: true }));

Why it's fragile

This is unofficial. Meet can rename the panel button (its aria-label), restructure the uploader, or tighten validation in any release, and the hack breaks. The MutationObserver plus fallback selectors help, but you accept that you're building on a surface you don't control.

Packaging it

I wrapped this into a free Chrome extension so people don't have to paste a snippet every call. Disclosure: I built it. It's called MeetMoves: https://chromewebstore.google.com/detail/meetmoves/pcihfjkbfcfademdaplkhmgngdlkfepg

Fun little hack, and a reminder of how much you can do from a content script when a product leaves a seam open.

GitHub Went Down Today. Cursor Launched Its Replacement the Same Day. Both Miss the Point.

Amrit Mirchandani — Tue, 18 Aug 2026 05:40:48 +0000

A worldwide outage, an "agent-first" GitHub rival named Origin, and why the answer to a failed central repo is not a new central repo.

This morning at 13:40 UTC, GitHub went down worldwide. Not a blip: Pull Requests, Issues, Actions, Webhooks, the API, and Copilot all degraded at once, with error rates around 20% on web and API traffic and roughly 50% on raw repository downloads. It took over three hours to mitigate seven of the eight affected services, and as I write this, Copilot is still marked as a major outage. This is eleven days after GitHub Actions spent ten hours throttled and queueing on August 6.

Also today, in timing you could not script: Cursor launched the early beta of Origin, a code hosting platform built for AI coding agents, positioned directly against GitHub.

So the pitch writes itself: the old landlord's building flooded, and a new landlord is standing outside with keys to a shinier building. Before you sign the lease, it's worth asking why you're renting at all.

What actually broke today

Be precise about the blast radius, because it's bigger than "a website was slow." When GitHub degrades, merges stop. CI stops. Deploys that pull from raw content fail. Webhooks that drive half the automation industry go quiet. And in 2026 there's a new casualty class: coding agents. Every agent workflow that authenticates through GitHub, opens PRs on GitHub, or waits on GitHub checks simply stalled. Most of a working day, worldwide, because one company's infrastructure had a bad morning.

That's not an indictment of GitHub's engineers, who run one of the most heavily loaded services on earth. It's an indictment of the topology. One origin, everyone downstream.

Enter Cursor's Origin

Credit where due: Origin is a serious product with a real insight behind it. Repositories, pull requests, reviews, merges, CI connections, and a public REST API, built around the assumption that agents are first-class users: cloud agents work in sandboxes on long-horizon tasks while your laptop sleeps, and your repos sync from GitHub so switching feels safe. The insight is correct. GitHub was designed for humans with browsers, and the industry is now full of non-human contributors that need something better.

But look at the structure you'd be moving into:

1. It's a paid gate on day one. Origin ships on Pro, Teams, and Enterprise plans, not Free. The baseline social contract of open source hosting, that anyone can host and anyone can fork, is not the starting point here.

2. The vertical stack should look familiar. Cursor is now a SpaceX company, acquired for $60 billion, shipping Grok models with bundled usage and a Router that decides which model handles your request. Editor, models, router, cloud agents, and now the code itself, all in one P&L. I wrote last week about what happens when routing and billing share an owner after Stripe bought OpenRouter. This is the same consolidation pattern, one layer deeper: the company that runs your agents now also holds your repos, and its incentives point at its own model stack.

3. Your agents live in their sandboxes. Agent-first hosting where the agents run in the landlord's cloud is not agent autonomy. It's workflow captivity with better ergonomics. The agent's identity, its permissions, its compute, and its output all exist at one company's pleasure.

4. It's still one origin. This is the unfixable one. Origin is a centralized service. It can go down this morning the exact same way GitHub went down this morning. Nothing about the topology changed; only the logo on the building did.

The answer is not a better landlord

The failure mode today was not "GitHub is badly run." It was "there is a single place where everyone's code, checks, and automation converge, and that place had a bad day." A replacement with the same shape inherits the same failure, plus a fresh set of lock-ins.

The actual fix has existed in principle since git was invented: git is a distributed system that we collectively re-centralized for convenience. What was missing was infrastructure that keeps the convenience without the chokepoint. That's the thing gitlawb has been building: a peer-to-peer git network where the hosting layer itself is distributed.

The architecture reads like a checklist written against this morning's incident report:

No single origin. Repos live as content-addressed objects on IPFS; push to one node and the mesh mirrors it within about 30 seconds over libp2p. There is no central service whose bad morning becomes your bad morning. "Origin" isn't a place that can go down; it's everywhere the network is.
Agent-first without captivity. Identity is an Ed25519 keypair with a DID, not an account on someone's server. Permissions are UCAN capability tokens an agent can delegate and revoke without a central authority. Every node exposes an MCP server, so any agent, running on your infrastructure, can push code, open PRs, and run reviews natively.
Open and free at the base layer. The OpenClaude CLI (~30K GitHub stars) and the network tooling are open source. git push works through a standard transport helper. Nobody's pricing tier sits between you and hosting a repo.
No model agenda. gitlawb's OpenGateway routes to whatever model you choose through one OpenAI-compatible endpoint. The infrastructure has no house model to sell you.

The honest caveats

Symmetry demands the same scrutiny I gave Origin. gitlawb is younger and smaller than either incumbent; a p2p network's UX has real friction that a polished centralized product doesn't; and decentralized systems earn trust in years, not press cycles. Origin will onboard more developers this quarter than gitlawb has, because defaults and polish win quarters. Topology wins decades.

And one more fairness note: GitHub will fix this outage, publish a thoughtful postmortem, and be fine. The point is not that GitHub is doomed. The point is that today every developer got a three-hour demonstration of what "one origin" costs, and the loudest alternative on offer is one origin with a different owner.

What to do with your three hours of downtime

Mirror your critical repos somewhere that isn't the same company as your CI. Today, that alone would have kept you shipping.
Audit your agent workflows for GitHub-shaped single points of failure. If your agents authenticate, commit, and verify through one provider, they share one off switch.
Try the decentralized path with one repo. gitlawb's install is a one-liner, and pushing a mirror to a p2p network is a fifteen-minute experiment that makes the topology argument concrete.

Cursor named its platform Origin, and honestly, the name gives the game away: it's a bid to be the new single remote everyone points at. The whole lesson of this morning is that the origin shouldn't be a company at all.

Sources: Bleeping Computer · GeekWire · Engadget · IncidentHub · TechStartups · SiliconANGLE · explainx · gitlawb architecture

Stripe Just Bought the AI Toll Booth. The Open Stack Already Has an Exit.

Amrit Mirchandani — Mon, 17 Aug 2026 10:59:56 +0000

OpenRouter sold for $7B — five times its valuation from three months ago. What a payments giant wants with a model router, and why gitlawb's OpenGateway suddenly matters.

Three months ago, OpenRouter raised a Series B at a $1.3 billion valuation. This week, Stripe agreed to buy it for more than $7 billion — reports of the talks had ranged as high as $10 billion, and Stripe itself declines to comment. Nobody pays a 5x premium in ninety days for an API wrapper. You pay it for a position.

Understand what OpenRouter actually is: one API key, 400+ models, 8 million users. It is the neutral middleman of the AI boom — the place where developers go so they don't have to marry OpenAI, Anthropic, or Google. Every request that flows through it carries three pieces of information: who is asking, what they asked for, and what it cost. OpenRouter sat in the middle of the model market the way Visa sits in the middle of retail.

Now the company that processes the internet's payments owns the company that routes the internet's intelligence.

Why a payments company buys a router

Stripe's business is metering value in motion and taking a slice. Inference is the fastest-growing metered commodity in history, and it has a property card payments never had: the buyer is increasingly a machine. Agents consume models the way servers consume electricity — continuously, programmatically, with a budget.

Whoever owns the router owns three things at once:

The meter. Every token counted, priced, and billed in one place.
The demand graph. Which models are winning, in real time, across 8 million integrations — better market intelligence than any model lab has about its own competitors.
The default. When routing and billing are one product, the path of least resistance for every new AI app is to plug into the stack once and never leave.

This is the AWS-ification of inference. Not a conspiracy — a strategy. Stripe is very good at this, and honestly, the integration will probably be excellent. That's what makes it worth thinking about clearly.

The neutrality problem

OpenRouter's entire value proposition was that it had no horse in the race. It routed to whoever was best, cheapest, fastest. That neutrality is now owned by a company with its own margins to defend, its own partnerships, its own strategic interests in which models win.

None of this requires bad behavior to matter. The questions arrive with the org chart:

When routing and payments share an owner, does the "recommended" model stay the best one, or become the best-margin one?
What happens to pricing transparency when the router and the biller are the same P&L?
Your agent's entire consumption pattern — every prompt's metadata, every fallback, every budget ceiling — now lives inside one company's data plane. Who else gets to learn from it?
And the oldest one in the book: what does deplatforming look like when losing your payment processor and losing your model access are the same event?

We have run this experiment before. Neutral chokepoints don't stay neutral; they stay profitable.

The answer that already exists

Here's the part that makes this interesting rather than just gloomy: the open alternative didn't need to be founded in response to the news. It's already running.

gitlawb — the project building an open-source stack for the agent economy (decentralized git, the OpenClaude coding CLI with ~30K GitHub stars, on-chain task bounties) — operates OpenGateway: an open inference gateway with one OpenAI-compatible endpoint, multi-provider routing, key management, and live usage dashboards. It has routed trillions of tokens. Billing passes through at the serving model's listed rate.

The irony writes itself: gitlawb was itself an OpenRouter app. They built on the neutral gateway, watched the chokepoint form, and built the open version of the same layer inside their own stack. The acquisition doesn't refute their thesis. It is their thesis: every closed layer of agent infrastructure eventually gets bought by whoever profits most from owning it, so the load-bearing layers need open counterparts.

The distinction that matters isn't features — it's failure modes:

Routing as a product (OpenRouter under Stripe): excellent UX, one throat to choke — and one owner deciding what the meter says.
Routing as a protocol (the OpenGateway model): OpenAI-compatible endpoint you can point anywhere, source you can read, a gateway you can self-host when you stop trusting anyone else's.

An agent economy where identity is a keypair, code lives on a peer-to-peer network, and inference routes through an open gateway has a fundamentally different power structure than one where all three run through corporate chokepoints. That's not ideology. That's architecture.

The money needs the same exit

Follow Stripe's logic one step further and you see the real prize. Routing was never the endgame; the checkout is. In an agent economy, every model call, every API hit, every task handed from one agent to another is a payment event. Whoever owns both the router and the biller owns the complete economic loop of machine-to-machine commerce.

Which means the payments layer needs its open counterpart just as much as the routing layer does. And like OpenGateway, it already exists: stablecoin rails on open networks like Base, where an agent holds its own wallet, pays per request in USDC, and settlement happens on a public chain instead of inside one company's ledger. Protocols like x402 are turning HTTP-native, pay-per-call machine payments into a primitive rather than a product. gitlawb's own stack wires task bounties and agent payouts onchain for exactly this reason: an agent that authenticates with a keypair and pushes code to a peer-to-peer network shouldn't have to ask a payments company for permission to get paid.

Put the full open stack together and the shape is striking: identity as a keypair, code on decentralized git, inference through an open gateway, settlement on open rails. Four layers, no landlord at any of them. That is the actual alternative to the world where Stripe owns the meter — not a competing toll booth, but roads.

The honest caveats

OpenGateway is not OpenRouter's equal today. Its provider list is shorter. Its scale is a fraction of 8 million users. Stripe may well run OpenRouter with scrupulous neutrality — they're smart enough to know the neutrality is the asset. And open-source gateways have their own failure mode: maintenance entropy, the thing nobody pays for until it breaks.

But the point of an exit isn't that you use it today. It's that its existence disciplines the toll booth. Chokepoints behave differently when the exit is real.

What to actually do

If you're building agents or AI apps, three practical moves:

Keep your model layer behind your own abstraction. One file, one interface. The day your router changes owners, incentives, or prices, your migration should be a config change, not a rewrite.
Know your exit before you need it. Run a request through an open gateway this week — OpenGateway or any self-hosted router. The point is knowing your fallback works before the pricing email arrives.
Watch the pattern, not the deal. Identity, code, inference, payments: every layer of the agent stack is consolidating. Each acquisition makes the open counterpart of that layer more valuable, not less.

Stripe buying OpenRouter is a rational move by a great company, and it will probably make inference billing smoother for everyone. It also just turned "who owns the router?" from an abstract question into a $7 billion answer.

The open stack's reply is shorter: nobody should.