Google Agentic Skills: Survey, Engineering Practices & Lifecycle Framework

Introduction: The Gap Between Skill Files and Reliable Agent Capabilities

Teams that have written SKILL.md files often experience a gap: the file works initially, but weeks later skills misfire, become undiscoverable, stall in intermediate states, or silently break due to API changes. The file remains, but the capability is no longer reliable. Google's recently published Agent Skills production process and a survey paper on Agentic Skills (with Google team participation) address this gap from two angles: an engineering retrospective on how skills are produced, tested, and maintained, and an academic framework that formalizes skills as a six-tuple and a nine-stage lifecycle, integrating discovery, routing, execution, evaluation, and safety.

Survey Defines Clear Boundaries

The survey's first contribution is a formal definition of a Skill as a six-tuple: Activation Condition (A), Process Instructions (I), Applicability Constraints (C), Tool Interface (T), Execution Policy (π), and Expected Effect (E). This formalism provides a checklist: a skill with only descriptions but no trigger and effect is closer to a Prompt; only interfaces without process is closer to a Tool; only stored history without execution logic is closer to Memory.

The survey establishes three criteria for a true Skill:

Encapsulated Modularity : Skills are independent external assets that can be authored, versioned, validated, and updated without changing model weights or global harness code.

Late-Bound Dynamic Loading : Skills do not reside permanently in context; they are loaded on demand based on current state and goal. System prompts are injected at session start, while skills appear only when needed.

Procedural State Transition : Skills encode operational knowledge — how to do something — including error handling and control flow, rather than recording facts or preserving history.

Applying these criteria clarifies many gray areas. A global JSON instruction is not a skill (lacks modularity and on-demand loading). A search API is not a skill (lacks process orchestration). But an API wrapper with timeout retry, cache fallback, and DOM parsing logic qualifies as a "tool execution skill". A conversation record is not a skill (no execution logic).

The survey also formalizes security constraints: a skill activates only when its declared tool set is a subset of the currently allowed tool set; otherwise it constitutes privilege escalation. This turns "whether a skill may use a tool" from a verbal agreement into a checkable condition.

Google's Engineering Practice: Skill as a Continuously Maintained Process Asset

While the survey answers "what is a skill", Google's engineering practice shows "how to do it". Google's skills are not isolated documents submitted by individuals. They live in a unified directory with automated checks, submission-time evaluation, weekly quality reviews, and long-term ownership. A Repo Maintainer governs common repository rules; a Skill Owner is responsible for evolving a specific skill alongside product, API, and evaluation changes.

This resembles conventional software engineering but is especially critical for skills. Expired documentation merely causes extra reading; an expired skill can make an agent call the wrong tool, miss a precondition, or execute an obsolete flow.

A core architectural principle: prefer remote MCP tools; CLI and API calls are fallbacks. Remote MCP servers integrate more easily with unified authentication and IAM-level permission governance, making them better suited for long-lived runtime environments. This aligns with the survey's "security governance" stage — a skill's tool declaration is both a functional description and a permission boundary.

Export rules are noteworthy. Skills are built and validated internally; only after passing criteria are they published to GitHub via automated rules that strip internal assets, owner information, and evaluation suites. The same skill thus has two shapes: internal and public (a sanitized facet).

Evaluation goes beyond correctness. Token consumption, latency, and whether gains hold across runtime environments are measured. Google uses a 2×2 matrix of accuracy and efficiency to judge whether a skill truly improves outcomes. A skill that makes results look more complete but increases call cost and retry rate may not be an improvement.

From an engineering perspective, a skill is a process asset requiring continuous maintenance, not a one-off prompt . Ownership, versioning, test cases, and retirement mechanisms follow naturally.

Nine-Stage Lifecycle: A Chain Not Yet Fully Closed

The survey divides a skill's full life into nine stages: Autonomous Discovery, Authoring & Representation, Memory Storage, Dynamic Retrieval & Routing, Composition & Orchestration, Execution & Repair, Lifelong Adaptation, Experience Evaluation, and Security Governance.

Google's engineering practice covers most stages, but "Security Governance" and "Lifelong Adaptation" are still evolving. Compressed into a runtime view, the chain becomes:

Discovery & Routing → On-Demand Loading → Constrained Execution → State Update → Result Verification → Version Governance

Harrison Chase describes the harness as "the orchestratable execution shell around the model" — it determines not what the model can say, but which information enters the model when and how, and how model outputs are validated and grounded. The degree of skill engineering ultimately depends on whether this loop is closed, not on how many SKILL.md files exist in a directory.

Andrej Karpathy on context engineering: the hard part of industrial LLM applications is not writing a prompt, but fitting task description, reference material, tools, state, history, and compressed results appropriately into the next context. Simon Willison on Claude Skills: the significance of skills is not giving the model more text, but turning "what is needed when" from ad-hoc judgment into reusable configuration.

Skill is a versionable carrier for Context Engineering, but it cannot replace the Context System or the Harness. This explains two seemingly opposite trends: one emphasizing Markdown, files, and on-demand retrieval; the other emphasizing structured state, event streams, and strict execution protocols. They are not debating "text vs structure" but handling information at different lifecycle stages. Experience must be human-readable, editable, and auditable; current state must be machine-verifiable, mergeable, and recoverable; execution evidence must be archived, while transient reasoning can expire.

Overlooked Details in the Survey

Three points deserve attention:

