FridaiOS: an operating layer for AI-native work

Role
Sole architect and engineer. Self-directed. It is both how I work and the methodology Fridai sells.
Scope
Knowledge layer, skills registry, workflow dispatcher, model router, cost ledger, six standing workbenches, scheduled agents, and a packaged installer for other people.
Stack
Markdown on a plain filesystem · Python · Claude Code and Codex in VS Code · MCP · Ollama Cloud and OpenRouter free tiers · systemd
Status
Running my daily work since April 2026. The packaged product is feature-complete and unreleased.

Software engineering absorbed AI first, and proximity to the labs is only half of why. Engineering work was already the right shape for it: documented, versioned, decomposed into units with tests that say whether the unit is right. Everyone else's work is not that shape. The tools reach them all the same, and what arrives is more information moving faster, which is a harder problem than the one the tools solve. Capability stopped being the scarce input. Organisation became it.

FridaiOS is what I built to close that gap for myself first: a plain-text knowledge base agents read from and write back to, a registry of portable skills, staged workflows that stop at human gates, and a model router that runs the routine work on free tiers. Nothing lives inside a vendor's product, so it survives model churn, surface churn and price changes. I run every working day through it, which is why the pieces have been exercised against real work rather than a demo.

1. The thesis

Engineers had a head start that was structural, not cultural. Their tools arrived first, but the deeper advantage is that their domain is tidy. Code is written down, versioned and reviewed; a repository is a source of truth; a test is a verdict. An LLM dropped into that environment has something to read, something to change, and something that tells it whether the change worked. Most professional work offers none of those, so the same model produces confident output nobody can check against anything.

Natural language lowered the entry cost and raised the mess. Anyone can now instruct a machine in their own words, but the machine still needs a working context, and in knowledge work nobody has one lying around. The path for a lawyer, a researcher or an operations lead is not the engineer's path with a friendlier prompt. It starts with writing down what is currently held in people's heads.

So the work is structure, synthesis and synchronisation. Record information in a form something else can read. Link it so related things find each other. Synthesise it into positions that still hold six months later, and keep those in sync as the material underneath them changes. It is unglamorous next to the demos, and it decides whether an AI rollout compounds or leaves a pile of abandoned chats.

The last piece is deciding what stays human. A system like this is only worth building if it names what makes a person's judgment valuable and puts that at the gates rather than inside the automation. Every workflow here stops and asks before committing to anything expensive to reverse. That is a position about where expertise belongs, not a limitation I have not got around to removing.

2. Durable and modular, because the price of AI is not settled

The subsidy is the elephant in the room. Frontier labs are selling subscription access well below what heavy use costs them, and that will not hold. Building a working life on one vendor's pricing is an unhedged position on a market that has not found its level, and it is not a hypothetical: in June 2026 the major coding surfaces moved unattended and scheduled runs off subscription onto metered API rates, repricing every background job overnight.

So the substrate is plain files. Memory, skills, workflow contracts and configuration are markdown and Python on an ordinary filesystem. There is no proprietary store to migrate out of and no export to negotiate. When a better model appears, the apparatus points at it. The same knowledge base and skills drive both Claude Code and Codex, running side by side in VS Code, because both read the same files through their own tether documents.

And the routine work runs on free tiers by rule. Every autonomous workflow declares its model chain in frontmatter, and the standing rule is that no autonomous stage may call a paid model: the chain is Ollama Cloud, then the OpenRouter free tier, with no paid fallback. When the whole chain is exhausted the run writes a retry payload and exits loudly rather than quietly escalating to something billable; the next scheduled event picks it up. Every call lands in an append-only token ledger, so the cost of the system is a number I can read rather than estimate.

3. How the pieces fit

Four nouns, three verbs. The model is deliberately small enough to hold in one head: Memory is what the system knows and is referenced, never worked in; Skills are portable verbs invoked from anywhere; Workbenches are standing apparatus for a recurring kind of task, worn like a hat; and Projects are bounded jobs that compose workbenches. Every session reads from Memory, calls Skills, and writes conclusions back at boundaries. That last verb is what makes the system compound instead of restarting at zero each chat.

The engineering underneath is the ordinary kind. Each component exists because something broke without it:

Six workbenches sit on top of that: front desk (the default hat, which triages and routes), content, research, dev, vault tech, and the site-demo bench that produces client demos. Each is a documented mode composing the same skills differently, and one of them is how the website-to-demo pipeline runs.

4. It runs on its own

The system does not wait to be prompted. Scheduled routines fire on cron, a file watcher running as a systemd service ingests whatever lands in the inbox, and long jobs self-pace, polling external state and resuming when it changes. Output feeds back into input: transcripts are harvested for decisions and lessons, staged behind a review gate, and written into the wiki, so the next run starts from what the last one learned. It maintains itself too, pruning stale knowledge and updating its own skills when a correction recurs.

5. What it lets a non-traditional engineer do

The gap between what an engineer can build and what a determined outsider can build is closing, and its failure mode is well known. Code that looks right, was never checked against the documentation, and falls over the first time reality differs from the model's recall. My background is data and IT training plus eight years of consultative sales, so I built the checks into the workflow rather than lean on instincts I have not had time to earn.

Two research benches do that work. A deep-research workflow takes a question through source discovery, scraping to disk, notebook interrogation and synthesis, gated by a human at framing and at curation. A sanity-check workflow pulls the load-bearing assumptions out of a plan and tests each against canonical vendor docs and real-world failure reports before any code is written. On the packaged build it caught an authorisation header leaking across an HTTP redirect while the design was still a document.

This is also my answer when a role names a platform I have not used. I learned on the fly through a paid engagement once, then built the apparatus so the next unfamiliar stack is a solved problem rather than something to survive twice. The claim is rate of acquisition, and the evidence is that the systems on this site were built in unfamiliar territory using it.

6. Packaged for other people

The hardest part of this for anyone else is the setup, so I productised it. The packaged build installs the same architecture through a conversation rather than a manual: a stdlib kernel with atomic writes and a read-only conformance check that reports problems instead of silently repairing them, an installer that detects which agent surface is in use and registers the suite for it, a short guided interview that produces the user's own context file, and the same free-tier autonomy layer wired to each OS's native per-user scheduler. It ships as a local bundle of auditable scripts rather than a piped remote installer, which matters given how agent-skill supply-chain attacks now work.

It is feature-complete and not yet released: 166 tests green, seven subsystems built to a locked spec. The reason it exists is the thesis in section 1. Structure is the unlock for everyone who is not an engineer, and setup friction is what stops people getting it.

7. Is this really orchestration?

A fair challenge is whether a skills-and-hooks harness is doing different work from a graph framework like LangGraph, or whether the two are the same architecture in different clothes. I mapped it concept for concept: the LangGraph equivalence brief. Stages are nodes, the run-state file is graph state, paused is an interrupt checkpoint, skills are tools.

Claude Code has been my daily driver since early 2026, with Codex alongside it over the same files, both in VS Code. Every page on this site was built that way. For the underlying engineering, read the code: