Short answer: no, neither. My setup is considerably more boring than that, and I think that is exactly why it keeps running for years instead of until the next major version of a framework.

Three moving parts

Everything I have running in the background comes down to three independent pieces.

The agent is a long-lived process on one of my local machines or servers. It does not monitor anything on its own — it knows how to accept a task and carry it out with its tools. Which agent barely matters here: Claude Code in headless mode, Hermes, your own loop over the API, something else entirely. For this scenario any of them will do.

The triggers are ordinary scripts and scheduled jobs. One watches a folder and fires when a new file appears; another polls a site or an API on a schedule and compares the response against the last one it saw. Nothing about this is AI-specific — it is cron and file watchers, tools that have been around for decades.

The handoff is what happens when a trigger catches something: it sends the agent a task describing what happened and what to work on. From there the agent decides which of its tools to use. You can build the handoff any number of ways — a file dropped into a queue directory, a CLI call with a prompt, an HTTP request — and the choice comes down to what is convenient for you and what kind of system you are building.

The property that makes this work: intelligence is only needed in the third part. Noticing that a file appeared, or that a page changed, is a job Unix solves without spending a single token. Paying for LLM calls — or burning local GPU cycles — so that the agent can poll the world itself is the most expensive way ever devised to write while true; do sleep 60; done.

What it looks like in practice

The skeleton of a folder trigger is a few lines:

#!/usr/bin/env bash
# Watch the inbox folder, hand each new file to the agent
fswatch -0 --event Created ~/agent-inbox | while read -d '' file; do
  send-task "New file dropped: $file. Process it."
done

Bash is not the point — the shape is. The same trigger in Python, when you want more structure and somewhere to put error handling:

#!/usr/bin/env python3
"""Watch the inbox folder, hand each new file to the agent."""
import time
from pathlib import Path

INBOX = Path.home() / "agent-inbox"

def main():
    seen = set(INBOX.iterdir())
    while True:
        current = set(INBOX.iterdir())
        for path in current - seen:
            send_task(f"New file dropped: {path}. Process it.")
        seen = current
        time.sleep(5)

if __name__ == "__main__":
    main()

Watching a website is a cron line plus a comparison against the last snapshot:

*/15 * * * * check-page.py https://example.com/releases

#!/usr/bin/env python3
"""Poll a URL, notify the agent when it changes. Run from cron."""
import hashlib
import sys
import urllib.request
from pathlib import Path

STATE = Path("/tmp/page.hash")

def main(url):
    body = urllib.request.urlopen(url, timeout=30).read()
    new = hashlib.sha256(body).hexdigest()
    old = STATE.read_text().strip() if STATE.exists() else None
    if new != old:
        STATE.write_text(new)
        send_task(f"Page {url} changed. Check what's new and summarize.")

if __name__ == "__main__":
    main(sys.argv[1])

Either language gives you the same three parts, and neither version contains a single AI-specific line. Python mostly buys you a comfortable place for the logic to grow into: retries, HTML parsing when hashing the whole page turns out to be too blunt, a filter deciding which changes are even worth an agent's time.

send-task / send_task stands in for the handoff. The point of keeping it a separate thing is that every piece can then be exercised on its own: run the trigger by hand and see what it catches, feed the agent a task directly and see what it does. When something breaks at three in the morning, there are only three places it can be.

Why not LangGraph or LangChain

I hold no ideological position that frameworks are evil. They simply solve a different problem than the one being asked about.

LangGraph and LangChain are about orchestration inside the agent process: graphs of steps, branching, state carried between nodes. "Run an agent in the background and react to events" is a question about the infrastructure around the agent — and for that the operating system already ships everything required: cron, systemd, file watchers, pipes. Those tools are older than most readers of this note, they do not get breaking changes every quarter, and their behavior does not depend on the version of a Python package.

Pulling in a framework to watch a folder means inserting a layer of dependencies between the event and the agent that adds nothing except surface area for failure. If one of my background jobs ever needs a genuine multi-step graph with branching and rollbacks, I will revisit the choice. So far none of them has.

A background agent is an unsupervised agent

One consequence goes past the original question, but leaving it out would be dishonest: an agent running in the background is by definition an agent nobody is watching. There is no "I'll look at the diff before it applies" — the event arrived at night and the agent worked at night.

