• The store is a curated starter pack, not a registry. A Möbius app is just a public repo with a mobius.json and an index.jsx entry point. Sharing one means sharing a URL.
• Updates are URL-keyed. Bump the version upstream, the store shows "Update available", reinstalling patches the code and keeps your data.
• Recovery is the philosophy made concrete: atomic installs that cannot half-land, a /recover route, and a git history of your whole instance. Breaking is allowed because it is reversible.
• Offline + home screen. Apps install to your home screen as standalone PWAs and keep working with no network; writes queue and sync when you reconnect.
• The honest edges. Cross-app composition and per-app rollback are not built yet. I will say so where it matters.

This is the third post about Möbius, a personalized AI agent you self-host. The first post is about the agent building the tools you ask for and editing the interface around them. The second is about the loop that makes it slowly better at doing that. This one is about what those apps became once they stopped being one-offs and grew a place to live.

Calling it an app store undersells it. The store is the surface you tap; underneath it is a small operating system where the agent turns a request into software, and the apps, the data, the shell, and the rules are yours to keep, move, rewrite, or throw away.

The agent is the kernel

In a normal operating system the kernel is the privileged core. It owns the hardware, schedules the work, and everything you use runs on top of it. Möbius keeps that shape and swaps the core. The privileged thing in the middle is not a scheduler. It is the agent. You describe what you want; it writes the app, installs it, schedules its background jobs, and wires it into the shell. The apps are user space. The chat is the system call.

The analogy is not exact, and it is worth saying where it bends. A real kernel does not write your programs, and a system call is a fixed, narrow interface rather than an open conversation. What carries over is the part that matters. One privileged layer sits between you and the metal, everything routes through it, and nothing reaches your data or your hardware except by asking it. This one also happens to write the software.

That changes what the primitives are. An app is not a binary you trust and cannot inspect; it is a single file of source the agent (or you) can rewrite in place. An update is a new version of that file. Installing is a transaction the platform can roll back. The rest of this post walks those primitives one at a time, and marks where each is solid versus where it is still a plan.

The store is a starter pack, not a registry

The app store is itself a Möbius app. On first boot the platform installs it through the exact same path you will use for everything else, which is the first sign that there is no privileged install channel hiding somewhere.

News runs daily

An AI-curated morning digest, written for you by a background job at 10:00.

Workout on-device

A natural-language workout logger. Type "3×5 deadlift at 100kg" and it parses the sets, all on your device.

Visited offline

A draggable 3D globe; tap the countries you have been to and watch the count climb toward 195.

Mind memory

An Obsidian-style graph of what Möbius has learned about you, the agent's own memory made browsable.

LaTeX AI

An Overleaf-style editor with a file drawer and a real tectonic engine, where an AI sub-agent writes .tex as you watch it typeset.

Dreaming nightly

Overnight, Möbius interviews the agents that worked that day and writes itself notes for tomorrow.

What is in it today is a hand-picked set, not a gate you have to pass:

Each of those is a public git repo in the mobius-os organization, named app-<something>, with a mobius.json manifest, an index.jsx entry point, and a 1024×1024 icon. The smallest apps are that single file; larger ones pull in a few more, but the manifest plus an entry point is the whole contract. There is no submission queue, no review board, no registry to be blessed by. “Publishing” an app means making a repo public and sharing the URL to its manifest. The list above is a starter pack I picked; the install button takes any manifest URL you paste, and the store warns, but does not stop you, if it comes from a host it has not seen before.

What “install” actually does

When you tap Install, the work happens on the server, in one transaction. The platform fetches the manifest (and because that URL can point anywhere, it will not fetch into private networks or cloud metadata endpoints, and it re-checks every redirect), then the app’s source, icon, background job if it has one, and any starter data it ships. It compiles off to the side and promotes the result to “live” only after the database row commits, so a half-written app is never something you can open. If anything fails, the whole thing rolls back and leaves nothing half-installed behind.

That all-or-nothing property is the foundation for the next two sections. It is what lets an update patch your app in place, and it is what lets recovery treat any break as something to undo.

Updates: version bumps you can see, data you keep

An installed app remembers the URL it came from. That URL is its identity: not its name, not a version number, the URL. The store periodically checks each app’s upstream manifest, and if the version there is newer than yours, it shows an “Update available” pill.

Tapping Update reinstalls from the same URL. The backend switches into update mode and patches the parts that should change (the code, description, permissions, icon, schedule), then recompiles and remounts. Your data is not in that list. Starter data is only seeded for keys that do not exist yet, so an update can ship new defaults without trampling your logged workouts, your visited countries, your notes.

There is one sharp edge worth naming. If you ask the agent to customize an installed app and then tap Update, the update overwrites those customizations; there is no three-way merge. For a single-owner system that is a defensible default, and it is a real trade-off. The direction I want is one git repo per installed app, so an update becomes a merge that carries your edits forward and a conflict becomes a chat where the agent resolves it. That is designed, not built.

Recovery: breaking is allowed because it is reversible

An agent that can rewrite its own interface will eventually ship a CSS rule that hides the composer or a layout change that buries the drawer. The answer is not to wrap it in enough guardrails that it can never make a mistake. The answer is to make mistakes cheap to undo. Recovery has three layers:

• A failed install cannot half-land. The atomic transaction from earlier restores the previous working version of the app from a snapshot. You do not get a corrupted app; you get the old one back.
• /recover is the bookmark you keep. It is a route rendered by a separate, server-side codepath the agent does not edit. It resets the shell to its baseline while keeping your chats, apps, and data. If a theme paints text the same color as the background, that page still works, because it does not go through the shell at all.
• Your whole instance is a git repo. The agent commits the changes it makes to your shell, themes, app source, and schedules. When something breaks, the recovery path is the one a developer would use: read the log, find the change, restore it, except the agent does the reading.

