Friday: a self-hosted control plane that routes agent steps across vendors and demands receipts

The failure Friday is aimed at: agents that grade their own homework

The README opens with a blunt diagnosis. Coding agents, it says, will cheerfully cut corners or claim they finished something they did not. The project's answer is not a better prompt. It is a refusal to accept a model's word for anything. Friday treats the sentence I am done as an unverified claim, and the leg of its loop that most tools skip is verify. A task cannot flip to complete unless a proof receipt is attached through what the README calls Friday's persisted mission and work-item code boundary. The database stores those references, and the application boundary rejects completion that arrives without one. That is a structural constraint, not a guideline an agent can talk its way around.

The intended user is someone already paying for several cloud models and already running agents against real repositories or real systems. The pain Friday addresses is not model quality. It is the supervision overhead: watching an agent, re-prompting it, checking whether it actually did the thing, and deciding what comes next. Friday positions itself as the loop that does that prompting on your behalf, on your machine, with your keys. Anyone running a single agent inside a single vendor's IDE is not the audience here, because the cross-vendor referee role is the entire point.

Route, execute, verify, remember: the four stages and where the brakes are

The README publishes the loop as a diagram. Your goal enters at the top. A route step picks an AI for that step, and you can re-route it. An execute step runs the work, and risky steps pause for your approval. A verify step has to prove the work is really done. A remember step turns observations into candidates, which you confirm before they become memory. Then the loop picks the next thing.

Two design choices inside that loop deserve attention. The first is routing economics. Friday runs Codex, Claude and DeepSeek like a metered crew, in the README's phrasing: cheap models do planning and thinking, expensive ones do heavy lifting. The README also claims the router makes a zero-token decision before spending anything, and that if it falls back to a backup model, the billing record names the model that actually answered. That last part matters more than it sounds. Silent model substitution is a common source of confusing invoices, and Friday's stated position is that the receipt must name the real worker.

The second choice is the approval boundary. Read-only operations never need sign-off. Anything that changes the world, or that the kernel judges risky, can only resolve to needs your OK or nope. It cannot resolve to sure, go ahead. The README's phrasing for this is that Friday was never given a pen: it holds the key that checks your signature, never the one that writes it, so the sign-off has to come from your own hand, offline, on your own device. Whether that holds up in the code is the first thing a careful adopter should check, because it is the claim the whole governance story rests on.

Getting it running: source only, Node 22, and a setup script

There is no published installer and no container image mentioned in the README. The documented path is a clone and a setup script, and it requires Node.js 22 or newer. On macOS with Homebrew the README gives this sequence:

brew install node@22 git clone https://github.com/thesongzhu/Friday.git cd Friday open "Friday Setup.command"

If the setup script reports an older or missing Node.js, the README says to install Node 22 or newer and run Friday Setup.command again. The npm package is published as @thesongzhu/friday, according to the badge in the README, though the quickstart itself describes running from source rather than from the registry. There is a CI workflow at .github/workflows/ci.yml, and the README carries a badge labelled public v1 local candidate, which is a fair description of the release state: v1.0.0 landed in April 2026, with v1.0.1 and v1.0.2 following in late May 2026.

Beyond the Node version and the setup entry point, the README does not document configuration keys, environment variables, or the shape of the BYOK credential file. That is a real gap for anyone evaluating deployment. You will be reading the repository to find out where keys go and what the kernel reads at startup.

Receipts, candidate memories, and a hash-chained audit log

Three mechanisms carry most of the governance weight, and they are worth separating because they fail differently.

The first is receipt-backed completion. A task cannot close without a proof receipt attached through the mission and work-item boundary. The README states plainly that a model saying ok, or a process that quietly exits, does not count on its own. This is the strongest claim in the document, and it is also the one most dependent on implementation detail. A receipt is only as good as what counts as evidence, and the README does not specify what a receipt contains or who is permitted to produce one.

The second is candidate memory. Facts surfaced during a run become candidates, and none of them graduate to real memory until you confirm. The stated consequence is that a poisoned fact just sits there, harmless. Recall is also scoped to your own data and scrubbed of known secret patterns before any model sees it. The scrubbing phrase is known secret patterns, which implies a pattern list rather than a guarantee, and the README does not say how that list is maintained.