Security is not an add-on chapter but a cross-lifecycle concern. Natural language instructions are injection entry points. Malicious skills can carry backdoors, steal credentials, bypass guardrails, and risks propagate across lifecycle stages. Defense operates at three layers: pre-admission static audit, runtime guardrails, and market governance (cryptographic provenance signatures). Reality: skills cannot be fully verified before invocation, which is why security remains hard to solve once and for all.

Skill libraries accumulate technical debt. The survey mentions SkillOps' five-dimension health governance: pruning low-value skills, repaying "skill technical debt". Conflicting trigger descriptions, duplicate processes, expired links, broken scripts, unmaintained owners, ever-growing reference catalogs — these are essentially the same as code repository technical debt. Quantity growth ≠ capability growth; discoverability, executability, and provable effectiveness are truer metrics.

Skill benefits are conditional. The survey cites a negative result: procedural skills yielded zero gain on cybersecurity CTF tasks. The authors propose an "environment feedback bandwidth hypothesis": when the environment itself provides rich diagnostic information, the marginal benefit of external skills diminishes. Skills are better suited for tasks with sparse environment feedback, high trial-and-error cost, and strong domain constraints — not every task deserves a skill.

WikiSkill and SKILL.state: Two Puzzle Pieces Completing the Lifecycle

The survey provides the full framework; two papers published the same day fill the "Lifelong Adaptation" and "Execution & Repair" stages.

WikiSkill addresses the production side. It inserts a persistent Wiki between execution traces and executable skills:

Execution Trace → Experience Pattern → Skill Proposal → Validation Gate → New Version Skill

The clever asymmetry: skills can roll back; the Wiki never rolls back. Failed proposals with rejection reasons remain in the Wiki, so future proposals can see "this direction was tried and why it failed". Skills are fallible hypotheses; the Wiki is settled knowledge — knowledge should not be zeroed out because one hypothesis failed.

The paper also found that evolved skills can let smaller models outperform larger base models on some tasks (a 9B model beat a 27B model in experiments). However, cross-model transfer can fail: small-model skills packed with model-specific workarounds degrade performance when given to stronger models. General procedural knowledge transfers; model-specific patches may cause negative transfer. This directly impacts maintenance strategy: when writing skills, distinguish domain-general knowledge from model-specific patches.

SKILL.state addresses the consumption side. It restructures execution as explicit state transitions: each step feeds the immutable skill description, structured current state, and latest environment observation to the model; the model returns a state patch and action; the runtime validates the patch, merges a new state, and discards that step's reasoning history. Single-step prompt length stays O(1), cumulative tokens drop from O(T²) to O(T).

This boundary matters but cannot be overstretched. The paper assumes structured state suffices for the next decision. If a task requires reviewing the full trajectory for audit, or an early observation only becomes important much later, discarding history may lose information.

A state machine does not mean "history is unimportant"; it demands that the system explicitly define the minimal sufficient state required for future execution.

Six Questions to Bring Back to Your Project

Instead of counting pages in a skill file, teams now ask six questions:

Under what conditions is it triggered, and what are the costs of false positives and false negatives?

What are the inputs and outputs, and which information must return to an authoritative system for confirmation rather than trusting contextual memory?

Which actions can be deterministically handled by scripts or tools, and which judgments still require model involvement?

After a mid-execution failure, how does the system proceed? Which side effects are retryable, and which require result verification before retry?

What evidence confirms "completion", and who has authority to override the model's completion judgment?

Who owns maintenance, how is it evaluated, and when is it downgraded, rolled back, or retired?

This is not a writing checklist; it reflects the unavoidable responsibility questions when skills are placed back into software systems. Different teams will answer differently, but if several items remain unclear, the skill likely remains stuck at "instructions for the model".

High-repetition, well-bounded, verifiable processes are good candidates for skillification. One-off exploration, rapidly changing facts, or tasks lacking acceptance criteria — forcing these into skills may solidify temporary judgments into erroneous rules. Aaron Levie noted publicly that as models handle more of what engineering scaffolding used to do, architecture needs continuous editing, not just layering.

Future Architecture Diagrams

Google's practice and the survey, one from production, one from academia, point the same direction.

In future Agent architecture diagrams, Skill will no longer be drawn as an isolated file icon. It belongs in the continuous loop of discovery, loading, execution, verification, and update.

How experience is distilled, how knowledge is stored long-term, how skills are routed, how state progresses, how permissions are scoped, how results are verified, how failures are recovered — missing any piece, a skill easily degrades into a "seems knowledgeable" prompt. Once the boundaries connect, a skill has a chance to become a truly reusable engineering asset: loadable, replaceable, delivering experience compounding, rollbackable on validation failure, helping the model act without handing over permissions, facts, and completion standards to the model.

References

Google Cloud: Behind the scenes: How we build, test, and scale Google Agent Skills (https://cloud.google.com/blog/topics/developers-practitioners/behind-the-scenes-how-we-build-test-and-scale-google-agent-skills/)

Google Skills GitHub repository (https://github.com/google/skills)

Towards a Systems Foundation for Agentic Skills: Architecture, Lifecycle, and Security (https://arxiv.org/abs/2608.29596)

WikiSkill: Compiling Agent Experience into Persistent Knowledge for Skill Evolution (https://arxiv.org/abs/2608.27454)

SKILL.state: Scalable Long-Horizon Agent Skills (https://arxiv.org/abs/2608.26263)

Andrej Karpathy: Public discussion on context engineering (https://x.com/karpathy/status/1937902205765607626)

Simon Willison: Claude Skills are bigger than MCP (https://simonwillison.net/2025/Sep/12/claude-skills/)

Aaron Levie: Public discussion on professional capabilities and architectural trade-offs in the Agent era (https://x.com/levie/status/2006521312693637597)