Which puts the full weight on the principle I wrote about in the note on Auto Mode: boundaries have to be mechanical, not statistical. A background agent of mine gets exactly the access its class of tasks requires — its own folder, its own restricted credentials, and no direct path to anything I cannot afford to lose. That isolation can be a separate system user or a container, or you can move the whole thing onto a separate machine.

It is the same approach as in my work with coding agents: trust is configured by architecture — by what the agent can physically reach — not by a confirmation dialog.

The bottom line

The answer to the original question fits on one line: a long-lived process plus ordinary trigger scripts, zero frameworks. The event-driven half is a problem Unix solved decades ago, and intelligence is only needed once the event has been caught and has to be dealt with. The part of a background agent that genuinely deserves attention is not orchestration but boundaries — with no human in the loop, they have to be mechanical.

How I divide work with agents in general, and what I run them on, is on the AI page.

The change has sparked a heated debate, and a lot of the reaction is negative. As I see it, the whole argument boils down to one question: are we ready to trust an agent with the terminal. But I think that framing is wrong. We already trust it. What changed is not the level of trust — it is who is accountable for it.

The numbers that explain everything

The most interesting part of the announcement is not the feature but the data Anthropic uses to justify it. According to the research being discussed, the classifier blocked about 89% of dangerous actions. Humans approving manually blocked 13.6%. And that is not even the worst case: as requests pile up, human approval degrades further due to approval fatigue.

Anthropic has long pointed to exactly this as the problem with the perpetual "Allow": in practice, users approve about 93% of requests almost automatically. A confirmation dialog you click through nine times out of ten without looking is not control. It is a ritual of control. It creates the feeling of safety without creating safety — while faithfully eating the agent's main advantage: the ability to work while you are busy with something else.

Accept those numbers and the conclusion is uncomfortable but direct: replacing the human approver with a classifier is not lowering the security bar. It is raising it. From 13.6% to 89%.

What this actually means

Formally, nothing revolutionary happened. Coding agents have been running autonomously for a long time — simply because users have been mass-enabling the equivalents of --dangerously-skip-permissions. A flag with a self-explanatory name that people turn on because working any other way is impossible.

The real difference is the shift in responsibility. It is one thing to have "a dangerous flag you enabled at your own risk," and quite another to have a default, first-class UX the vendor stakes its name on. Until now, autonomy was effectively the user's fault; now it becomes Anthropic's position.

To me this event matters more than another bump on SWE-bench. Benchmarks measure how well an agent writes code. What is changing here is the working model itself: coding agents are moving along the path "assistant → supervised agent → semi-autonomous worker," and Auto Mode by default is an official acknowledgment that the industry is already on the third step. Not "the model got smarter" but "the model is now expected to work unsupervised."

I see nothing frightening in this logic — my work with agents was never built on the "Allow" button in the first place, but on boundaries written into the project itself: a spec the code can cite, rules that record expensive mistakes, tests on the critical spots, and diff review. The confirmation button was never a real line of defense in that setup — the 93% figure merely confirms what everyone who works with agents knows from experience.

A classifier is not a sandbox

That said, it is important to call things by their names: a classifier is not a sandbox and not a formal security guarantee. It is a probabilistic model that catches 89% of dangerous actions. The remaining 11% have not gone anywhere — and prompt injection as a class of attacks is specifically designed to hunt for exactly those gaps.

The difference is fundamental. A sandbox is a boundary defined by a mechanism: whatever the agent decides, it physically cannot get outside the container, the VM, or the restricted user. A classifier is a boundary defined by a prediction: a dangerous action will most likely be stopped. "Most likely" is not the level of guarantee you build on when production credentials and other people's data are involved.

So for serious work my position does not change: an isolated environment remains the last line of defense. The classifier is a good middle line — it catches the vast majority of problems cheaply and without friction. But the last line has to be mechanical, not statistical: a separate environment, restricted credentials, no direct access to anything you cannot afford to lose.

The bottom line

