WAM Agents: a personal AI-agent platform built by AI agents

Case study by Max Silenkov, Co-founder & CTO of We Are Magnets. As of October 2026.

WAM Agents is a personal AI agent in Telegram: every client gets an isolated container with its own memory, tools and choice of LLM provider. I designed the platform and took it to production, and over the last six months its code was written by AI agents that I orchestrate: 7.6 releases a day from May to October 2026, a median of 19 minutes from merge to release, and hundreds of isolated client containers on the fleet.

The problem

A regular chatbot on a shared server is not good enough for an agent that people trust with their email, documents and work. Three things are needed at once: per-client data isolation, freedom to switch models (providers change prices and limits every month), and a development speed that a small team without in-house engineers normally cannot deliver.

Architecture

One container per client. Each agent runs in its own Docker container with its own workspace. One client's data is physically out of reach for another client's agent.
Multi-provider. Claude, DeepSeek and Codex. A client can link their own ChatGPT subscription right in the chat via device-code OAuth and pick any model their plan includes. When a rate limit hits, the agent fails over to a standby account and retries the turn.
LLM broker. A shared layer between containers and providers: per-model quotas, token accounting, image and speech generation.
Memory. A scoped memory index (personal core, group, topic) with search across the full history and a log of shared files. The agent keeps context across sessions and never mixes up conversations from different groups.
Tools. Agent capabilities are plugged in through MCP; external services connect via managed OAuth, so access keys never land in the container.
Fleet. A scheduler places clients on nodes, adds nodes under load, puts idle containers to sleep and wakes them on the next message. Nodes converge to their desired state on their own: version, sidecar services, configuration.

AI-agent delivery pipeline

This is what sets the project apart. Over the period, not a single pull request was opened from a human's personal account.

A task is written as an issue: what, why, acceptance criteria.
An AI agent (Claude Code or Codex) implements it in a branch and opens a PR.
Codex reviews it and returns either safe or a list of findings; the agent fixes them and the loop repeats until safe. Median: 2–3 rounds.
Auto-merge lands the PR once review and CI are green. Database schema changes are merged by hand only.
release-please cuts the version and the changelog.
An e2e harness on test Telegram accounts runs a nightly smoke and a check before every fleet rollout; an issue is filed automatically on failure. PRs on critical paths pass e2e before merging.

DORA metrics, May–October 2026, across all platform repositories:

Deployment frequency: 7.6 releases per day (6.7 in April).
Lead time, merge → release: median 19 minutes (1.3 h in April). PR open → merge: 14 minutes.
Reverts and hotfixes: 0.26% of merged PRs.
P0/bug issue resolution: median 1.9 h.

By DORA standards, frequency and lead time are Elite. The formal change failure rate based on semver patches is higher, but that is a release-please artifact: any fix: commit produces a patch release, so reverts are the more honest measure.

Fleet migration to ARM

In September the whole client fleet moved from x86 nodes in the US to ARM nodes in the EU in two days without stopping the whole fleet: regular clients saw pauses of minutes. Node cost dropped by roughly 69% (estimate), with capacity headroom for growth. This required multi-arch images and client migration between nodes with rollback: moving one client takes minutes, with a health check at every step.

Scale

The fleet runs hundreds of client containers. Every agent release goes through the full e2e suite first and then rolls out across the fleet in a batch; containers busy with a conversation are never restarted mid-turn.

Incident: a new bot path in one day

In October Telegram restricted the previous way of issuing bots to agents, and new agent creation stopped. The next day a new path was in production via Managed Bots from Bot API 9.6: a client creates their own bot in one tap, and the agent attaches to it automatically. The scenario was covered by e2e before rollout.

My role

I am the architect and the decision owner: I frame the tasks, choose the architecture, set priorities and make the calls at forks — merging risky changes, rollouts, incident response. I have no direct reports; my partners at We Are Magnets run marketing and creative. The engineering team is the AI-agent pipeline that I built and orchestrate. Beyond the platform I own product decisions: pricing tiers, onboarding as data (changed without a release), a UI in any user language, and analytics on primary data.

Lessons

AI review works when its verdict is a gate, not advice. Auto-merge does not fire without safe, and a finding is fixed as a class, not as a single spot.
Speed rests on e2e, not on courage. Frequent releases are safe when real scenarios on real accounts stand in front of the fleet.
Cost is an architectural decision. Moving to ARM and putting idle containers to sleep cut costs in days, without rewriting the agent.
Platform dependency is a risk to keep in the plan. The bot incident was closed in a day because the pipeline can ship a new path the same day it is designed.
Humans are needed at the forks. Agents quickly build what is well framed; my job is to frame it right and to say "no" in time.

Contact

Max Silenkov — t.me/spacemax · linkedin.com/in/silenkov · me.silenkov@gmail.com