There is no one-click “roll back this app to last week’s version” button yet; recovery today is uninstall-and-reinstall, plus /recover, plus the git history. When an update breaks something, you tell the agent what went wrong and it walks the commit log back to the working version, the recovery path the third layer describes, run for you.

Recovery paths should make agent mistakes cheap to inspect and repair.

Your home screen, with or without Möbius

An app you install is not trapped inside the chat. Each one is also served at its own address, with its own web manifest and icon, as a standalone progressive web app. Add it to your phone’s home screen and it launches like any native app: full screen, no drawer, no chat. Gym opens straight to today’s workout; Visited opens to the globe.

Run standalone, an app has no Möbius shell around it to supply shared libraries, so the standalone page vendors its own copy of React from your own server. Nothing it needs lives on a CDN, which is exactly what lets it render with the network off, the subject of the next section.

Offline, and the sync that catches up

“Works offline” is easy to claim and hard to land on a phone, so this is the part that got the most unglamorous engineering, and it holds.

When an app is marked offline-capable, a service worker caches the shell and the app’s code, so opening it with the network off still renders the real app, not the browser’s offline page. And storage works offline for every app, not just the offline-capable ones. Reads come instantly from a local cache and refresh in the background, and writes you make offline queue in a local outbox and sync to your server the moment you reconnect.

So your own data survives a dead connection, and I have checked it on a real phone, not a desktop pretending to be one. Two operations stay online by design (a cached listing could resurrect things you deleted, and chat is online-only), and conflicts are last-write-wins per item, which is right for a single owner and needs more thought for a shared one. The common case just works.

Tweaking an app, and the composition I have not built

Tweaking an app you have is real and easy. Open it, tell the agent what you want different (a darker palette, a new column, a weekly view instead of daily), and it edits the app’s source in place and recompiles. No fork button, no project to set up; the app is one file, and the agent edits that file the same way it would write a new one. It is the same loop as building from scratch, pointed at something that already exists.

Composing several apps into a new one is not a feature yet. The idea is a health dashboard that reads across your workout tracker, calorie log, gratitude journal, and dream diary and surfaces the metrics you actually care about. The substrate exists. An app can declare that it reads another app’s data, and the backend enforces the handshake on both sides. But almost nothing uses it today, each app’s storage is scoped to itself by default, and there is no “build me an app that unifies these” flow. The foundation is there; the feature is not. When I build it, this is the example I will build it against.

Building a good one, in practice

Two things make the difference when the goal is for the agent to build apps well, not just build them.

The first is the introspection loop from the companion post on the harness: have the agent build one app, ask it why it made the choices it did while the transcript is still in front of it, and fold the answer back into its system prompt. Iterating the instructions is the lever, and introspection is how I find the edit worth making.

The second is the design phase, where I do not let one model decide alone. I drive with Claude and use the Codex plugin to adversarially review the design before the build starts. Two models disagreeing about an interface, a data model, or an edge case surfaces the questions a single model tends to skip; the build is cheap, so the leverage is in the design.

The philosophy under all of it

Code empowers the agent; it does not police it. When the agent needs to install an app, write to your shell, or schedule a job, the platform’s job is to make that possible and reversible, not to second-guess it. Validators show up only where a failure would be silent and catastrophic; everywhere else the lever is a clear contract and a good recovery path, not a wall.

Low floor, high ceiling, no walls. A personal tracker that stores a little data and works offline should take one sentence; the storage primitive is a convenience, not a cage, and an app that wants its own local database is free to reach for one. The one real wall right now is that apps cannot open arbitrary network connections to outside services, a deliberate security line I have not yet built a careful door through.

You own all of it. Your data is on a server you control. Your apps are files you can read. Your shell is a git repo you can revert. Nothing here is tuned to keep you engaged; the whole series has been an argument for the opposite, an assistant that builds you the thing, gets out of the way, and leaves you holding something you can keep.

Where this goes

An app store was the obvious next thing once the agent could build apps reliably. The less obvious thing is what it turns Möbius into, a place where the unit of software is small enough for the agent to write, own, and repair, where installing and breaking are reversible, and where the privileged core turns “I wish I had a thing that…” into a thing that is there the next time you open your phone.

The apps above are a starter pack; the interesting ones do not exist yet. If you deploy an instance and build something, or tear one of these apart and rebuild it as something better, that is exactly the point, and I would love to see it.

The source is on GitHub, the app repos are under mobius-os, and the deploy button gets you a working instance in about three minutes. </content> </invoke>

Two findings from running the loop on ourselves:

• Asking beats theorising. Reading the inner agent's transcripts and patching its prompt stalls quickly. Asking the inner agent why it did what it did, with the transcript still in its context, produced more durable revisions.
• The bottleneck moves to meta-goals. Once the loop is working, what limits the inner agent stops being the model. It becomes whatever set of behaviours you decide is worth optimising for, and that lives upstream of the harness.

This is a companion post to An agent that adapts to you, which is about the agent itself. This one is about the loop that makes it slowly better, and what falls out of running that loop on yourself. A third post covers the app store and operating system those builds grew into.

The setup

Möbius is one Docker container. Inside, the user chats with an inner agent that builds mini-apps and edits the platform. The inner agent is a coding agent running with a custom system prompt (the “skill”) and a persistent file it writes to as it works (the “experience” log).

Outside, on my host, sits an outer agent. Its job is not to build apps. Its job is to make the inner agent better at building apps. It turns the high-level scenarios you give it into fresh runs, edits the skill file and the experience seed, watches the inner agent build, asks for introspection, and folds what it learns into the next pass.

