Claude Sonnet and the Jarvis Pattern: Why AI Agents May Need Nothing More Than an Operating System

A text published on Habr proposes a radical simplification of the conversation about AI agents. Instead of frameworks, graphs, orchestrators and vector databases, the author puts forward a formula: LLM + operating system + files. His point is that a modern model is already strong enough to use a terminal, APIs and a file structure much as an engineer does. The bottleneck, then, is not how much scaffolding surrounds the agent, but how its memory, access rights and working environment are designed.

The concept's author, IT architect Egor Zinoviev, describes the Jarvis Pattern as a personal networked agent assigned to a specific specialist. Such an agent lives neither in a browser nor on a laptop, but in its own container with access to infrastructure, and acts on the person's behalf. As an example, he cites his DevSecOps agent umax, built on Claude Sonnet, which by his account covers the full range of relevant tasks: from configuring RBAC in Kubernetes and working with Vault to deploying clusters, scanning Docker images, setting up CI/CD and analyzing vulnerabilities.

The key thesis is that the agent does not need a pre-assembled zoo of tools. If it needs to query Prometheus, it uses curl; if it needs to transform data, it picks up jq, sed or awk; if no suitable utility exists, it writes one itself and adds it to its working environment.

Memory gets particular emphasis. In the author's view, it remains the only truly unsolved part of agent architecture. He proposes splitting it into declarative, procedural and episodic memory: facts, instructions and experience. Negative experience matters as much as success: knowing which path already led to a dead end, and why.

Instead of vector search and graph models, Zinoviev bets on the file system and markdown files as a natural map of routes. Folders define categories, file names indicate direction, and an index document serves as the starting point for diving into the right context. A separate Memory Agent should run in parallel; after each session it decides what to save, what to update and what to discard.

This scheme leads to a broader view of the human's role. The Jarvis Pattern is not about fully autonomous AI but about augmenting a specific engineer: the human sets the task, checks the result and makes decisions under uncertainty, while the agent takes over execution and routine. The author believes this model could change hiring, because candidates could be assessed not by abstract questions but by how they work with an agent on a real case. The article even cites enterprise-market benchmarks: a hiring cycle of 40–60 days, the cost of a bad hire at tens of percent of annual salary, and a noticeable share of employees who do not make it through their first year.

Another practical conclusion concerns software: if an agent works through APIs and CLIs, products without a proper API will start to lose out, no matter how attractive their interface is.

Although the text is framed as a manifesto, the author stresses that he does not see himself as a lone voice. As support, he points to similar ideas from other engineers and to products in which the agent is already seen as an operating environment for a specialist rather than a chat with a set of buttons.

In this sense, the Jarvis Pattern is neither a ready-made standard nor a new platform, but an attempt to pin down a shift: part of the industry is starting to see the AI agent not as a standalone application but as a control layer over existing infrastructure. If this logic takes hold, the main debate around AI agents will move from choosing a framework to designing memory, access rights and API-first tooling. For teams, that means less magic in the architecture and more demands on the quality of context. For specialists, it means rising value for deep domain knowledge, which an agent can scale but not replace.