Auto Mode by default is the right move, backed by honest and uncomfortable data: a human with an "Allow" button protects worse than a classifier, and everyone has known it for a long time. But the right move does not cancel the main rule of working with autonomous agents: trust is configured not by a confirmation dialog and not by a classifier, but by architecture — by what the agent can physically reach. Anthropic removed the ritual. The real boundaries are still on us.

A reaction that size makes sense. GitHub stopped being just code hosting a long time ago: it is also the CI, the release process, the public face of a project, and often the project's website. When one company holds all four roles, any outage of theirs turns straight into a conversation about vendor lock-in.

I find that interesting from a practical angle. I have mirrored my repositories for years and assumed I was covered. An outage is a good excuse to check whether that is true.

What I actually have

Every one of my projects lives on three hosts at once: my own Gitea on my server, GitLab, and GitHub. Texodus has four — the fourth is a Raspberry Pi in the next room.

$ git remote -v
server   ssh://git@git.blokhin.us/nick/Texodus.git
gitlab   git@gitlab.com:w512/texodus.git
origin   git@github.com:w512/Texodus.git
rpi5     ssh://git@rpi5-local/nick/Texodus.git

This costs essentially nothing: git remote add once, plus the habit of pushing to all of them. If GitHub disappeared tomorrow along with my account, the commit history would not be affected.

It sounds like a finished answer to "what if". It is an answer to the wrong question.

The code is safe and I still cannot ship

Users do not download a repository. They download a built .dmg, .AppImage, or installer — and those are produced by GitHub Actions.

In my case that is not simply "run the build somewhere else". The Texodus release pipeline contains a non-obvious step: after the AppImage is packaged, the build machine's graphics libraries are stripped out of it, because otherwise the app does not start on recent distributions. That fix exists only inside the workflow file. Building the project locally "the usual way" would hand me an artifact with the old bug back in it — and I would not notice immediately.

That is the real single point of failure. Mirrors protect the history of the code. They do nothing at all for the ability to release and deliver an update.

There is a partial exception. macOS builds already run locally, from a separate script, because Developer ID signing and notarization need a certificate from the local keychain. So one of my three release paths does not depend on GitHub — but for an entirely unrelated reason. That is luck, not planning.

What follows from this

Leaving GitHub entirely is not rational: the audience is there, the issues are there, discovery is there. The question is not how to quit, but how to make an outage mean a delay rather than a standstill. The minimum set looks like this:

• A repository mirror. The cheapest item and, judging by my own case, the most overrated: it takes a minute to set up and covers only part of the problem.
• The ability to run CI locally. Not "in principle possible" — actually verified: the pipeline runs on your own machine and produces the same artifact.
• Artifact export. Releases that exist only as GitHub Releases are unavailable to your users exactly when the platform is unavailable.
• A written emergency release procedure. One document: what to run, where the keys are, where to publish, when the normal path is closed.

The last one I wrote down for myself: I do not have it. Until an outage actually happens, "I roughly remember how this gets built" feels like enough — and that feeling is precisely the dependency nobody closes.

The boring counterexample

The site you are reading did not notice the outage at all. It is built as static files on my laptop and published to my own nginx; GitHub is involved in its life only as one of three code mirrors. Neither Actions nor Pages sits anywhere between the source and the reader.

That is not foresight — it is just the kind of site I find comfortable to run. But the coincidence is instructive: the fewer moving parts belonging to someone else stand between your code and your user, the fewer questions someone else's outage raises.

Across numerous tests, Kimi K3 is already approaching the best closed models from OpenAI and Anthropic in coding and tool-use tasks. What matters most is that, for the first time, an open-weight model shows a comparable level on the kinds of tasks typical for AI agents.

The infrastructure around such models is developing at the same time. vLLM added support for Kimi K3 on release day, including recommendations for running the enormous MoE model with a context of up to 1M tokens. DigitalOcean added K3 to its Inference Engine almost immediately, making it possible to use the model as a managed API without having to stand up complex infrastructure yourself.

NVIDIA also used the moment to publicly back the open-weight approach, calling it an important part of US leadership in AI, and took part in founding the Open Secure AI Alliance, which is meant to address the security of open models.

That is why, in my view, the significance of Kimi K3 lies not so much in its benchmark results as in the fact that the boundary between self-hosted and cloud models is starting to disappear. A developer can get the control of an open model while still using convenient managed infrastructure. The choice between local deployment and an API is gradually turning from a standalone infrastructure project into practically a matter of configuration.