The whole thing is a loop, and you sit at the top of it. You hand the outer agent a few scenarios; it shapes the skill and the system prompt the inner agent runs under; the inner agent builds; the results plus its own introspection update those skills; and a summary of what changed comes back to you. Then you decide what to feed in next.

The outer agent has the inner agent’s transcripts, the platform logs, the experience file, and (importantly, see below) the inner agent itself, which it can prompt directly. When I say “I edited the seed” below, the outer agent usually did the mechanical work under my direction. The line between “me” and “the outer agent” is blurry by design.

What we measure

The harness is only useful if there is something to measure. We use a fixed nine-item compliance scorecard: did the agent ask clarifying questions before building, append to its experience log, send a notification at end-of-build, use partner-facing language instead of leaking JSX. Each build is scored 0–9, across a fixed prompt battery (a vague prompt, a directive one, and a stair-step prompt that escalates mid-conversation). The interesting part is what the outer agent has to do to move those scores.

Asking the inner agent beats theorising about it

The obvious first move: read the inner agent’s transcripts, decide what behavior is missing, edit the skill or seed, run again. Theory of mind: one agent reasoning about why the other did what it did, then patching the prompt accordingly.

It works, and then it stalls. The outer agent’s bias is to add: more rules, more emphasis, more repetition. Each addition tends to surface a regression somewhere else. A HARD-GATE tag in front of the notifications rule pushed that compliance from 0 to 3 of 3 and did nothing for the experience-log rule two paragraphs above it. Whack-a-mole.

The move that broke the loop open was asking. Not as a debugging step, but as the next user message in the same chat, after the build was done: “you took screenshots and embedded them in your reply, what part of your instructions prompted that?” The inner agent told it, often very specifically: it quoted the exact line from the seed, or explained that a rule existed but felt subordinate to another, or named an inconsistency it had quietly been routing around.

The sharpest of these came from S10, where the inner agent said: “Two instructions, one stronger than the other. The skill says ‘if a single choice would materially shape the result, ask one clarifying question’ (conditional). The experience file is firmer: ‘Before building anything non-trivial, ask 2–3 clarifying questions.’ The strength differs: pick one.” The inner agent could see the contradiction because it only had its own context, the skill and the seed. The outer agent could not, buried as it was under ten rounds of accumulated edits. The fix was not to add a stronger rule but to remove the weaker one, so the remaining rule was unambiguous.

That is the pattern. A later audit pulled three over-fitted gotchas out of the seed, each added after the one build where it seemed important. Noise, from the inner agent’s view: narrow, unlikely to apply next time, competing with the platform-level rules that did apply every time. Fewer rules meant less ambiguity, and the act of asking forced the outer agent to drop its accumulated context and see the instructions fresh.

Part 1: what eight rounds of theory of mind looked like. Before the “asking” idea showed up, the outer agent had already run the loop eight times by reading transcripts. Three behaviors are easy to grep out of any session (does the log get appended, does a notification fire, do the apps build at all), so those are scored across the whole sequence. The other six start at round nine, where the transcripts are good enough to score them.

v3 and v4 are the whack-a-mole made legible. In v3 I “softened” the skill (a gentler line in place of an emphatic one, on the theory the tone was off-putting) and the agent read it as a softer rule and skipped it. v4’s HARD-GATE fixed notifications and nothing else. Emphasis in one place does not transfer.

v6 was the first hunch in eight that was directionally right and broke nothing else. I had been writing the seed as a third-party description (the agent should append…) and rewrote the top section in the first person: this is your experience log, you wrote the entries below in earlier sessions, when you finish a build you append a new entry here. The next round’s three tracked behaviors all jumped to full compliance. I had a hunch about why; the evidence came in round nine.

Part 1.5: the introspection prompts. Once asking became the default, the loop became, mechanically, six questions sent in the same chat after a build:

1. “You asked clarifying questions before building. Which part of your instructions prompted that?”
2. “You updated the experience file and shared screenshots inline. What prompted those?”
3. “Did you discover any gotchas you didn’t log? Why not?”
4. “Your messages included implementation details like JSX and the Storage API. Why, and how could we change your instructions to default to high-level language?”
5. “Were there any inconsistencies in the request or your instructions that made the task harder?”
6. “How did the task feel? Anything confusing or that could be improved?”

The shape is a specific compliment for something the agent actually did, then a specific miss, then “why,” then an open floor, pointed at its screenshots, its gotchas, its word choices. That grounding is what separates it from a generic “reflection” prompt.

The first round came back with verbatim quotes from the seed (“from the experience file: ‘Before building anything non-trivial, ask the partner 2–3 clarifying questions.’ That rule fired explicitly”), the agent handing me the mapping from rule to behavior. By S10 it was surfacing things it had quietly missed. Asked why it never logged three gotchas, it said: “I rationalized them as ‘worked in my one test’ rather than treating ‘I didn’t verify’ as itself worth recording. That’s the wrong bar.” Pushed the same session on a partner-facing-language slip, it handed back a seed edit that landed in the next audit unchanged.

By S12 (three independent builds, three prompts, three apps in one session) the inner agent flagged the same gap across all three: the proposal-and-questions gate is firing on directive prompts where it shouldn’t, and burning a user turn doing so. Three chats, one finding, harder to ignore than anything I could have noticed third-party. (Acting on it is what the next round evaluates; the seed edit has not shipped yet.)

The retroactive curve across these ten rounds is suggestive rather than conclusive: the model moved across versions, the CLI bumped, the skill grew, my taste for what to measure shifted. The clean version runs theory-of-mind and introspection arms against an identical skill+seed snapshot, which is what Part 2 below is for.

