The transition from traditional software development to AI-driven systems forces a reevaluation of how we structure code. The primary obstacle to sharing Agent configurations is State. Agents capture specific user constraints, personalities, and "vibes," making them rigid and difficult to reuse. To scale, we must decouple the structural logic of the Agent from the specific context of the user.
The focus is shifting from "Software Engineering" to "System Architecture." Classically, this was treated as a logistical exercise involving defining database schemas, selecting languages, and assembling technology stacks. However, I hold a personal definition that is simpler yet far more generative in the decisions it enables me to make. It serves as a compass for the Architect, filtering out noise to focus on what truly drives system complexity.
To understand the challenge, we must stop viewing State merely as data storage. State is the entanglement of memory and compute. It is the source of inertia in any given codebase, acting effectively like mass that resists change. Yet, this resistance is necessary; it provides the "body" and intention of the system. State is the heart of the application and the fundamental variable that is acquired and spent to reach a specific coordinate in the design space. Trade off cheap Compute and Memory while strictly managing expensive State, and you can keep your codebase dynamic, learning and adapting to change.
The architectural shift from "Frameworks and Libraries" to "Agents and Skills" marks a distinction in components, not just terminology. These are not interchangeable. An Agent is a stateful entity analogous to a Framework, while a Skill is a stateless, reusable tool analogous to a Library.
Agents do not yet possess true autonomous agency. Today, an Agent is simply a persistent while loop acting as the Turing machine of the system. It functions as a controller, owning the logic and proactively calling functions, which are occasionally LLM calls. Crucially, the Agent is the "Center of State" for the system, acting as its Center of Gravity.
Conversely, a Skill is a structured, stateless knowledge package. It follows the Unix philosophy of input, processing, and output to teach a model a workflow without retaining user history. This structure comprises three parts: the Context or "brain" in SKILL.md, the Tool defined by a rigid JSON Schema, and the Execution runtime. When an Agent invokes a Skill, it transfers the Center of State to the LLM call, which in turn may transfer it to another recursively called Skill.
This distinction resolves architectural confusion by separating concerns based on where memory lives. Agents hold Contextual State, which implies information specific to the product, user, and session that is heavy, personal, and non-portable. Skills hold Functional State, or the information required to use the tool itself, which is light, generic, and portable.
Instead of the Center of State remaining fixed at the Agent scope, a skill based architecture becomes dynamic packets of contained State akin to function closures. Hoarding all the state above the While loop is tantamount to Architectural Cowardice! The genius of Skills lies in controlling the duality of LLMs. The unreliability is mitigated by traveling with part of local state expressed in rigid code that serves as a guardrail. At the same time making full use of the dynamism of LLMs and their fluid intellect using the text part of the local State packet. The apt metaphor is a space ships use of its own mass to perform a gravitational slingshot where mass is now an asset rather than a libility.
The ideal workflow prioritizes specifying and writing Skills first. By forcing yourself to strip away user context to create a valid Skill, you ensure reusability from the start. These Skills become the foundation for any future Agent, valid well beyond the context of the single application for which they were built.
Claude Code appears to be the first architecture to fully internalize this physics, reflecting the distinct character of the principal engineer Boris who is driving it. I have observed the derision it faces in the wild, such as YouTube comments mocking a "packed audience to listen to people talk about .md files" or claims that "the emperor has no clothes" because the tech seems easily replicable. These critiques miss the structural genius of recursively calling skills. Making packets of local state for each skill to float on, recursively discovering and calling them, effectively outwits context windows and brings about seemingly long range intelligence. Managing state via Skills is not a feature like traditional software features; it is a protocol. As history shows, protocols have an unusual habit of being unreasonably effective compared to the raw effort that went into them.