The question I get asked most often is not which tool I use. It is what this looks like over the long run. Here is the answer.

Architect: the spec that is not in the prompt

The public spec is forty-four lines with no section numbers anywhere. Yet the Texodus sources still carry references like these:

// ── Window close confirmation (§4.4) + Tauri drag-drop (§4.1) ──
/* Implements the 3-button flow required by spec §4.4 (Save / Don't Save / Cancel) */
// Debounce rendering (§6.2)

They point at a detailed, numbered specification — it runs to §12.8 — that I wrote myself, using that public prompt as the starting point. This is probably the clearest answer to what the human actually does here: not "ask for a Markdown editor", but turn a page of requirements into a document the code can cite and that you can later check implementation against, line by line.

Those markers are still in the sources four major versions later, and a rule in the agent instructions requires keeping them: "§N.N comments reference the original product spec — keep them intact". A §4.4 next to the unsaved-changes dialog is not decoration. It is an address: it takes a second to find how the behavior was meant to work, instead of reconstructing the intent from the code.

The boundary follows the cost of a mistake

The agent does not get the same freedom everywhere in the codebase. The line is drawn not by type of task but by what an error costs. The Texodus rules mark it in plain text:

services/markdownSanitizer.ts — single source of marked options + the DOMPurify whitelist, shared by live preview and export so sanitization can't drift. A regression here = XSS.

The cold-start race (macOS Opened fires before main exists) is handled in main_window_is_empty — read its comments before touching.

Where a mistake is cheap — layout, refactoring, routine changes — the agent works on its own. Where it is expensive — the sanitizer, cryptography, saving files — the freedom ends.

The rules file is an archive of mistakes already made

The most useful thing I have learned from all of this: agent instructions consist almost entirely of prohibitions, and every prohibition is the trace of something that once broke. Not an abstract style guide — a list of expensive lessons written in the imperative.

From Kivarion, my password manager:

onDragOver must decide with isEntryDrag, never with getData: the drag data store is in protected mode for the whole drag, so getData returns '' there — which is exactly how entry→group drag came to be silently dead.

Do not move it back into the webview, and do not reintroduce argon2-browser.

The second rule comes with a full paragraph of reasoning: the WASM call is synchronous no matter what the promise looks like, and kdbxweb re-derives the key on every save — so the interface froze for the length of the KDF on every auto-save.

From Texodus:

AppState.pending_files is a queue per window label — several "Open With" files can target one window before the frontend drains; don't collapse it back to a single slot.

Every one of these lines was written after something went wrong. Their value is that they stop anyone from returning to the "simpler" solution that already turned out to be the wrong one — the agent, and me six months later.

Reviewer: I look at everything, I read selectively

I go through every diff. But I do not read all of it closely — only the parts that touch critical and important code. That is the only honest way to work at the speed agents give you: reading every line would eat the entire gain, and reading nothing means eventually shipping a regression in the sanitizer.

So the other half of review is automated. The rules contain a one-line gate:

Run typecheck + test + lint before declaring frontend work done.

Work is not done until those three commands pass. The tests cover exactly the dangerous places — the sanitizer is tested for stripping XSS, and the rules even record why the test environment is jsdom rather than happy-dom: happy-dom's parser mishandles siblings after a <script>, which would have made the test useless.

This is a system, not one project's setup

CLAUDE.md lives in many of my repositories. In Texodus and Kivarion an AGENTS.md sits next to it — I work with two agents in parallel, and each one needs its own file carrying the same knowledge about the project. Those files never reach the public repositories: they are in .gitignore and stay local.

Rules pay off best where things break quietly. For example, the CLAUDE.md for this site records that routes are linked by name, so renaming one silently breaks both the links and the active-menu highlight, and that the sitemap generator parses the routes file with a regex — which is why the one-line route format must not be touched. Neither tests nor reading a diff catches that.

Where it breaks: the line between JS and Rust

The most expensive problem I have hit was not code quality. It was that the agent has no memory between sessions.

