Agents

Hard problems don’t have to be worked one step at a time. LifeOS fans them out to specialized workers that run at once — several researchers splitting a question, or a builder and an auditor on the same code — then pulls the results back together. The system thinks in parallel instead of in single file.

Why it exists

One worker on a big problem is a bottleneck. Plenty of the work in closing a gap is independent — a dozen sources to check, a directory of files to map — and running those in sequence wastes the one thing you can’t get back, which is time.

There’s a second reason, and it matters more. A single model shares its own blind spots. Ask it to check its own work and it tends to miss the same things twice. Real review needs a different vantage point, sometimes a different model family entirely. That’s why the audit at high effort comes from another vendor’s model, not one more pass of the same one.

How it works

There are three kinds of agent, and the system picks by the job. Built-in ones handle internal legwork like searching a codebase or drafting a plan. Named agents are persistent identities with their own backstory and voice, so recurring work keeps continuity across sessions. Custom agents get composed on the fly from traits — an area of expertise plus a personality and a work style — and each combination maps to its own voice.

Each agent runs on a model sized to its task: a quick model for grunt work, the strongest one for deep reasoning. After parallel work, a spotcheck agent reconciles the outputs so nothing contradicts. At the top effort levels a cross-vendor agent from another model family audits the result. It’s a read-only pass, and its whole job is to catch what a same-family reviewer would share and miss.

The mix scales with the stakes. A quick lookup might spawn no agents at all, while a big research sweep can fan out to a dozen and reconcile them at the end. For unattended runs where you want a provable record of what happened, a read-only observer team can watch the work and vote to continue, halt, or escalate, never touching a thing itself. It trades some speed for a trail you can audit later.

Where it fits

The Algorithm reaches for agents on its own once a task splits into three or more streams of work. It follows a preference order: teams first for anything that needs coordination, custom agents when you ask for them by name, cloud-hosted agents for long unattended jobs, built-in types for plain internal routing.

The cross-vendor audit isn’t optional at the highest effort levels. When the stakes are up there, a second model family checking the work is a required step, not a nicety.

What it feels like

You ask a hard research question and the answer comes back quick, because several agents went and got it in parallel while you waited once. You green-light a build and a reviewer you didn’t ask for flags the bug you’d have shipped. The work feels less like one assistant grinding through a list and more like a small team that split the job and checked each other before handing it back.