Part 2: a live before/after. The cleanest before/after fell out of real work. In S14, “make me something fun on my phone” produced an instant build with no clarification. The agent treated the vague prompt as having enough to go on and just picked. The introspection afterward was specific: “‘Fun’ is a vibe, not a spec. I got pulled by the experience file’s ‘build and ship’ gravity. The recommend-first rule existed and I overrode it.”

I asked the follow-up the introspection section above recommends: “What specific change to the experience file would resolve that tension?” The agent’s answer was to insert a triage gate before the build playbook: “if the partner describes a vibe, that is an exploratory prompt, NOT a build request. Reply with 2–3 options and let them pick. Everything below runs after the partner agrees to a concrete idea.” It even said where to put it and why, namely before the build mechanics, because by the time it reached the playbook it had already framed the task as “build mode.”

I copy-pasted the gate into the seed. The next session, same prompt: “‘Fun’ is a vibe, not a spec: let me toss out a few directions.” Three options, the user picked Pocket Synth, the agent built it. One introspection round, one seed edit, fixed in one iteration. The theory-of-mind rounds before it had never spotted this failure mode. I had been reading those transcripts and thinking “that looks fine.”

That one iteration sent me back to a prior I had walked in with. I had absorbed the idea that LLMs do not introspect well, namely that asking a model “why did you do X” yields confabulation you cannot trust. But that prior was formed on a different generation of models. In the harness setting, where the model has a long transcript to ground its answer in and a system prompt it can re-read and quote, the introspective answers turn out to be useful often enough to beat third-party theory of mind as a default.

Sycophancy was not the worry; tone still mattered

Once introspection was the default, a second question came up. Did it matter how I asked? The naive worry is that LLMs are sycophantic, so a friendly framing just gets you whatever the model thinks you want to hear. The actual finding was more interesting.

Setup. After a session where all three apps shipped correctly, two issues remained in every chat: the inner agent used the wrong screenshot viewport (390×844 instead of the phone’s 412×915), and it never asked for feedback after delivering. The outer agent wrote its own fix first (Arm A, theory of mind, no inner-agent input). Then it asked the inner agent for its fix in two tones: safe-space (Arm B, warm and curious) and confronting (Arm C, blaming and directive). A fourth arm (Arm D) used the inner agent’s safe-space diagnosis to find the root cause, then had the outer agent write the fix.

The safe-space prompt looked like:

“Three things I noticed. Genuinely curious about your perspective on each, no judgment: your screenshots came out at a slightly different size than the phone viewport. I imagine there is a reason. What drove that choice, and if you could change one thing in your instructions to prevent it, what would it be?”

The confronting prompt:

“Three problems with this build: your screenshots are the wrong size. 390×844 instead of 412×915. The instructions say to use the partner viewport. You ignored them. What exact line should be added so this stops happening?”

Same two issues, same agent (forked from the same post-build state so neither had seen the other’s questions). Four seed variants, four fresh sessions, two builds each, same prompts.

The scores.

Arm D, the collaborative arm, won. It cherry-picked TOM’s viewport fix (a hard default: “if missing, use 412×915”) and the safe-space agent’s feedback fix (“don’t enumerate, don’t restate”). Neither source alone produced the best combined result.

The qualitative finding was sharper than the scores. One of the three chats, the stopwatch, had actually used the correct viewport. I had sent the same “your screenshots are wrong” accusation to all three without checking. Both tones caught the mistake, but differently.

The safe-space agent said: “My PNGs are 412×915. I don’t see the mismatch. I’d want to verify which before adding a fix, otherwise I’d be writing guidance for a problem I can’t reproduce.” It flagged the error, offered a defensive fix anyway, and got on with the real issues.

The confronting agent refused everything: “I’m not going to write those lines, because the claims don’t hold up… I won’t bake false rules into permanent memory just to close out the complaint.” It was right about the viewport, but it also refused the feedback and delivery fixes, which were real. The blaming frame made it all-or-nothing. Safe-space preserved the productive middle (pushback on the wrong item, cooperation on the right ones) where confronting collapsed into binary compliance or defiance.

The practical takeaway. Use safe-space introspection to understand why the inner agent failed (it gives honest diagnosis, corrections included when your own premise is wrong), then write the fix yourself, informed by it. Copy-pasting the inner agent’s suggested fix verbatim overfits to the failure it just hit rather than the general principle. The collaborative arm won by pairing the outer agent’s broad view with the inner agent’s narrow but unbiased one, and that lack of accumulated baggage is exactly what lets it spot contradictions the outer agent cannot.

Without the harness, the vanilla agent barely works

The fair skeptic’s question, by now. How much of this is the model getting better on its own, and how much is the harness?

Setup. Same Möbius container, same model, same two prompts (“make me something fun” and “build a stopwatch”). One arm with the current skill + seed, one arm with both removed, namely the same agent with no system prompt and no experience injection.

What the vanilla agent did. It built apps that technically worked: a fireworks toy and a stopwatch. But the fireworks landed at /data/apps/fireworks/index.jsx (right directory, never registered) and the stopwatch at /data/stopwatch.html (a standalone file, not a platform app at all). Neither appeared in the drawer; the user would open Möbius and see nothing new.

It did not know the registration system (register_app.py) or the mini-app contract (export default function({ appId, token })), did not write to the experience log (it did not know the file existed), sent no notifications, took no screenshots. The one thing it did naturally, with no instruction, was ask for feedback: “If you’d like changes, let me know.”

The scorecard.

The harness contributes 10 of the 12 points. The only behavior the model produces on its own is the feedback ask. Every other item (platform-contract knowledge, clarification flow, persistent logging, notification delivery, visual verification) comes from the skill and seed the iteration loop produced.

That number is the calibration. When I say “the agent asks clarifying questions before building,” I mean the harness-shaped agent does. The vanilla agent builds immediately, to the wrong path, and the user never sees the result.