In a Tauri app, almost every task has two places it could be solved: the JavaScript frontend or the Rust backend. The agent kept getting this wrong — and it decided differently in different sessions and different tasks. Not because the choices were bad: each individual one was defensible. The problem is that every new session starts from zero, so any decision not written down in the project gets made again, differently. Architecture does not drift because of one big mistake. It drifts because of a dozen small ones, each perfectly reasonable on its own.

There is exactly one cure: draw the boundary explicitly, in writing. In Texodus the rules list all five Rust commands and state what belongs to the backend and what to the frontend. In Kivarion the line is drawn harder, with the price attached:

KDBX 4's KDF runs in the backend, not the webview. […] Do not move it back into the webview.

The frontend has no direct filesystem access; saveDatabase serializes the db and calls the Rust save_database command.

Which closes the loop on the archive of mistakes: the rules I quoted earlier exist because of exactly this problem. The agent does not remember architectural decisions. The repository does.

What it comes down to

The split is simple. I own the spec, the boundaries — both trust and architectural — and the critical parts of the code. The agent owns the volume of work inside those boundaries. Tests and the linter make sure I never have to take its word for it.

All of it reduces to one principle. An agent has no memory between sessions, so the project's memory has to live in the project: a numbered spec the code can cite, and a rules file that grows out of every expensive mistake. Whatever is not written down will be decided again — and differently next time.

How I pick models for this kind of work, and why I do not trust leaderboards, is on the AI page and in Prompt Vault.

Here is what shipping Texodus taught me about the distance between "it builds" and "they downloaded it and it started".

Linux: it did not start for everyone

I did not find this one myself. It arrived as a bug report on GitHub: the AppImage would not launch at all, dying on graphics initialization. On my machine, and on plenty of distributions, everything worked — exactly the kind of symptom you cannot reproduce where you develop.

Could not create default EGL display: EGL_BAD_PARAMETER

The cause was not in the application code but in the packaging. linuxdeploy faithfully bundles the graphics client libraries of the machine that built the app — in my case Ubuntu 22.04 on GitHub Actions. At launch they are loaded ahead of the host's own copies, and then talk to the host's Mesa driver. As long as the versions stay close, this works. On recent Mesa — the report came from Arch with RDNA4 — WebKitGTK cannot initialize EGL through that mismatched pair, and the window simply never opens.

The reasoning is the same as behind AppImage's standard excludelist: the graphics stack has to come from the host, not from the bundle. Which means those libraries have to leave the bundle.

The fix belongs in the pipeline

Fixing this by hand once would be useless — the next release would rebuild it exactly the same way. So the GitHub Actions workflow got a step that runs after the build: unpack the AppImage, delete what should not be there, and pack it back up.

find squashfs-root \( \
  -name 'libwayland-*.so*' -o \
  -name 'libgbm.so*' -o \
  -name 'libdrm*.so*' -o \
  -name 'libEGL.so*' -o \
  -name 'libGL.so*' -o \
  -name 'libGLX*.so*' -o \
  -name 'libGLdispatch.so*' \
\) -print -delete

Then came three details, each of which cost its own round trip:

• No FUSE on the runner. Extraction goes through --appimage-extract, and appimagetool itself runs with --appimage-extract-and-run.
• The appimagetool download was dead. Assets on the old AppImageKit releases return 404, so the step pulls from the maintained AppImage/appimagetool repository instead, at a pinned version.
• The asset was already uploaded. tauri-action publishes the AppImage before this step runs, so the finished file has to be swapped through the API: delete the old release asset, upload the repacked one.

None of this follows from the Tauri documentation. All three showed up on live releases.

macOS: not even in CI

The Texodus build matrix has two runners: ubuntu-22.04 and windows-latest. macOS is not there at all — those builds run locally, from a separate script.

The reason is signing. A shippable DMG needs a Developer ID certificate from the local keychain and notarization with Apple, which wants an app-specific password and a team ID. On top of that, a universal binary means two Rust targets (x86_64-apple-darwin and aarch64-apple-darwin) built and merged. All of this can be moved into CI — at the price of spreading certificates and secrets across someone else's infrastructure. For a project I run alone, a local script turned out to be the honest trade.

The result is one application with two different release paths: Linux and Windows build in the cloud at the push of a button, macOS builds on my Mac.

