Bring agents to the systems

For a while I tried to make the agent workspace the center of everything.

Hermes was the experiment. One dedicated place for the agent. One room where context lived, tools lived, and the work was supposed to gather. Capturing knowledge there still felt good. Making context readable for other agents still felt good. The problem was quieter: the real results still lived somewhere else, and now I also had another app to maintain.

That is the shift I want to name. Personal AI should bring agents to the systems where work and results already live. Email stays in email. Files stay in native storage. Durable artifacts stay in their project homes. The harness is a portable control and orchestration layer, not another destination that demands loyalty.

The destination tax

A powerful all-in-one agent workspace can look like simplification. One window. One memory. One place to ask.

In practice it often recreates the maintenance burden personal AI was supposed to reduce. You migrate reading into it. You migrate tasks into it. You start treating the chat product as home. Then the newsletter still ships from the writing stack, the briefing still needs the calendar and news sources, and the "home" becomes a mirror you have to keep current.

I already wrote the setup surprise in Real work in one bot session. A few Grok Bots against my existing MCP stack. Local news briefing, AI briefing, Monday Pixel Perfect Picks draft. Same jobs I already had, just scheduled. What surprised me was not the output. It was how little the workflow changed. MCP became the bridge. Every piece of the stack kept its own territory. I could borrow model intelligence without rebuilding everything.

This essay is the architectural claim under that TIL post.

What changed when I stopped centering the harness

The Hermes phase taught me what I liked about a central layer: capture, persistence, a place where tool calls and rules could sit together. It also taught me what I disliked: treating that layer as the place work had to live.

The portable version flipped the priority. Existing MCP connections plus an external memory layer meant I could try Grok Bot features and routines without a day or two of setup theater. First real results showed up inside an hour. Lightweight, transportable, boring in the best way.

That is the before and after for me. Destination app: slow to stand up, sticky once you invest, quietly hungry for more of your stack. Agents-to-systems: reuse the connections you already trust, leave artifacts where they belong, treat the model as something you can swap under a stable how.

What I still want the harness for

I am not arguing against harnesses. I still want a powerful underlying layer, even if I only use a fraction of it.

I want it for capturing knowledge. Things that only exist in a chat are easy to forget and hard to find. I want durable memory in files, history I can read, and enough context to hand an agent without starting from zero. I want tool calls, rules, and guardrails in one central place.

The picture that feels right: one persistent layer of the how, with the knowledge underneath swappable. Model and capabilities can move. The operating posture stays. For that to work, the harness has to stay lightweight and portable. Heavyweight destinations fight the portability I now care about.

Lilian Weng's harness engineering treats the harness as the system around the model: orchestration, context, feedback loops, the runtime that decides what the model can see and do. The Harness Playbook makes a related point from the other direction: unavoidable complexity needs an owner, and that owner is the envelope around the agent, not the chat window. I am stealing the useful part for personal systems: own the how somewhere stable. Do not force every surface to become that somewhere.

Mozilla's The Interface Is No Longer the Product pushes further: agents need structured state they can read and rewrite, not another mouse theater. That lines up with bringing agents to systems that already hold the work, rather than teaching agents to click through a fake desktop of your life.

The other side of the argument

Every's One App to Rule All Knowledge Work describes people converging on a unified Codex-style destination: project sidebar, connected tools, daily workflows in one desktop AI app. For some jobs that is probably correct. Orchestration tax across five systems can be worse than one strong room. Fragmentation is not virtue.

Kieran Klaassen's The Folder Is the Agent also complicates my claim in a useful way. The specialist is often a folder with conventions and skills, not a chat product. That is closer to what I want than a mega-destination: portable context that makes a general model useful in a specific territory.

So "bring agents to the systems" is not "never build a harness" and not "never use a unified workspace." It is a bias. Default to leaving work where it already lives. Use the harness to orchestrate across those places. Reach for a destination only when the destination clearly reduces maintenance instead of relocating it.

How I am running it now

Narrow bots against existing MCP-connected systems. Briefings, newsletter drafts, writing proposals prepared in place. Memory and skills treated as owned assets, not chat residue. A powerful how-layer kept light enough that trying the next bot does not cost a weekend. Superlist is one of those territories: agents land in the same lists I already use, instead of inventing a second task world.

I expect more cross-system access over time. That does not mean I want one app to become the home of everything. It means the bridges get better while the territories stay named.

Bring agents to the systems. Keep the harness portable. Let email be email.