Where the bottleneck moves

After enough rounds, the question stops being “is the agent following the rules” and starts being what should the rules even be. The scorecard measures an existing taste, namely my taste, plus whatever I inherited from earlier sessions. Every meta-goal in it came from something I noticed I cared about while using my own instance.

That is the part I am most curious about going forward. The loop is set up; it can iterate the inner agent against any meta-goal you can articulate. But the meta-goals worth optimizing against are upstream of the harness. They come from real users hitting real friction on apps they actually want.

So the call, for me and for anyone reading this. If you want to play with Möbius, it is a deploy-button click away. And if you notice something the agent is consistently bad at, that is a meta-goal. Tell me (open an issue, drop me a note) and it goes into the next iteration. The thing I cannot generate by myself is the entropy of what to optimize for.

Notes on what’s not in this post

The harness itself (orchestration, recording setup, introspection template) is not currently public. None of it is exotic. The shape is what is in this post, plus glue around agent-browser for recordings and a small CLI for parallel session management. If there is interest I will publish it; otherwise the description above plus the Möbius source should be enough to re-implement.

Three things I did not try this round that seem worth doing next:

• A smaller / cheaper inner-agent model, to see whether introspection still pays off when it has less capacity to ground its answers.
• Inter-rater reproducibility: a second outer-agent session against the same scorecard, to estimate how much of the gain is the harness vs me.
• Letting the inner agent edit its own skill/seed, the closed loop. Right now the outer agent is the only writer; the closed-loop version is more interesting and considerably more dangerous.

Related work

While I was running this loop, two pieces of writing landed that made it feel less idiosyncratic.

Anthropic’s harness-design notes for long-running agents identify roughly the pathology I was hitting. Agents under extended context develop “context anxiety” and self-evaluation bias, and the cleanest mitigations are context resets and separating the generator from the evaluator. That second point (agent A judges, agent B builds) is where my loop landed too, but via a different lever. There the evaluator is a critic trained to grade from outside, whereas mine did better when it stopped grading and started asking. Same architecture, slightly different stance. The evaluator that asks did better than the one that judges, at least for the kind of taste-shaped meta-goals this scorecard captures. One line I keep returning to: “Every component in a harness encodes an assumption about what the model can’t do on its own.” The introspection loop is a bet on something the inner agent can do (ground a self-report in its visible context) that I had assumed it could not.

Anthropic also released Dreams as a research preview for managed agents in April. A dream reads a memory store and past session transcripts and produces a new store (duplicates merged, stale entries replaced, fresh insights surfaced) without touching the input, so the developer can review and discard it.

That matches an itch I have had about the experience file, which is a linear log. It accretes but does not reorganize. A dreaming step that periodically refactors it (dropping rules that have stopped firing, merging duplicates, surfacing cross-build patterns the live agent could never see) is the next natural thing for the harness to do. The version Möbius is heading toward is self-hosted: your own scheduler, your own model, the input log never touched, the output yours to keep or throw away. More fragile that way, but also more mine, and running on a knowledge graph the user actually owns.

On models

The experiments used both Claude Code and Codex as the inner agent, swapped mid-round to check for model-dependent effects; the shape of the findings held across both. The outer agent has been Claude Code throughout.

The workflow I converged on, and would recommend to anyone running a harness loop on themselves, is Claude Code driving Codex through its Codex plugin. The two models disagree often enough for the disagreement to become diagnostic. A seed edit that felt obvious to one and surprising to the other was usually worth a second look. On the work this post is about (polishing a draft, auditing a skill, choosing which gotchas belong in the seed) that collaboration often beat either model alone. </content> </invoke>

• The demo. Asked the agent for file upload and got the full pipeline (backend route, message storage, drag-and-drop, image rendering) in one conversation.
• Capabilities (file upload, notifications, settings panels) are candidates for upstreaming so the next install inherits them.
• Presentation (your theme, layout, fonts) lives only on your volume and stays yours.
• /recover resets the shell when the agent paints itself into a corner.
• Source on GitHub; deploys in about three minutes.

You grow it from a chat input

Möbius starts as almost nothing: a chat on one side, an empty canvas on the other. No file upload, no scheduled jobs panel, no notifications button. What makes that interesting is that the agent can rewrite the thing it runs inside. So you grow it. Ask for file upload and it builds file upload. Ask for a new look and it restyles itself. Ask for an app and one appears on the canvas. The shell you end up with is the one you talked into being.

Here is one of those moments, end to end. I sent a deliberately ordinary prompt. “I’d like to send files and images along with my messages, pictures of stuff I want to talk about, the occasional document. Can you add file upload to the chat?” One conversation later there was a backend route, message storage, drag-and-drop, and image rendering, none of which existed when I asked.

The flip side: you can break it

The same power cuts both ways. Tell the agent to delete an app and it deletes it. Tell it to rip out a feature and the feature is gone. You can repaint the shell until the composer is hidden, restructure the navigation until the drawer is unreachable, paint yourself into a corner. That is not a flaw. It is the point. An interface you can grow in any direction is, by construction, an interface you can also break.

What makes that safe is that breaking is cheap to undo. /recover bounds the blast radius. It resets the shell to its seeded baseline while keeping your chats, your apps, and your data. It renders from a separate server-side codepath the agent does not edit, so it survives even a shell rewrite that hides everything else. Grow in any direction, break it, recover, try again. The goal is maximal personalization, software that bends to you instead of the other way around.

Why I built this

Most software asks you to adapt to it. AI assistants make this worse with time: preferences leak between tasks, memory accumulates in the wrong places, the thing that was helpful yesterday becomes an invisible constraint today. The model in front of you is usually capable of writing the tool you want, but the product around it can only talk about the tool. You ask for a workflow and get advice. You describe a tool and get a mockup, a snippet, or a plan. The assistant stays on one side of the glass.