The third is the audit log. Every routed agent turn lands as one all-or-nothing entry recording who, what and how much, in a hash-chained log, so editing the past snaps the chain. Hash chaining gives tamper evidence, not tamper prevention. Someone with write access to the log file can still alter it; what they cannot do is alter it and leave the chain intact. That distinction is worth holding onto when you decide how much the log is worth to you.

Where Friday is the wrong tool

Friday adds a kernel between you and every model call. That is the product, and it is also the cost. If your work is a single agent in a single vendor's environment, with no cross-vendor routing and no compliance requirement for an audit trail, the kernel is pure overhead: an extra process to run, an extra configuration surface to maintain, and a loop that will pause for approval on steps you would have waved through anyway.

The approval-first design also imposes latency by construction. Risky steps wait for a human. The README does not describe a policy engine that can pre-authorise classes of action, only the statement that read-only work passes through and everything else lands on needs your OK or nope. For interactive work that is fine. For anything meant to run unattended overnight, it is a hard stop, and the README does not present an unattended mode.

The release state is the other limitation. The badge calls this a public v1 local candidate. Setup is a shell script opened from Finder on macOS, with no documented Linux or Windows path in the material available. There is no stated plugin API, no documented extension point for adding a model vendor beyond the three named, and no published roadmap. The README ends mid-sentence in the section describing the shape the project is growing into, which is a reasonable signal of how much of the vision is still prose.

How this differs from a single-vendor agent harness

The obvious comparison is a vendor's own agent tool, such as Codex or Claude Code. Both give you a capable agent, a permission prompt, and a session. Neither referees the other, and in both cases the controls sit on the vendor's side of the connection. Friday's argument is that a neutral layer running on your hardware, holding your keys and your memory, is a seam no single vendor has an incentive to fill.

The difference is concrete rather than philosophical. In a vendor harness, the model vendor decides what counts as a completed action and how the transcript is retained. In Friday, completion is gated by a receipt checked at an application boundary you can read, memory graduates only on your confirmation, and the audit log is a local hash chain. You can inspect all three without asking anyone for an export.

That neutrality has a price the vendor tools do not charge. You supply and rotate the API keys. You run the Node process. You own the upgrade path when a model vendor changes an endpoint. Friday's value is concentrated in the harness around the models, and the README says so directly: the model is rented, not married. If you are not prepared to maintain the harness, the neutrality buys you nothing.

Licence, maintenance burden, and what to verify before you commit

Friday is MIT licensed. That is permissive: you can use, modify and redistribute it, including in commercial settings, provided the copyright notice and permission notice are preserved. It also means there is no warranty and no support obligation from the author. This is a description of the licence text, not legal advice; if you plan to redistribute a modified Friday or ship it inside a product, have counsel read the MIT terms alongside your own dependency obligations.

The maintenance cost is the part the README understates. You are running a local service that brokers calls to at least three model vendors, so you inherit three sets of API changes, three sets of pricing changes, and the routing logic that maps work onto them. The npm package @thesongzhu/friday exists, but the documented install is a git clone, which means upgrades are a pull and a re-run of the setup script rather than a package manager command. There is no documented migration path for the persisted mission, work-item, memory or audit data between versions.

Three things are worth verifying in the source before you trust the governance claims. First, find the code that enforces receipt-backed completion at the application boundary and confirm it rejects receipt-free transitions rather than merely logging them. Second, trace the approval path and confirm the signing key genuinely lives outside the kernel's reach, since the README's claim that Friday was never given a pen is the load-bearing statement. Third, check what a proof receipt actually contains, because a receipt that any agent turn can mint is a receipt in name only.

Editorial conclusion

Adopt Friday if you already hold API keys for two or more model vendors, you are comfortable running a Node 22 service on your own hardware, and the failure you are trying to prevent is an agent claiming success it cannot prove. Do not adopt it if you need a supported installer, a stable plugin API, or a documented path for running this on a team server; the README describes a local candidate with a source-only install and no published roadmap. Before committing, read the persisted mission and work-item code that enforces receipt-backed completion, and confirm that the approval path really does require a signature your own device holds rather than a flag the kernel can set for itself.

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. thesongzhu/Friday on GitHub