MWS cut AI agent startup from 37.6 to 16.8 seconds: a harness teardown

While some developers tune a local harness on a laptop, others are already shipping one to production for thousands of users. A Habr author went to the MWS meetup “Russkoe Tekhno 2” and wrote up what happens when the scaffolding around a model has to scale. The main points are below, with a caveat: the figures come from the speakers, and they cannot be verified independently.

The harness is almost everything except the model

A bare LLM is a black box: it takes text in and puts text out. It has no memory, no exact arithmetic and no self-checking. By the speakers' definition, an agent equals a model plus a harness. The harness is the prompt, context and memory, tools, the action loop, checks, constraints and orchestration.

What does that difference look like in practice? An architect at MWS gave a code review task to Opus and got three minor comments. The same task on DeepSeek with a harness produced about 50 comments, 25 of which needed attention. In other words, a “mid-tier” model in a good harness beat a strong model in a plain one.

A few lessons from the talk:

• Context is everything. The model rereads the entire conversation from scratch, and the longer it gets, the worse the answers. The fix: compress the history, load what you need through subagents, or move data into files.
• More tools is not better. At Vercel, an agent with 17 tools got one task in five wrong. After the set was cut to the four that mattered, tasks passed 100% of the time.
• Errors compound. At 99% accuracy per step, a 10-step chain runs clean 90% of the time, and a 50-step chain only 60%. That is why you need tests after every change and a spec for the task, for example in OpenSpec.

The 2026 trend is a harness that edits itself. A tuner reads session logs, finds recurring failures and adds rules. In an MWS example, the agent handed in work without tests in three of six sessions. The tuner added a “don't submit without tests” hook, and the next day all six sessions passed with tests.

Where the 37.6 seconds went

The “Digital Employee” project is a personal concierge agent in Telegram and Max with 30+ skills. Under the hood, each user gets their own pod in Kubernetes running OpenClaw or Hermes. Users waited 37.6 seconds on average for the first reply, even though the model's answer itself took 2.3–4.5 seconds.

The time went to infrastructure:

• 4 s — the operator deploys the agent manifest to Kubernetes;
• 10 s — attaching the disk to the node;
• 5 s — mounting the disk in the pod;
• 5 s — initializing containers;
• 9.5 s — loading the agent Gateway;
• 3.1 s — readiness check;
• 1 s — delivering files.

The team chose a pre-warmed slot architecture: the heavy preparation happens in advance, and the user waits only for the launch. MWS rejected the alternatives: a pod per user takes too long to start, a MicroVM per session is hard to operate, and a shared dispatcher takes everyone down when it fails.

The chain of optimizations went like this:

1. Moved pod startup and key delivery into the slots: minus 4 s, leaving 33.6.
2. Switched from block disks to CephFS shared storage: minus 15 s, leaving 18.6.
3. Pre-warmed the containers and agent modules: a gain of only 1.8 s, because slot pinning and agent wake-up added their own delays.

The result: 16.8 seconds. The target is 6–8, but getting there will mean digging into the agent's code and possibly forking it.

The price of speed

Every step made the system more complicated. It needs a slot registry on PostgreSQL, events from Kafka, and a guarantee that a slot freed by user A never goes to user B. The main problem is the shared disk: in the current setup, slots see a common root, and because of permissions a user could theoretically see their neighbors. The fix is to mount a subvolume by key, but that will require a separate service.

Files in the agent's workspace were split into five areas: managed (by the registry), protected (profiles, do not touch), runtime, user-owned and seed (delivered once). The rule is simple: you may update and delete only your own files.

Another pain point is when to put the agent to sleep. Right now it is time-based: 30–35 minutes after the user's last activity, or 5 minutes if a Cron job woke the slot. Without access to the runtime, there is no way to tell “gone” from “thinking about a reply.” The team is testing a hypothesis with a fast model that decides in 0.5 seconds.

What to take from this

If you are building agents for many users, measure time to first reply separately from model run time. Chances are your problem is in the infrastructure, not the LLM. Do not bloat the tool set, and put checks inside the loop. Plan data isolation up front: shared storage speeds up startup but turns access rights into the main risk.

A limitation of the source: the text breaks off at a talk on deploying AI in organizations and assessing business impact, so there is nothing to say here about measuring payback. Some claims (for example, about Google Research Harness 2) are given without sources and should be treated as the speakers' statements.