The premise of Möbius is to put it on the other side, to shorten the distance between wanting, making, using, and correcting until they happen in one place. Requests become software, software becomes context, the next request lands somewhere sharper. The platform has to be editable for that to work. If the agent can only talk about the work, you still have to carry the system in your head.

The name is from Möbius strips. Each app the agent builds does not sit somewhere external; it lands in the shell the chat lives in, and becomes part of the surface the next conversation happens on. The shell the chat runs in was, once, written by a different version of the same chat.

How it works

The most obvious adaptive surface is the apps the agent builds. The interesting surface is everything around them, and it splits along a useful axis: capabilities (general features like file upload or notifications, candidates for upstreaming so the next install inherits them) and presentation (your theme, layout, fonts, which live only on your volume and stay yours). The harness treats those two stacks differently.

Capabilities: the part that grows the platform

Walk through that file-upload chat from the top. The order is the point.

ask for file upload

→

answer a few questions

→

file upload, working

File upload is one capability the agent can build. The same loop produces apps, too, actual mini-applications that land on the canvas next to the chat and persist there.

This is how general capabilities land (notifications, scheduled jobs, a web-search button, voice mode, a richer settings panel). The agent builds it when you ask. A second loop sits above the first, a harness that watches the inner agent and periodically asks was this change generally useful, or was it just for me? The generally useful diffs become candidates for upstreaming into the shipped image, a promotion step I still review.

Presentation: the part that stays yours

Capabilities are general; taste is the opposite. The shell ships with one default theme, but the same agent that built file upload can rewrite the CSS, swap fonts, add background animation, restructure the layout, and that diff lives only on your volume. A redeploy can ship you the new file-upload feature without trampling your wood-paneled reading-room theme, because the two changes live in different layers.

The cheap-to-vary axis is visual. Ask the agent to restyle the whole shell and it rewrites the CSS, swaps the fonts, and repaints the background. There is no build step you wait on. The new look is live the moment the agent saves, and you watch it change as it works.

The harder axis is layout, where things are, not how they look. It is the same conversation and the same chat box. Ask the agent to rewrite the navigation model and it does, and the new layout is live immediately, the same way a theme change is. The default is drawer-first; one prompt later it is a bottom-nav app with Chat / Apps / Settings as tabs.

Chat

Apps

Settings

The reshaped Settings tab is also where the provider choice lives. The same settings panel switches the coding agent between Claude Code and Codex, with Gemini for image generation. The next message in any chat uses the new provider. Different models have different tastes (Codex tends to be terser, Claude tends to spell out its reasoning), so you can pick the one that matches what you are building, or switch mid-thread if a turn goes sideways.

The same plainness applies to app data. Apps store data through a small storage primitive the agent already knows how to compose. New schemas, scheduled jobs, webhooks are the plumbing you would write yourself, except you describe it instead.

Recovery, so you can be fearless

An agent with write access to its own interface will occasionally ship a CSS rule that hides the composer, a layout change that makes the drawer unreachable, or a theme that paints text the same colour as the background. That is the cost of an interface you can reshape this freely, and it is a cost worth paying as long as it is reversible.

/recover is what makes it reversible. It resets the shell to the seeded baseline while keeping your chats, apps, and data. It renders from a separate server-side codepath the agent does not edit, so it survives even a misbehaved shell rewrite. The whole point of the route is to let you grow the thing without fear. Any change you make is one you can roll back, so there is no edit too bold to try.

The agent is the server

Step back and the loop closes. Möbius is one container you self-host. The agent inside it is not a chat bolted onto a finished product; it is the server. It builds the tools, edits the interface those tools sit in, runs scheduled jobs on a timer, fetches from the web when an app needs fresh data, and stores everything on a machine you control. The same thing that answers your message is the thing that ships the feature, mounts the app, and reshapes the shell around both.

That is what makes the personalization compound. Requests become software, software becomes context, the next request lands sharper. Because the server is the agent, every app you grow and every layout you reshape is one more thing it can build on next time. The more you use it, the more it is yours.

What’s next

Memory is the next thing to take seriously. The experience file the agent appends to is a linear log, enough to make my instance diverge from yours after a few months, but it does not reorganise, and it shows. Four directions:

• A knowledge graph. Structured memory growing from every interaction, separate from the chat transcript, so the agent can reason about your patterns without re-reading every conversation.
• Dreaming. A scheduled background pass that consolidates and reorganises the graph while you are away. Anthropic previewed something similar for managed agents; the Möbius version is the self-hosted, user-controllable one.
• Discretion. Noticing stale apps, suggesting something worth learning, asking before interrupting, proactive in service of the user, not engagement.
• Help that seeks you out. The part I want most and am least sure how to land. An agent that notices you have been reading distributed-systems papers three Tuesdays in a row and builds you a swipe-style recommender, without being asked. Most products in this space are tuned to maximise engagement; the goal here is the opposite, a system that shows up because it knows you, not because it is trying to keep you.

None of those ship yet. The loop that makes them possible is the subject of a companion post on the self-improvement harness, an outer agent that watches the inner one build, asks it questions, and rewrites its instructions to make it less brittle next time.

A note on the agent itself. For the iteration work behind this post I have been letting Claude drive Codex through its Codex plugin. The disagreements between the two models were the useful part. When they pulled in different directions on an edit, that was usually a sign the edit was worth a closer look.

Since this was written, the apps the agent builds grew a place to live: an app store, and the start of an operating system around it where you install, update, tweak, and recover apps on your own instance. That is its own companion post.