One feature, three mechanisms

The most underrated part of cross-platform work is not packaging. It is that identical behavior has to be implemented differently.

Take opening a file by double-clicking it in the file manager. On macOS the path arrives as a RunEvent::Opened event. On Windows and Linux it arrives as a command-line argument, plus a single-instance plugin so that a second launch hands the file to the running process instead of starting a second application.

The macOS branch also has a race that does not physically exist on the others: Opened can fire before the main window has been created. Until that was handled, double-clicking a .md file while the editor was closed opened two windows — one empty, one with the file. The routing logic saw no window and read that as a signal to spawn one.

The same category includes features that simply do not exist elsewhere. In Kivarion, Touch ID unlock is macOS-only, and reporting an honest "not supported" on Windows and Linux is as much a part of cross-platform work as the feature itself.

What I took away

• Test the release artifact, not the build. The EGL problem lived neither in the code nor in a dev build — only in the packaged AppImage, on someone else's system. If you do not test that, a user will, and then they will write to you about it.
• "Works on my machine" means nothing on Linux. Distributions differ in graphics stack versions more than you expect, and it is the newest environment that breaks, not the oldest.
• A platform fix has to be a pipeline step. Anything repaired by hand after the build is lost on the next release.
• Plan for different release paths. Apple's signing requirements differ enough that a single pipeline for all three platforms stops being an obvious goal.

"Cross-platform" is true about the code. About delivery, it is three separate projects that happen to share a repository.

Texodus is open source: repository and releases.

Let me be upfront about where I am standing. I have never worked at a FAANG company myself. But in twenty-plus years in this industry I have worked alongside plenty of people who did, a good number of my friends and former colleagues built careers there, and I have interviewed and hired candidates coming out of those companies. This is the view from the other side of the table — the side where the brand on the résumé stopped answering the only question that matters: what can this engineer actually build?

The role narrows to a single component

At a company with hundreds of thousands of employees, work has to be split into very small pieces. That is not a flaw in anyone's character — it is what scale demands. But instead of designing a system or taking a service from zero to production, an engineer can spend years maintaining one narrow component of one internal platform. Depth in that component grows. The view of the system as a whole quietly atrophies.

The result for a career is the same either way: after a few years you know something brilliantly, and that something exists only inside one company.

A closed stack does not transfer

The largest companies have always built their own ecosystems: their own frameworks, build systems, version control, deployment tooling. Inside, these are often excellent — years ahead of what the rest of the market has. The problem is not quality. It is portability. Expertise in an internal platform is worth very little the moment you walk off the campus.

There is an honest complication here worth stating. A significant part of today's open stack consists of public descendants of exactly those internal systems: Kubernetes grew out of the experience of Borg, Bazel is the open version of Blaze. The argument is not that Big Tech has bad tools. The argument is that the market runs on the public versions, and an engineer who spent four or five years on the internal ones tends to discover that the ecosystem moved on without them — from cloud providers to orchestrators to frameworks.

Golden handcuffs

High salaries and equity grants build a standard of living that is hard to maintain anywhere else. The price for that comfort is often routine work wrapped in process. Colleagues describe simple changes spending weeks in approvals that a small team would not need at all. Engineering initiative does not die suddenly in that environment. It just stops paying off.

What Big Tech still teaches better than anyone

I am not interested in building a straw man, so let me be clear about the other side. Some things scale teaches better than any startup can: operating systems where a failure reaches millions of people, a real code review culture and the discipline that comes with it, the skill of changing a running system without knocking it over. And for researchers and R&D engineers pushing fundamental work, those labs are still the best places on the planet.

Choosing stability is a legitimate choice too. Trading some speed of professional growth for comfort and predictability is an adult decision, not a mistake — as long as it is actually a decision. The failure mode is the cargo cult: treating "getting into the corporate elite" as the goal itself.

What to do about it

If you are an engineer inside a big company, do not let the internal platform become the only thing you know. Side projects, open source, a public trail — anything that lives outside the campus and can be checked from outside it.

If you are hiring, look past the brand at what the person has built and what you can verify: shipped products, breadth of stack, a visible trail in open code. The brand on a résumé answers the question of where someone was once hired. It stopped answering the question of what they can build a while ago.