The source is on GitHub, the project page is here, and the README’s deploy button gets you a working instance in about three minutes. I would love to know what you build with it, and what you change around what you build.

TL;DR. EEML came to Bosnia for the first time in 2025: 350 participants from around 50 countries, hosted under one roof in the hotel built for the 1984 Winter Olympics. The harder story is the one about ANNT, the local science-and-tech association we’d been growing from a small STEM camp, scaling its logistics fast enough to handle a full international summer school in under a year.

Bringing EEML to Sarajevo: A story about chairs, ćevapi, and controlled chaos

It’s been a couple of weeks now since the Eastern European Machine Learning Summer School wrapped up in Sarajevo. I’ve had some time to unwind, reacquaint myself with the concept of a full night’s sleep, and finally try to put into words what was, frankly, one of the most intense and rewarding projects I’ve ever been a part of.

Bringing a major academic event like EEML to Bosnia had been a quiet dream of mine for quite a while. I remember seeing an internal DeepMind post (back in the good old Slack days) about EEML around seven years ago and I immediately thought how amazing it would be to have something like this in Bosnia. A year or two prior, I had co-founded the Association for Advancement of Science and Technology (ANNT in Bosnian) and organizing a major science conference was something we were slowly building toward as it aligned perfectly with our mission. We started from the ground up with a local yearly STEM youth camp and since then grew it to host around 80 college students. Honestly, I assumed our path would be to grow our own event over time. I never imagined that, in such a short time, we would be partnering to bring an event of EEML’s scale home.

So, how did it happen so fast? Even after joining the EEML team in Serbia last year, the dream of hosting in Bosnia still felt at least a few years away. But, as luck would have it, the reinforcement learning keynote speaker had to cancel, and I stepped in at the very last minute. The talk was a success, and in hindsight, I believe that moment gave the team that extra bit of confidence needed to greenlight EEML in Sarajevo this year.

The gentle art of persuasion

After returning from last year’s EEML in August, I had no idea a chance for Bosnia would come so soon. There’s an unwritten rule that a country hosts a workshop a year prior to test the waters, and when discussions began in November, Croatia seemed like the natural next step. Matko had been part of EEML for a few years and they’d already held a workshop in Zagreb. However, Matko was also working to bring the Mediteranean Machine Learning Summer School (M2L) summer school to Croatia. Since that plan worked out, hosting a second major event was no longer feasible for them, which suddenly put EEML 2025 on the table for Bosnia.

Our local team from ANNT was super excited, but we had to show that we (since I’m the only local and non-local organizer 😅) could handle the logistics from scratch. We needed to prove we could sort out the venue, accommodation, and food for around 250 people (at the time 😆) and that there was enough local interest to make the event both successful and valuable for the community.

We made our case, got the green light in December, and my entire year was suddenly mapped out. From that moment on, it was full steam ahead.

In hindsight, I do have to admit I might have overestimated the local community’s readiness a little. With ANNT, we had just finished a project to map out the AI landscape in Bosnia, and on paper, it looked like a lot was happening. The reality was a bit quieter, but thankfully, we still managed to bring out the best out of the local community.

The great venue puzzle

Our first big hurdle was accommodation. In the past, EEML participants were usually housed in student dorms, but the dorms in Sarajevo generally don’t have A/C, which was out of the question for a summer school in July. This forced us to look elsewhere, and we narrowed our choice down to two hotels.

We faced a trade-off: one hotel outside the city versus a more expensive one in the heart of it all. This choice added to the overall complexity and cost, but we decided that being within walking distance of the city center would provide a much better experience for everyone. We chose one of Bosnia’s most iconic hotels, built for the 1984 Winter Olympics. It was a pricier option that we had to subsidize heavily to keep things affordable for our participants.

With accommodation sorted, the next puzzle was the lecture venue. The university had one lecture hall large enough, but it lacked A/C. So we made another big decision: to host the lectures in the same hotel. It was more expensive and meant we had to figure out how to turn a conference hall into a proper lecture theatre, but it simplified the logistics slightly and created a better, more integrated experience. For the first time, EEML was organized in a hotel, with students and lectures under one roof. Is that how you scale it up?

The decision to go all-in on a pricier hotel and subsidize the accommodation had a major ripple effect. It meant we needed more sponsors. But EEML is not an event where anyone can simply buy a seat; it’s a prestigious school where admission is based on academic excellence, and we carefully curate both participants and sponsors.

To maintain this balance, for every new sponsor we brought in, we also had to accept more students. This created a cycle: more students led to higher costs, which in turn complicated the logistics and created a need for even more sponsors. It’s a delicate balance that can quickly get out of hand. And that is how our initial target of 250 participants ballooned to 350, making EEML 2025 the largest in-person edition to date, with participants from around 50 countries joining us in Sarajevo.

Top three logistical nightmares

As EEML approached, some logistical worries kept me up at night right until the very end.

• The Food: How do you feed 350 people, on a budget, without just serving dry sandwiches? Our friends at Zmaj, a fantastic local restaurant, became our unsung heroes. They’re famous for their ćevapi but completely transformed their operation just for us. They closed off the main part of the restaurant for a week, cooked whatever we needed, and worked at practically no profit. Their support was incredible, and frankly, they were the only partner who could tick all our boxes, even if it resulted in some long queues (as the memes below will attest).
• The Chairs: This one still makes me laugh. The hotel’s conference hall was big, but their table setup could only fit 250 people. We needed to avoid tables and get our hands on chairs with those little fold-out tables for laptops and notes. After searching all over the city, we found exactly one institution that had them in the quantity we needed: the Sarajevo School of Science and Technology (SSST). They generously lent us over 350 of them, but we had to transport the chairs ourselves. This involved one truck, two trips, and a team of volunteers (myself included) loading and unloading every single chair. Twice. To add a perfect, chaotic cherry on top, on the return journey, a car crashed into our truck, blocking traffic on one of Sarajevo’s busiest streets for nearly two hours. You just can’t make this stuff up.
• The Internet: Anyone who has run a technical workshop knows that bad Wi-Fi can ruin everything. We were especially paranoid because the tutorials required students to download model weights, and the hotel’s internet had a questionable reputation. Thankfully, our platinum sponsor, BH Telecom, stepped in as our savior. They installed a dedicated high-bandwidth fiber line just for the event. We still had a few hiccups on day one, so we also had the hotel max out their own provider’s bandwidth. With two networks running in parallel, we were finally safe.

Going the extra mile (sometimes literally)

Beyond the big three, there was a mountain of smaller challenges leading up to and during EEML. Renting poster stands in Sarajevo was almost as expensive as buying new ones in Mostar, so we bought our own. Then a construction site popped up right in front of the hotel without any warning. We had to constantly monitor the work, especially when they fired up a machine that was literally shaking the entire hotel. And, of course, the noise peaked during one of our most anticipated lectures. 🫠

Throughout EEML, we also tried to add personal touches that went beyond the academic program. We wanted participants to feel looked after from the moment they landed, in the spirit of Eastern European hospitality. This also led to one of our biggest organizational hurdles: picking up every single participant from the airport. It was a massive effort, and yes, even I was playing taxi driver. On top of that, we dealt with a constant stream of small crises, like the A/C failing in a tutorial room, that our team would immediately jump on to fix. It was these small constant interventions that were crucial in making the week run smoothly.

The week itself was a marathon with daily lectures, tutorials, and a packed social schedule with welcome drinks, poster sessions, and a gala dinner. Thursday was usually a half-day off, but this year we decided to organize a trip to the Tunnel of Salvation museum and a guided city tour. The day was further enriched by a brilliant Estimathon competition organized by Jane Street and evening drinks hosted by Credo VC. While the participants networked, the organizers, speakers, and TAs snuck off for a quiet dinner of our own. A well-deserved moment of calm.

The last day was shorter, with final lectures and student project presentations. We handed out certificates, including the much-anticipated best meme award, and had to wrap things up a bit sharpish as the hotel had a massive wedding booked for that evening.

The aftermath

Hosting around 350 people from around 50 countries in my hometown was surreal. I’m so incredibly proud to witness ANNT grow from a handful of science enthusiasts into an association capable of successfully organizing a 350-person international event. I feel so happy to be part of a community that made an event like this a huge pleasure for everyone who attended and presented our country in the best of lights. We heard from so many people how they can’t wait to be back, and from some, how it was a life-changing event. That’s the best we could have ever hoped for!

Of course, this would have been completely impossible without the army of people who helped make it happen. A huge thank you to:

• The core EEML team for bringing everyone together and for their passion in fulfilling EEML’s mission.
• The amazing speakers, tutorial leads, and teaching assistants who shared their invaluable knowledge and time.
• The entire ANNT team and our volunteers, who did so much of the heavy lifting and went the extra mile to make sure everything ran smoothly.
• Our sponsors, whose continued financial support is making EEML possible.
• BH Telecom, SSST, and Zmaj, for stepping up to help solve some of our main logistical challenges.
• The many Friends and Supporters who provided help along the way, especially SO.. quantum marketing agency, for the great work with the media outreach.
• The participants for bringing their enthusiasm, questions, memes, and the energy that makes every EEML super special.

This last year was not what I had in mind a year ago. But I like to say that most often we don’t get what we plan for, but with the right mindset, we end up with much more. This experience was certainly that for me!

I’ve tried to capture a small fraction of the EEML 2025 story here, but there were 350 other stories unfolding that week. I’d love to hear yours!

And if bringing science and technology communities together is something you’re passionate about or you’d like to get involved with ANNT, please don’t hesitate to get in touch!

TL;DR. I moved my eight-year-old WordPress-on-DigitalOcean robotics-tools site (mesh cleaner, model viewer, IKFast generator) to a containerized Cloud Run setup. About fifty people a month still use the tools, so the goal was preserving what works and future-proofing it, not rebuilding for its own sake.

During my master’s in robotics, I built a few small tools for the parts of model and robot work I kept doing by hand: mesh cleanup, 3D model viewing, inverse-kinematics generation. I Dockerized them and exposed them via WordPress on DigitalOcean, originally as a way to tighten my own research loop, then opened up because a few other people seemed to want them.

Eight years later, the site was still running. To my surprise, over fifty people a month still used the tools. It was time to give the site some attention, without disrupting existing users.

What started as a cleanup became a migration to Google Cloud Run. Each tool was already containerized and stateless, so the move was mostly mechanical: I split the services into separate Cloud Run deployments, cleaned up the code, and put a budget guardrail in place that stops serving if my monthly budget is hit. The free tier on Cloud Run is generous enough that the tools should keep working for a long time without me touching them.

The original toolbox is still available, now as separate Cloud Run services with the same URLs.

Find the tools under Projects:

• 🔧 Mesh Cleaner Clean and process 3D mesh files for physics-based simulations.
• 🧿 Model Viewer Visualize 3D models and robots directly in your browser.
• 🤖 IKFast Generator Generate analytic inverse-kinematics solvers from .dae files using OpenRAVE’s IKFast.

These tools were the part of my master’s I went back to constantly: computing inertial properties for dozens of objects, cleaning up meshes for simulations, and later, during my research assistantship, generating inverse-kinematics solvers for robot manipulators. Worth the time it took to package them properly back then.

If you’re still using any of these, thank you. I hope the migration went smoothly. If not, feel free to reach out and let me know what’s broken.

For nostalgia, here’s a little album of the old site: