“How Artificial Intelligence and the Power of Nature Are Coming Together to Build a Greener, Smarter, and More Sustainable Future.”

What happens when the most powerful technology we’ve built learns to listen to the oldest systems on Earth?

The forest that has too much to say

Imagine a rainforest at 3 a.m. Thousands of insects are calling, frogs are overlapping in a chorus, and somewhere above the canopy a bird we have never catalogued is singing to a mate. All of it is data. For most of history, almost none of it was heard by anyone who could make sense of it.

This is the quiet problem at the heart of conservation: nature produces far more information than people can ever process. A single camera-trap project can capture millions of images. A single acoustic sensor can record for months. Scientists have not lacked curiosity; they have lacked ears, eyes and hours.

That is exactly what AI is good at. And it is why, in 2026, the question is no longer whether AI and nature will meet. It is how well they will work together.

Part 1: AI as nature’s tireless field assistant

The most immediate gains are unglamorous and enormous. Computer vision can sort camera-trap photos by species in a fraction of the time a human team would need. Tools such as BioCLIP can read traits from images to help identify species, and automated insect-monitoring platforms like Antenna have already helped identify hundreds of new insects, according to a McGill University study.

The tools are also looking in new directions. A model called TropiCam-AI, reported by Mongabay in May 2026, targets animals living in the tree canopy, a long-neglected blind spot in wildlife AI that mostly focuses on the ground.

And the data keeps compounding. Platforms like Movebank gather billions of animal location points, which lets researchers model home ranges and movement routes with a precision that was impossible a decade ago, from hummingbirds to pumas.

Then there is protection in real time. According to a WWF report, an AI-enabled monitoring system at Solio Game Reserve in Kenya, deployed in 2023, had recorded no new poaching incidents through 2025. One reserve is not a global trend, but it shows what happens when detection becomes faster than the crime.

Part 2: The wildest idea, learning to listen

Here is where the story turns almost mythical. The Earth Species Project, a nonprofit founded in 2017, is trying to apply the same family of techniques behind modern language models to animal communication. Its goal is nothing less than decoding how other species communicate, and it is working with biologists on crows, beluga whales and elephants.

Its flagship model, NatureLM-audio, is described as the first large audio-language model built for animal vocalizations. It was trained on a mix that includes human speech, music and environmental sound, with the hypothesis that patterns learned from human language can help reveal structure in non-human communication. Separately, Project CETI is using AI to study sperm whale calls.

It is worth being honest here: nobody is chatting with a whale yet. Researchers themselves describe the road as long, comparing it to the journey to the moon. But the near-term wins are real: separating one animal’s voice from a noisy soundscape, detecting species, and classifying call types across huge unlabeled recordings.

The deeper promise is emotional as much as scientific. People protect what they feel connected to. If AI helps us understand that a killer whale or an elephant is saying something, it may shift how much we are willing to do for them.

Part 3: AI that thinks like an ecosystem

Nature is not a list of species; it is a web of relationships. The most exciting work asks AI to model that web: predicting where habitats are about to change, spotting land-use shifts from satellite imagery, and quantifying the services ecosystems provide, such as clean water or pollination, so that protecting them can be justified in budgets and policy.

A 2026 horizon scan of conservation issues, published in Trends in Ecology & Evolution, flagged a hopeful frontier: low-power AI chips and tiny machine-learning models that could run directly on small field sensors. That means monitoring that does not need a constant internet connection or a power-hungry server, which matters in remote forests, reefs and savannas.

Part 4: The uncomfortable half of the story

A fair article about AI and nature has to include the fact that AI is made of nature’s resources.

A June 2026 United Nations University report found that global data centers used 448 trillion watt-hours of electricity last year, more than all but ten countries. It projected usage rising to about 935 trillion watt-hours by 2030, close to 3% of projected global electricity use. AI’s share of data-center energy is about 20% today and is expected to reach roughly 40% by 2030. The report also noted that most of AI’s power use, about 90%, comes from everyday requests rather than training, and that cutting the length of prompts by 30% could reduce the energy used by about 25%.

There is also a classic paradox: when something becomes more efficient, we tend to use more of it, so total consumption can still climb. And researchers point to a lack of transparency, since many companies don’t disclose what their data centers consume.

Other risks are closer to the field. AI systems can be biased by incomplete data, can produce confident but fabricated outputs, and, as reviews of the field warn, can lead to flawed conservation decisions or social backlash if deployed without safeguards. Monitoring that watches wildlife also records the people who share those landscapes, so privacy and community consent matter just as much as accuracy.

So what would “working together” actually look like?

The best version of this partnership is not AI replacing ecologists, rangers or Indigenous knowledge-holders. It is AI handling the overwhelming volume so that humans can do what only humans can: make judgments, build trust and decide what is worth protecting. A few principles seem to follow from the evidence:

Open and shared. Open-source models and shared datasets let small conservation groups use tools that would otherwise be out of reach, and make errors easier to catch.

Small and local. Low-power models running on the sensor itself reduce the footprint of the very technology meant to help.

Humans in the loop. Fabricated outputs and bias are manageable when experts and local communities check the results.

Honest accounting. AI for nature should count its own energy and water costs, not just its benefits.

Listening before acting. Understanding animals better is only valuable if it changes what we do for them.

The closing thought

For centuries, humans have looked at nature and asked, “What can we take from it?” AI gives us a chance to ask a different question: “What is it telling us?”

The answer depends less on the technology than on us. Used carelessly, AI becomes one more large machine drawing on a finite planet. Used wisely, it could be the first tool that helps us hear the living world clearly enough to finally listen.

When AI and Nature Work Together was originally published in The Ai Studio on Medium, where people are continuing the conversation by highlighting and responding to this story.

TL;DR

• Lineage tools usually rebuild their record from a scheduled crawl, so the graph describes a pipeline that has already changed.
• Snowflake’s own lineage views can trail query activity by up to three hours, and ACCESS_HISTORY needs Enterprise Edition.
• Fivetran’s 2026 benchmark estimates average monthly exposure from pipeline failures at $3 million, with incidents taking nearly 13 hours to resolve.
• A structurally valid change can still run four times slower, so lineage that tracks only structure shows it as healthy.
• Datameer compares job duration, result rows, result bytes and bytes scanned on the pull request itself, before the change merges.

Getting Started: What Data Lineage Records and Why It Falls Behind

A data pipeline is the chain of jobs that pulls data from its sources, transforms it, and delivers it to reports and models. Most data teams past a certain size no longer run a single warehouse. Snowflake, the cloud data warehouse, sits at the center, an orchestrator schedules the transformation layer, a BI tool sits a few hops downstream, and something legacy that nobody wants to touch still feeds a report. Each of those systems changes on its own, and the person changing one rarely sees what it affects three systems away.

Data lineage is the record that closes that visibility gap. At the table level, it shows which upstream tables feed a given table. At the column level, it shows which source column populated which target column, through every transformation step in between. With a complete record, someone can start at a dashboard number or a churn score and trace it back to its raw source, or start at a source table and see every consumer that would break if it changed.

The common way teams build that record is a crawl. A tool scans query history, catalog metadata, or transformation code on a schedule, usually nightly, and rebuilds the graph from what it finds. That answers “what did this look like as of yesterday” well. It also means the graph always describes a pipeline that has already changed. A column renamed at 9 a.m. stays invisible until the next crawl, so if a breaking change merges at 10 a.m. and a downstream job fails at noon, the team investigates with a lineage view of the old pipeline. A crawl is only one of several ways to capture lineage, so it helps to see all of them before judging any one.

Four Common Ways Teams Capture Lineage Today

Most approaches fall into one of four categories, and each carries a different trade-off between coverage and staleness.

• Manual documentation: Engineers maintain a wiki page or diagram of how pipelines connect. It goes stale within weeks and depends on someone remembering to update it.
• Warehouse-native views: The platform logs query activity and object dependencies, as Snowflake does with its ACCESS_HISTORY view, covered in the next section. Coverage can be limited to higher editions, and the record can lag live activity by hours.
• Event-based capture: Orchestrators and transformation tools emit structured events as jobs run, following a shared format such as OpenLineage, an open standard for describing those events. It works well for tools that emit events and is blind to anything that does not.
• SQL parsing: A tool statically analyzes each job’s transformation SQL to derive column-level lineage. Results depend on parsing quality, and edges inferred by name-matching should be flagged as inferred, not certain.

None of these is wrong on its own. The trouble starts when a team treats whichever one it has as complete. Each method sees a different slice of the estate, and none of them, alone, says what a change costs to run. Snowflake teams already have the warehouse-native option, so that is the one to look at first.

How Snowflake Native Lineage Compares With Continuous Tracking

Snowflake’s built-in lineage is the warehouse-native approach from the list above. It relies on two views inside ACCOUNT_USAGE, Snowflake’s schema of account-level metadata. ACCESS_HISTORY records which queries read or wrote which objects, and OBJECT_DEPENDENCIES records how objects such as views depend on one another. Neither is instant: an overview of Snowflake lineage on Medium notes both can trail actual query activity by up to three hours. That is a fair delay for a governance audit trail and an awkward one during a live incident.

Access is uneven too. OBJECT_DEPENDENCIES is available on every Snowflake edition and needs only the OBJECT_VIEWER role. ACCESS_HISTORY, the view that shows which queries touched which objects, sits behind Enterprise Edition and the GOVERNANCE_VIEWER role, as Atlan’s Snowflake lineage setup guide lays out. A team on Standard gets the dependency graph without the query-level trail behind it.

Real-time, in this context, does not mean instantaneous. It means the record updates as pipelines execute instead of being rebuilt from a periodic scan. When a developer opens a pull request, the step where teammates review a change before it merges, that change should appear in the lineage graph as part of that same workflow, not hours later when a crawl happens to run. The difference is largest in the window between a change in shipping and someone learning what it broke, which is the window an incident lives in.

Why Regulation in 2026 Pushed Lineage From Optional to Expected

Two regulatory frameworks have moved lineage from a nice-to-have to something auditors ask to see on demand. The EU AI Act’s top penalty tier reaches €35 million or 7% of global annual turnover for prohibited AI practices, with lower tiers for high-risk system failures and for giving regulators incorrect information. Showing where a model’s training or output data came from is a lineage question before it is anything else.

DORA, the EU’s Digital Operational Resilience Act, has applied since January 2025 to roughly 22,000 financial entities across the EU. It requires firms to manage information and communication technology (ICT) risk and to report incidents on a defined timeline. When a report has to name exactly which downstream systems were hit by a data issue, a team working from an hours-old graph rebuilds that picture by hand under a deadline.

Neither law was written with lineage as its subject. Both require it as a byproduct, because you cannot show where a number came from, or what an incident touched, without a record that stays current with what the pipeline did.

What Runtime Behavior Shows That Structural Lineage Misses

Two terms need pinning down first. Structural lineage records which tables and columns connect. Runtime behavior covers how a job executes: its duration, the rows it returns, and the bytes it scans, meaning the volume of data a query reads from storage, a main driver of how long it runs and how much compute it uses. Impact analysis is the check a team runs before shipping a change, asking what the change will touch downstream. Structural impact analysis answers from the graph alone. Runtime impact analysis adds what the change costs to run.

Consider a data team at a mid-size SaaS company. A nightly job rolls subscription events into a monthly recurring revenue table, which feeds an executive dashboard and a churn model. An engineer adds a join to bring in a new discount field. The SQL is valid, the column resolves, and every lineage tool in the stack shows the pipeline as healthy, because the shape of the graph did not change.

What structural lineage cannot show is that the new join scans a much larger table. The job that ran in six minutes now takes twenty-five and scans several times the data. Nobody notices until the warehouse bill jumps or the dashboard starts refreshing late, and by then the cause is buried in a change that looked fine by every structural measure.

This is the part of pipeline reliability that costs the most and is caught the least. Fivetran’s 2026 Enterprise Data Infrastructure Benchmark, a survey of 500 senior data and technology leaders at organizations with more than 5,000 employees, estimates average monthly business exposure from pipeline failures at $3 million. Large enterprises in the study averaged 4.7 failures a month, with incidents taking nearly 13 hours to resolve. Much of that time goes to working out what changed, not to fixing it once the cause is known.

A second blind spot appears as more people touch the same pipelines. Most impact analysis compares one proposed change against what is currently shipped. That answers whether a change is safe against today’s state, but not whether another team has an unmerged change on the same table. Two changes can each look safe in isolation and still collide. The gap widens as AI coding tools write more pipeline code: an agent can produce a locally correct change with no way to know if another branch touches the same upstream table. Most lineage tooling is not built to catch this yet, so it is worth asking a vendor about directly.

How Datameer Approaches Operational Lineage on Snowflake Pipelines

Datameer’s approach targets the gap described in the last section: the distance between a change that looks structurally fine and a change that is fine to ship. Column-level lineage is derived by parsing each job’s transformation SQL, instead of relying on the column-level metadata other tools are meant to attach to their lineage events, which OpenLineage calls a facet and many tools do not consistently provide. That addresses the coverage problem with event-based capture, where a tool that emits nothing leaves a blind spot.

Parsing brings its own risk, which is why edges inferred by name-matching are surfaced as inferred and not shown with the same confidence as a directly traced dependency. A team can then tell what the system knows from what it is guessing, which is most useful when someone is tracing a failure under pressure.

The piece that maps onto the slower-join scenario is impact analysis on the pull request itself. When a change is proposed, the workflow compares job duration, result rows, result bytes, and bytes scanned between the current version of a job and the proposed one, and shows that comparison in the review before the change merges. That is a different check from confirming the SQL parses or the column exists. It separates “this change is valid” from “this change will scan four times the data the old version did,” the detail that stayed hidden in the MRR example until the warehouse bill exposed it.

The same record also flags systems it is not yet mapping, instead of treating unmapped territory as though it does not exist. For a team migrating off legacy tooling or consolidating platforms, knowing what is not covered yet is nearly as useful as knowing what is.

Two Datameer product areas connect to this. Job Management runs impact analysis on scheduled jobs to identify downstream dependencies and historical usage patterns. Data Transformation is where pipelines are authored, debugged, and deployed, running on the cloud data warehouse’s native storage and compute.

Five Checks to Run on Any Real-Time Lineage Approach

These questions are worth putting to any lineage tool, whatever the vendor, before treating it as a source of truth.

• How stale can the record get, and when? Ask for a number. “Near real-time” can mean seconds or several hours depending on the capture method.
• Does it separate confirmed lineage from inferred lineage? A name-matched guess drawn with the same confidence as a traced dependency will eventually send someone down the wrong path during an incident.
• Does it show runtime impact, not just structural validity? A change that parses and a change that is safe in production are different claims, and a tool that only checks the first will miss the failures that cost money.
• What happens to a system it does not cover? A record that quietly stops at the edge of its coverage is riskier than one that flags the gap.
• Does it fit the review workflow your team already uses? A lineage check in a separate dashboard nobody opens gets ignored. One inside the pull request, where the change is already being reviewed, gets read.

Where Should You Start With Your Own Snowflake Pipelines

Lineage used to be a map of how data moves. It now also has to record what each change costs to run. A structurally correct change can still blow a runtime budget, and a tool that tracks only the shape of the pipeline will show that change as healthy until the bill or the dashboard says otherwise. Regulatory pressure in 2026 has made the cost of lacking that record concrete, and the pipelines running through Snowflake are where much of the exposure sits for teams already native to the platform.

Start by pulling up your team’s current lineage source and checking how stale it gets during a busy week. Then compare that against how Datameer Job Management runs impact analysis on scheduled jobs, and look at how Data Transformation handles authoring and running those pipelines.

FAQs

Is real-time data lineage the same as data observability?

No. Lineage shows how data moved and what depends on what. Observability monitors whether data is healthy right now by checking freshness, schema drift, and anomalies. They answer different questions and work best together during an incident.

Do we need real-time lineage if we are not in a regulated industry?

Yes, if more than one team or system depends on the same tables, which covers most teams past a handful of pipelines. Faster root cause analysis and safer change review apply regardless of regulation, and a stale record costs investigation time either way.

How is real-time lineage different from OpenLineage?

OpenLineage is an open standard: an event format that orchestrators and transformation tools emit as jobs run, plus a reference backend that collects those events. Real-time lineage is the broader goal of a record that stays current with execution. OpenLineage is one route to it for tools that emit events, and SQL parsing is another.

Why can a lineage graph look healthy when a query got slower?

Structural lineage records which tables and columns connect, and a new join leaves those connections intact. Runtime and bytes scanned are not part of the graph, so a query that takes four times as long can pass every structural check. Catching it requires comparing runtime metrics between job versions.

How stale is Snowflake’s native lineage?

The ACCESS_HISTORY and OBJECT_DEPENDENCIES views can trail query activity by up to three hours, and ACCESS_HISTORY requires Enterprise Edition. That suits audit reporting better than live incident response.

What does Datameer compare on a pull request before a change merges?

It compares job duration, result rows, result bytes, and bytes scanned between the current version of a job and the proposed one, and shows the result in the review. Column-level lineage comes from parsing each job’s transformation SQL, with name-matched edges labeled as inferred.

Snowflake Pipelines and Real-Time Data Lineage: Five Checks Before You Trust Your Lineage Record was originally published in The Ai Studio on Medium, where people are continuing the conversation by highlighting and responding to this story.

Here’s something I’ve noticed about working with AI coding agents: getting them to perform a task once is relatively easy. Getting them to perform it correctly, consistently, and without constant supervision is much harder.

You can ask an agent to review a pull request, generate a monthly report, migrate a database, or investigate a production issue. It may produce an impressive result.

Then you run it again.

The structure changes. It misses an important step. It makes an assumption you explicitly corrected last time. Or it produces something that looks correct until you check the details.

This is where agent skills become useful.

Instead of explaining your workflow in every conversation, you can package the instructions, examples, supporting files, and scripts that help an AI agent perform a particular job.

But there’s a catch.

A poorly designed skill can be just another long prompt that the agent occasionally ignores. A badly written description can prevent the skill from being selected in the first place. And a skill downloaded from an unknown source can introduce security risks into your development environment.

So what separates a useful agent skill from a folder of instructions that nobody trusts?

After examining the Agent Skills open standard and Anthropic’s official skill-authoring guidance, I think five principles matter most.

First, what exactly is an AI agent skill?

An agent skill is a reusable package of instructions and supporting resources that teaches an AI agent how to perform a particular workflow.

The distinction between knowledge and procedure is important.

A model might already know how to write SQL, generate a PDF, or analyze a spreadsheet. What it may not know is how your team performs a database migration, which calculations your finance department requires, or what your company expects in a pull request.

A skill supplies that missing, task-specific knowledge.

The Agent Skills specification defines an open format built around a directory containing a SKILL.md file, with optional scripts, references, and assets.

A basic skill looks like this:

database-migration/
├── SKILL.md
├── references/
│   ├── migration-guide.md
│   └── rollback-policy.md
└── scripts/
    ├── validate-schema.py
    └── check-migration.py

Each component has a different purpose.

SKILL.md tells the agent when and how to perform the workflow.

The references/ directory holds detailed documentation that the agent can consult when needed.

The scripts/ directory contains executable code for operations that should follow explicit, repeatable logic.

This structure matters because a skill isn’t just a prompt. It’s a way of packaging a workflow so that an agent can reuse it across tasks.

Now let’s look at how to build one properly.

1. Write a description that makes the skill trigger at the right time

Imagine you have created 30 skills for your development workflow.

One reviews pull requests. Another generates release notes. A third validates database migrations. A fourth checks API compatibility.

Now you ask your agent:

Review this pull request for breaking API changes.

The agent has a skill that does exactly that — but it never uses it.

Why?

Because the skill’s description says:

Helps with code reviews.

That description doesn’t explain what the skill checks, which tasks should activate it, or how it differs from the other skills.

This is a discovery problem.

In systems such as Claude’s implementation of Agent Skills, the agent initially receives the skill’s name and description. It loads the full instructions when it decides that a skill is relevant. The official documentation explains this progressive-disclosure model.

In other words, the agent needs to recognize a skill before it can benefit from the instructions inside it.

A better description

Here’s an example of a more useful skill definition.

---
name: api-compatibility-review
description: Reviews API changes for breaking compatibility,
  including changed request fields, response schemas,
  status codes, and authentication behavior. Use when
  reviewing pull requests, modifying API contracts,
  changing endpoints, or checking backward compatibility.
---

This description answers two questions:

What does the skill do? It checks API compatibility.

When should the agent use it? When reviewing API changes, endpoint modifications, or potentially breaking pull requests.

That’s substantially more useful than saying the skill “helps with development.”

The open standard specifies a maximum of 64 characters for the skill name and 1,024 characters for its description. The name must also follow the required lowercase naming format. See the Agent Skills specification.

Should you make descriptions more aggressive?

There is a reasonable argument for making important triggers explicit. If your description is too vague, the agent may fail to recognize a relevant task.

But making a description so broad that it triggers on unrelated work introduces another problem.

Suppose your API compatibility skill activates whenever someone mentions an API, even if they’re just asking what REST means. You’ve now added an unnecessary workflow to a task that doesn’t need it.

The goal isn’t to make a skill trigger as often as possible.

The goal is to make it trigger when it adds value — and stay out of the way when it doesn’t.

Test this explicitly. Give the agent examples that should activate the skill, examples that should not, and ambiguous cases where the distinction is less obvious.

A skill’s description is part of its interface. Treat it with the same care you would give a public function’s name and parameters.

2. Build skills from real expertise, not generic AI-generated instructions

This is where I think many skills lose their value.

You ask an AI agent:

Create a skill for reviewing pull requests.

It generates a perfectly reasonable set of instructions:

• Check code quality.
• Look for bugs.
• Validate inputs.
• Handle errors.
• Follow best practices.
• Write tests.

Nothing here is necessarily wrong.

But most capable coding models already know these general principles. You haven’t given the agent much information it didn’t have before.

The real opportunity is to encode what your team has learned through experience.

Imagine your team has discovered that database migrations occasionally fail because older installations contain null values that new code assumes cannot exist.

That is useful information.

Or perhaps your project uses a particular authentication middleware, and adding a second authentication check to route handlers causes inconsistent behavior.

That is useful too.

These details aren’t generic programming advice. They are specific to your environment.

Where should that knowledge come from?

You don’t need to invent a workflow from scratch.

Look at the material your team already produces:

• Pull-request review comments.
• Production incident reports.
• Runbooks and internal documentation.
• Bug fixes that required several attempts.
• Past reports and their corrections.
• Tests that capture edge cases.
• Repeated instructions that developers give to AI agents.

These artifacts reveal the difference between what an agent already knows and what it needs to know to work effectively in your environment.

For example, a report-generation skill might contain this instruction:

Before finalizing the report, compare the subtotal of all included rows with the sum of the category totals. Exclude cancelled entries, but retain refunded transactions in the audit appendix.

That instruction is much more valuable than telling the model to “ensure the report is accurate.”

It defines a real business rule.

Capture the corrections you keep repeating

One practical technique is to maintain a list of recurring mistakes.

Whenever an agent makes a mistake that reveals a non-obvious project constraint, ask whether the lesson should become part of the skill.

For example:

## Project-specific gotchas

- Do not add database retries around non-idempotent
  operations without checking duplication behavior.

- Keep API error responses compatible with the
  existing response schema.

- Run integration tests before modifying transaction
  handling.

- Do not assume production configuration matches
  development defaults.

These examples are illustrative; your actual rules should reflect your system.

The idea is to turn repeated corrections into reusable knowledge.

However, don’t turn every mistake into a permanent instruction. Confirm the underlying cause first. Otherwise, you risk preserving an incorrect workaround just as easily as a useful lesson.

A strong skill captures knowledge that would otherwise have to be rediscovered.

3. Keep the skill focused and manage context carefully

At first glance, this advice might appear to contradict the previous point.

I just argued that skills need real expertise and enough detail to be useful. Now I’m saying they should be concise.

Both are true.

A skill should contain the information necessary to perform its workflow correctly, not every fact that could possibly relate to the subject.

Consider a skill that helps your agent generate a monthly sales report.

It needs the calculations, required data sources, formatting rules, and validation steps. It probably doesn’t need a complete explanation of how CSV files work or an entire reference manual for the database.

The model already has general knowledge. Your skill should concentrate on the rules and evidence that are specific to the task.

Understand how skill loading works

Agent Skills uses progressive disclosure.

In Claude’s implementation, the name and description are available at startup. The full SKILL.md instructions are loaded when the skill is selected. Additional reference files are read when needed, while scripts can execute without loading their entire source code into the model's context. The precise behavior can vary across agent implementations. See Anthropic's skill overview.

This gives you three useful layers:

Layer 1: Metadata

Tell the agent what the skill does and when it should be used.

Layer 2: Core instructions

Describe the workflow, constraints, expected outputs, and validation requirements.

Layer 3: Supporting resources

Keep detailed documentation, examples, templates, and scripts in separate files.

The advantage is that you don’t need to load every detail for every task.

A practical directory structure

For example, a PDF-processing skill might use:

pdf-processing/
├── SKILL.md
├── references/
│   ├── form-filling.md
│   └── table-extraction.md
├── assets/
│   └── report-template.docx
└── scripts/
    └── validate-output.py

The main instructions can explain when to use each resource.

If the task involves extracting tables, the agent can consult table-extraction.md. If it involves filling a form, it can read the relevant guide instead.

Anthropic recommends keeping the main skill body under approximately 500 lines and moving detailed material into separate files when necessary. That’s a guideline for managing the skill, not a universal performance threshold. See Skill authoring best practices.

Avoid overengineering your first skill

You don’t need a complicated directory with a dozen references and scripts for a simple workflow.

Start with a focused SKILL.md. Add references only when the instructions become difficult to navigate or when detailed information is needed only for certain tasks.

The best structure is the simplest one that supports the workflow reliably.

4. Use deterministic scripts when guessing is unacceptable

This may be the most important engineering principle in the entire article.

AI agents are useful because they can interpret instructions, handle ambiguity, and adapt to unfamiliar situations.

But not every operation should be left to interpretation.

Imagine an agent generating a monthly financial report.

It extracts the rows, identifies categories, calculates subtotals, and produces a polished document.

The report looks convincing.

Then someone checks the totals and finds a discrepancy.

Why did this happen?

Possibly the model misread a row, omitted a record, or applied an incorrect assumption while doing the arithmetic.

You could respond by adding more instructions:

Be extremely careful with the calculations. Double-check every number. Never make mistakes.

But stronger wording is not the same as a reliable calculation system.

If the task requires exact arithmetic, write code that performs the arithmetic.

Let the model interpret; let code calculate

A useful division of responsibility looks like this:

TaskPreferred approachIdentify the relevant report sectionsModelInterpret ambiguous descriptionsModelApply a fixed business formulaDeterministic codeSum thousands of numeric rowsDeterministic codeCheck whether the totals reconcileDeterministic validationExplain the result in plain EnglishModel

This isn’t a claim that models can never calculate correctly. It’s a way of assigning work according to the reliability requirements.

The model can decide which categories a report needs. A tested script can calculate the exact totals. The model can then explain the results without inventing the arithmetic.

A simple example

Suppose you want to calculate invoice totals.

Instead of letting the agent repeatedly perform the arithmetic inside its reasoning, give it a script:

from decimal import Decimal

def invoice_total(
    unit_price: Decimal,
    quantity: int,
) -> Decimal:
    if quantity < 0:
        raise ValueError("Quantity cannot be negative")

    if unit_price < 0:
        raise ValueError("Unit price cannot be negative")

    return unit_price * quantity

This is only a simplified example; a real invoicing system also needs explicit rules for taxes, currency precision, rounding, discounts, and refunds.

The point is that once the rules are defined in code, the calculation no longer depends on the model reconstructing the arithmetic every time.

The skill can tell the agent when to execute the script, what inputs to provide, how to interpret the output, and which validation checks must pass.

When should you use a script?

Use a deterministic implementation when:

• The result must follow an exact formula.
• The operation changes important data.
• The same transformation should produce the same output.
• A failure would be costly or difficult to reverse.
• The logic can be expressed and tested precisely.

Keep flexible reasoning for tasks that genuinely require interpretation.

One caution: deterministic code can still contain bugs. The script itself needs tests, explicit error handling, documented dependencies, and appropriate permissions.

The advantage is not that code is automatically correct. It is that exact rules can be implemented and verified independently rather than regenerated probabilistically on every run.

Anthropic’s official skill-authoring guide recommends using scripts to solve problems directly rather than merely delegating the same reasoning back to the model.

When a step must be exact, don’t rely on the model to improvise it. Give it a tested operation to call.

5. Treat third-party skills like software dependencies

Agent skills are often shared as small folders containing Markdown instructions and optional scripts.

That simplicity makes them easy to distribute — and easy to underestimate.

A SKILL.md file might look harmless. But its instructions can influence the agent's behavior, and its scripts may run with access to your filesystem, environment variables, network, or tools, depending on the host configuration.

A malicious skill could try to read credentials, send private files to an external endpoint, or persuade the agent to perform actions unrelated to the advertised task.

This isn’t merely theoretical.

In February 2026, Snyk published its ToxicSkills security research. Its analysis of 3,984 skills from the sampled agent-skills ecosystem reported that 1,467 skills (36.82%) had at least one security issue and 534 (13.4%) had at least one critical-level issue. The researchers also confirmed 76 malicious payloads through human review.

These numbers come from a particular dataset and detection methodology. They should not be interpreted as the probability that any specific skill you download is malicious, nor as a finding about every skill marketplace. But they make a broader point: skills need a supply-chain security review.

Anthropic’s own security guidance for Agent Skills recommends using trusted sources and thoroughly auditing unknown skills before use.

What should you inspect?

Before installing a third-party skill, examine more than its main Markdown file.

Read the instructions. Look for commands that tell the agent to ignore safety rules, conceal actions, or access files unrelated to the skill’s purpose.

Review the scripts. Check shell commands and code for unexpected filesystem access, destructive operations, credential collection, or external network requests.

Inspect dependencies. Determine which packages are installed, where they come from, and whether the skill fetches remote content at runtime.

Check network behavior. A skill that unexpectedly transmits local files or environment information deserves immediate scrutiny.

Look for secrets. API keys, passwords, and access tokens should not be embedded in a skill.

Run in isolation where possible. A sandbox or restricted environment can limit the impact if the skill behaves unexpectedly.

Use least privilege

A report-generation skill shouldn’t need unrestricted deployment access.

A documentation skill shouldn’t automatically need access to production credentials.

A database-inspection skill shouldn’t need permission to delete tables.

The capabilities granted to a skill should match its actual purpose.

Also remember that a clean security review doesn’t establish that a skill’s output is correct. Security and functionality are separate questions, and both matter before deploying a skill into a production workflow.

Treat a skill like a third-party software dependency: inspect it, understand its permissions, test it, and keep track of what you install.

6. Don’t stop at writing the skill. Test whether it works.

A skill can follow every formatting rule and still fail at its job.

It might have a perfect name, an accurate description, concise instructions, and a carefully written script. But does the agent actually select it when needed? Does it produce the right output? Does it interfere with other skills?

These are separate questions.

Anthropic’s skill-authoring guidance recommends testing skills with real scenarios and across the models you intend to support.

Here’s a practical evaluation plan.

Test 1: A task that should trigger the skill

Ask for the exact workflow the skill was designed to perform.

For a database-migration skill:

Migrate the customer repository to the new database driver and preserve the existing API behavior.

Check whether the correct skill activates and the workflow is followed.

Test 2: A task that should not trigger it

Ask an unrelated question:

Explain the difference between a database index and a primary key.

If the migration skill activates unnecessarily, its description may be too broad.

Test 3: An ambiguous task

Ask:

Can you review these changes before I merge?

The request might warrant a general code review, an API compatibility check, or a security review. Observe which skill the agent selects and whether it asks for clarification when appropriate.

Test 4: A known edge case

Give the skill an input that historically caused mistakes.

For a financial report, this might be a cancelled transaction or a refunded invoice. For a code-review skill, it might be a backward-incompatible API change hidden among otherwise harmless edits.

The purpose is to check whether your specific rules actually prevent the problem.

Test 5: Measure the output

Write down what a successful result looks like.

For instance:

• Every required section is present.
• Calculations reconcile.
• Required tests run successfully.
• Output files follow the expected format.
• No unauthorized operation occurs.
• The skill doesn’t activate for unrelated requests.

If the skill is intended to work with several models, test it with those models too. Instructions that provide enough guidance for one model may be unnecessarily verbose — or insufficiently explicit — for another.

For team or production use, save a small set of representative prompts and expected results. Run them again when the skill changes.

That way, modifying the skill becomes an engineering process rather than a matter of intuition.

7. A complete example: building a better code-review skill

Let’s bring these principles together.

Suppose your team repeatedly asks an AI agent to review pull requests for API compatibility.

You want the skill to identify breaking changes, respect your existing conventions, and avoid producing generic comments on every line.

A simple directory might look like this:

api-compatibility-review/
├── SKILL.md
├── references/
│   └── api-contracts.md
└── scripts/
    └── validate-openapi.py

The SKILL.md file could begin like this:

---
name: api-compatibility-review
description: Reviews API changes for breaking compatibility,
  including request fields, response schemas, status codes,
  and authentication behavior. Use when reviewing API pull
  requests or modifying endpoint contracts.
---

# API Compatibility Review

## Objective

Identify changes that could break existing API consumers.

## Workflow

1. Inspect the pull request and identify affected endpoints.
2. Compare the changed contract with the current version.
3. Read references/api-contracts.md for project-specific rules.
4. Check for removed fields, changed types, incompatible
   status codes, and authentication changes.
5. Run scripts/validate-openapi.py when the contract format
   and dependencies support it.
6. Report findings with file references and evidence.

## Review rules

- Do not label a change breaking without explaining its impact.
- Separate confirmed issues from potential risks.
- Do not modify files during the review.
- Do not claim tests passed unless they were actually run.

## Output

For each finding, include:
- Severity
- Affected endpoint or file
- Description of the incompatibility
- Evidence
- Recommended fix

Finish with a concise summary of the review.

This is a starting point, not a production-ready skill for every API.

The script, its dependencies, the API contract, and the team’s compatibility rules still need to be implemented and tested.

But notice what the skill does well.

Its description tells the agent when to use it.

Its instructions describe a specific workflow rather than offering generic coding advice.

Project-specific rules live in a reference file.

A deterministic script handles a validation step where code is appropriate.

The expected output is explicit, making the result easier to evaluate.

And the instruction not to claim that tests passed without running them makes an important boundary clear.

Most importantly, the skill is narrow enough that you can test whether it works.

You don’t need a hundred rules on the first attempt. You need a small, useful workflow that solves a real problem — and evidence that it does so consistently.

The five principles to remember

After putting these ideas together, I would summarize good skill design in five rules.

1. Make the skill discoverable. Its name and description should clearly communicate what it does and when to use it.

2. Encode knowledge the model doesn’t already have. Use real procedures, project conventions, edge cases, and lessons from previous mistakes.

3. Keep the active instructions focused. Use references and supporting files to provide additional detail when necessary, rather than loading everything at once.

4. Replace risky guessing with deterministic code. When exact calculations, validations, or transformations matter, use tested scripts with explicit inputs and outputs.

5. Review and test before trusting. Evaluate the skill’s behavior, inspect its code and permissions, and repeat your tests when it changes.

The same principles are useful whether you’re building skills for Claude, Codex, or another agent that supports the open Agent Skills format. Exact behavior and supported fields can vary by platform, so always verify the implementation’s documentation.

Final thoughts

I think the most useful way to think about an agent skill is as a small piece of engineering infrastructure.

It’s not just a prompt you save because it worked once. It’s a documented workflow that should be discoverable, maintainable, testable, and safe to run.

A good skill captures the decisions that would otherwise have to be repeated. It gives the agent the right information without filling its context with unnecessary detail. It uses code where correctness must be predictable. And it can be evaluated rather than judged solely by whether one example looks impressive.

None of this removes the uncertainty inherent in AI systems.

But it does give developers more control over how agents perform real work.

The goal isn’t to write longer instructions for a smarter model. It’s to design a workflow in which the model has fewer opportunities to make avoidable mistakes.

That’s what makes an agent skill worth maintaining.

How to Build Reliable AI Agent Skills: 5 Best Practices was originally published in The Ai Studio on Medium, where people are continuing the conversation by highlighting and responding to this story.

Many people know me from brand marketing, advertising, and the record business. What they don’t know is that when I was eighteen, I was building Novus Online Services and ChatLink: an online service platform and a real-time chat system, years before anyone used the words “social network.”

It was February 1986. The digital world was a frontier of text-based commands and acoustic couplers. There was no “web” as we know it today.

Fast forward forty years. We are in the midst of the most significant technological shift since the dawn of the internet: the transition from “tools” to “agents.” But as I look at the current AI landscape, I see a familiar error. We are so focused on the artificial that we have forgotten the intelligence.

The 2016 Experiment

In November 2016, I launched what was then a business experiment: The Wagner Agency. After decades working at various advertising and marketing agencies, I witnessed a disconnect. Agencies were becoming rigid, slow-moving entities that dictated to the market rather than listening to it.

I founded the agency on a few core beliefs: that trust is more valuable than proximity, that nomadic work is the future of creativity, and that an agency should be a “proof of concept” for the very advice it gives its clients. We didn’t just sell strategy; we lived it.

From Strategy to Systems

By 2022, the experiment had succeeded. We had serviced global brands and won awards. But the market was shifting again. The “Subscription Economy” was no longer a trend; it was the baseline expectation. I wound down the original entity to introduce a new concept: WGNR, a subscription-based advertising and marketing agency, a model designed to match the speed and accessibility modern businesses demanded.

But as a tech pioneer, I knew that subscription-based human labor was only half the answer. The real bottleneck was the “shallow work” that drained human creative potential.

The Rise of the Agentic Era

For the last three years, I have been back in the architecture, building what WGNR became: wgnr.ai. This is not another layer of “chatbots” or AI-generated copy. It is a proprietary agentic framework designed to handle the operational execution that typically slows a brand to a crawl. I wrote recently about why the interface, not the model, is the real bottleneck in this era (https://wagnerspeaks.com/the-language-tax-why-the-interface-not-the-model-is-holding-ai-back-babfffe9e503), and that argument runs underneath everything we build here.

We’ve now reached the production phase of kelle.ai, built on this framework: a suite of AI agents grouped into subject-focused squads and orchestrated by an AI agent squad leader. What makes this different from the thousands of AI tools flooding the market? It is Agency-Powered, and it is built by people who have spent thirty years in the trenches of brand psychology and forty years at the leading edge of digital communication.

We aren’t tech tourists; we are architects who understand that an agent is only as good as the anthropological strategy behind it.

The 10-Year Milestone

As wgnr.ai marks its 10th anniversary on November 1st, the mission remains the same as it was in 2016: to listen to the market. Today, the market is asking for speed without the loss of soul. It is asking for automation that understands nuance.

We are entering an era where the most successful brands will be those that use AI to become more human, not less. At 57, I find myself exactly where I was at 18, standing on the edge of a new frontier, building the systems that will define how we connect for the next forty years.

The future isn’t just about what AI can do. It’s about what we can finally do, now that we have the agents to handle the rest.

The 40-Year Horizon: Why the Future of AI is Rooted in the Past was originally published in The Ai Studio on Medium, where people are continuing the conversation by highlighting and responding to this story.

Something uncomfortable about my industry: we spend most of our engineering effort teaching machines to write, and almost none of it asking whether writing is the right way to hand a machine a task at all.

Every AI product today runs through the same pipe. You describe what you want in prose. The model parses your prose, thinks, and answers in more prose. If you’re using an agent, that prose gets wrapped and re-wrapped again on every hop between you, the model, and every tool in the chain. That pipe is the interface. And I’m going to argue, as an opinion piece and not a fact, that the interface is now the bottleneck. Not compute. Not model capability. The pipe itself.

Call it the language tax. It’s real, it’s measurable, and it explains a lot about why AI feels simultaneously miraculous and exhausting.

The tax is visible in the engineering data

Start with the cost. Anthropic’s own engineering writeup on its multi-agent research system, 2025, puts a number on it: agents typically use about 4x more tokens than chat interactions, and multi-agent systems use about 15x more tokens than chats. A frontier lab admitting this about its own architecture is worth pausing on. The language-heavy version of a task costs an order of magnitude more than the conversational version, and the model isn’t even the thing you’re mostly paying for. You’re paying for the scaffolding of words wrapped around the task.

Is that cost buying anything? A peer-reviewed answer arrived in 2026. In a Frontiers in Robotics and AI study of single-agent versus multi-agent orchestration on a simulated decision-support benchmark, Sanabria (2026) measured mean token usage of 458 tokens for the single-agent run against 2,273 for the multi-agent version, roughly five times the cost and latency, with no significant gain in decision quality. Statistically controlled, five times the tokens, same decisions. The language tax doesn’t get cleaner than this: you’re not paying for better answers, you’re paying for more prose in the pipe.

Then there’s the failure mode, which is worse than the cost. The more conversational hops between an intent and an outcome, the more chances for the intent to get garbled. The MAST taxonomy (Cemri et al., arXiv 2025), the leading academic effort cataloguing why multi-agent LLM systems fail, analyzed over 200 traces and found 14 failure modes across three categories, with specification and coordination issues dominating. The paper itself flags the mechanism: LLM-based agents mainly communicate via unstructured text, leading to ambiguities. Its own demonstration case, the ChatDev framework, achieved full correctness on software-development tasks only 33.33% of the time. One in three. The agents weren’t failing because the model couldn’t write code. They were failing because the instructions for that code traveled through natural language and got mangled on the way.

The question I keep coming back to is how much of all this loss is a model problem and how much is an interface problem. My claim is that we’ve been attributing to weak models what is actually a weak pipe.

Why chat became the default anyway

So why did we all build chat interfaces? Because LLMs are trained on text, and text in, text out is the shape of the model. Chat wasn’t chosen as the ideal interface. It was inherited. The model speaks sentences, so the product speaks sentences. Nobody ran the comparison against alternatives because the alternative didn’t exist yet at the time the product decisions were being made. The interface is a deployment artifact, not a design conclusion.

There’s also an institutional logic worth naming. Conversation is the path of least deployment resistance. A chat box is the cheapest product surface to build, the easiest to demo, and the one that requires the least translation between what the model can do and what a product manager can spec. Every company that ships an AI feature ships it as chat first because that’s the shape the model comes in. It reads as polish. A product that talks feels advanced, even when a form would serve the user faster.

Here’s the part that surprises people: preference, not efficiency, is how chat won. Soni et al., 2022, ran a controlled study of 206 participants collecting the same health data through a chatbot and a structured online form. The chatbot took longer to complete, and 69.9% of participants preferred it anyway, describing it as conversational, interactive, and intuitive. People rated the form as faster and still picked the chatbot. That’s the whole story of chat adoption in one study: users like it, so it ships, even though it’s measurably slower at the task. Nobody chose chat because it was optimal. People chose chat because it felt good, and the industry followed the feeling.

There is a demo effect layered on top of all this. Chat is great for showing off a model. Type a question, get a paragraph, everyone’s impressed. It’s a worse interface for actually working, because it makes you a typist. You translate your intent into words, the machine translates your words back into an interpretation, and if any step of that translation goes sideways, you re-explain.

Now the caveat on the evidence, because it matters. That Soni study predates LLMs entirely. Four years old, earlier generation of conversational systems. I’m not citing it as proof about GPT-era interfaces. I’m citing it as the baseline a rigorous LLM-era comparison hasn’t yet, to my knowledge, filled in. That’s a research gap the industry should close, and I suspect the results would be uncomfortable reading for anyone whose entire product is a text box.

A worked example: the same task, two interfaces

Let me make this concrete with the kind of judgment call most AI products are asked to make. Say you need a reliable yes-or-no answer with a confidence level: is this customer message a billing complaint?

The chat version of this task is a conversation. You write a prompt describing what a billing complaint is. The model replies in prose, verdict buried in the middle. If you want a consistent format, you ask for one, and it half-follows. If the reply hedges, you tighten the prompt and go again. Each round trip is more tokens, another parsing job on your side, another chance for the answer to drift from the last one.

The typed version of the same task is one request. You define the judgment: a classification of billing or not-billing, a confidence value, done. The model fills the type. That’s it. No paraphrase layer, no second parsing pass, no drift between runs.

The evidence for why the second version wins is already published. OpenAI’s Structured Outputs announcement, 2024, reported that on evaluations of complex JSON schema following, a model with structured outputs scored a perfect 100%, while the prior generation without it scored less than 40%. Read that again: same class of model, same task, and simply constraining generation to a typed schema moves reliability from under 40% to 100%. Free-form text turns out to be the unreliable mode. Structure is the reliability feature.

That’s a vendor claim, so here’s the independent corroboration. JSONSchemaBench (Geng et al., arXiv 2025), an academic benchmark from EPFL and Microsoft researchers covering 10,000 real-world schemas, found that constrained decoding speeds up generation by up to 50% compared to unconstrained decoding, and consistently improves downstream task performance by up to 4%, even on tasks with minimal structure. Structure didn’t cost anything. It won on cost and accuracy at the same time.

Vendor and independent research landing on the same conclusion from different directions is as strong as evidence gets in this field. I won’t pretend to have per-task performance numbers for the chat version versus the typed version of this example; nobody has published a controlled head-to-head, and I’d rather tell you that than invent one. But the verified pieces point the same way: free-form prose fails schema adherence most of the time without help, and constraining generation to a type makes it faster and more accurate at once. One interface negotiates with language on every call. The other states the judgment and gets it back.

The case for chat, stated honestly

Before anyone writes the rebuttal, let me make the strongest version of the other side myself, because it’s real.

Conversation genuinely does things structured interfaces can’t. When you don’t yet know what you want, chat is the discovery tool. Ambiguity is chat’s home turf: a good conversation teases out requirements you couldn’t have specified in advance, which is exactly what a rigid schema can’t do. Conversation builds trust in a way forms never will. And accessibility matters: for many users, many situations, and many languages, typing a question into a box is the interface that works, full stop.

I’m not arguing against any of that. Notice where those strengths live: exploration, discovery, trust, onboarding. All upstream of the work. Then look at where the tax gets paid: execution. Once the task is defined and runs repeatedly at scale, the conversation stops adding value and starts adding cost. Chat wins discovery and loses execution, and execution is where products live or die. The argument isn’t that conversation is bad. It’s that entire industries now run the execution phase through an interface designed for discovery, and the bill shows up as tokens, latency, and failure modes the research keeps cataloguing.

The alternative already exists: language stops carrying the weight

This isn’t hypothetical for me. In my writing on bound versus unbound text, I lay out one principle underneath all of it: narration can never be evidence. When an agent says “I saved the file,” that sentence is not proof anything happened. Only text that exists as a byproduct of action counts: tool output, exit codes, logs, hashes. That single axis explains most of what goes wrong in agent systems. And language isn’t replaced in that picture. It gets re-addressed machine-first, so human-readable prose becomes a delivery layer instead of the load-bearing evidence. The typewriter isn’t going anywhere; it’s being repurposed.

There’s a beat in that essay I find genuinely unsettling. In a long exchange with an AI assistant, its praise escalated with every round while it absorbed the content of my corrections verbatim and then violated them in its own voice. Narration runs upstream of comprehension. That observation is why I don’t ask prose to be honest; I ask artifacts to be.

We build on this direction at wgnr.ai with JEV, a typed-judgment AI: you ask it a classified question, it returns a typed answer with a confidence value, not an essay. The machine reads first. The human reads what matters. The utility arrives directly.

To be clear about the size of this claim: this is a direction, not a finished revolution. Chat is not going away, and some tasks are genuinely conversational. But when the task is “classify this,” “score that,” “decide between these,” prose is overhead, and the overhead compounds. I’ve written before about agent architectures, single versus multi-agent, and the coordination costs between them. This is the layer underneath that problem. Whether you run one agent or ten, they all talk in language, and every hop pays the tax.

The challenge

If you build AI products, try this test. Take your core user action and ask: does the user’s intent need to survive a sentence before it reaches the model? If yes, you’re paying the language tax, and some part of your accuracy problems, latency complaints, and token bills are that tax arriving.

The models will keep getting better. That’s the easy part. The hard part, the part that will actually differentiate the next generation of AI products, is designing interfaces that don’t route human intent through a lossy language middleman on the way to the machine.

Language was how we taught computers to talk to us. The next unlock is interfaces where the machine reads first, and the human reads only what matters.

Transparency note (evidence gaps)

This piece cites only points verified against live primary sources (October 28, 2026):

• Used: Anthropic Engineering multi-agent research system, 2025 (4x chat / 15x multi-agent token figures, quoted from source). Sanabria, Frontiers in Robotics and AI, 2026 (458 vs 2,273 mean tokens, no significant quality gain, dz = -12.7). MAST taxonomy, Cemri et al., arXiv 2025 (14 failure modes, 3 categories, 200+ traces; ChatDev 33.33% correctness). OpenAI Structured Outputs announcement, 2024 (100% vs under 40% schema adherence, vendor eval). JSONSchemaBench, Geng et al., arXiv 2025 (up to 50% faster generation, up to +4% downstream accuracy, independent benchmark; note the speedup is specific to the Guidance engine).
• Flagged: the HCI chat-friction argument rests on a single 2022 pre-LLM study (Soni et al., Frontiers in Digital Health, N=206), cited here with its age and scope stated rather than as proof about current LLM interfaces.
• Not found / not used: the MAST paper’s overall failure-rate range (it appears only in a figure and could not be text-verified, so it is excluded); LLM-era comparative studies of chat versus structured interfaces; verified production statistics on chat-interface task failure rates. No reliable data was found for these, so none is claimed.

The Language Tax: Why the Interface, Not the Model, Is Holding AI Back was originally published in The Ai Studio on Medium, where people are continuing the conversation by highlighting and responding to this story.

If you’ve spent time explaining your writing style, research rules, or preferred output to an AI assistant, switching apps raises a practical question: how much of that work can you take with you?

On October 22, 2026, Anthropic announced it was donating Agent Skills to the Agentic AI Foundation, under the Linux Foundation.

The useful answer is that reusable workflows can be easier to carry between compatible AI tools. The format was already open, though, and this announcement doesn’t make every workflow work everywhere.

Its significance is longer term: a shared format now has a home intended to serve an ecosystem of tools. For creators and solo professionals, that could make carefully written instructions a more durable part of their work.

What is an Agent Skill, in ordinary language?

Think of a skill as a small instruction pack for a recurring job.

At its center is a readable file called SKILL.md. It describes what the skill does, when to use it, and how to do the work. The folder can also contain examples, reference documents, templates, or small programs that help complete the task. That’s the structure described in the Agent Skills overview.

A saved prompt can already be useful. A skill adds a standard way to package the instructions with their supporting material and tell an assistant when they’re relevant.

The assistant can first read a short name and description, then load the detailed guidance when needed. You don’t have to paste every instruction into every conversation.

That still leaves room for mistakes. Having a procedure available doesn’t prove the assistant followed it.

What actually changed this time?

Three dates explain the news:

• October 16, 2025: Anthropic introduced Skills.
• December 18, 2025: It published Agent Skills as an open standard, extending the idea beyond its own products.
• October 22, 2026: Anthropic announced the donation, and the foundation welcomed Agent Skills as a hosted project.

The donation includes the Agent Skills name and logo, its GitHub organization, and the agentskills.io domain. Anthropic also proposed work on versioned releases, a formal proposal process, and security guidance. Those are proposed next steps, not completed features.

Why should an ordinary user care about governance?

Because investing effort in a reusable workflow makes more sense when several toolmakers can help shape the format it uses. A neutral home could give those companies more confidence to keep supporting it. That’s my interpretation of the practical value; the announcement itself can’t guarantee adoption or quality.

Why this matters beyond saving a long prompt

I recently set up reusable article-writing instructions and a featured-image skill for my Medium workflow. That’s why this subject interests me: the work includes decisions about sources, structure, tone, and visuals that I want to keep available.

Consider a hypothetical article-research skill.

It could tell an assistant to check official announcements first, separate confirmed details from speculation, preserve source links, and flag facts it couldn’t verify. Alongside those instructions, it could include an outline template and an example showing how to explain a product limitation.

Now imagine improving that pack after an article needs a correction. You add a rule to distinguish an announcement date from an availability date.

That revision becomes part of the reusable procedure. You can review it, keep a copy, and potentially carry it into another compatible assistant.

The deeper benefit is preserving decisions about how the work should be done. A long prompt can contain those decisions too; the shared packaging makes them easier to organize and reuse with their references.

It also makes the instructions inspectable. You can see the rule you wrote rather than relying on an assistant to remember an earlier conversation correctly.

An open format still needs a capable app

Compatibility has several layers.

First, the app must recognize the format. GitHub’s official documentation confirms support in products including Copilot CLI and agent mode in VS Code, while noting that IDE support depends on version. That’s evidence of implementation beyond Claude, with product-specific conditions.

Second, the skill’s requirements must match the environment. The specification explicitly allows authors to describe requirements such as a particular product, installed software, or internet access. It also warns that support for its experimental tool-permission field can vary.

Return to our hypothetical research skill. Its instructions might arrive intact in another app, but checking live announcements still requires web access. Reading the bundled example requires access to that file. Any step using a connected service needs that service’s integration and appropriate permission.

An instruction to use a tool doesn’t supply the tool.

The standard’s implementation guidance also distinguishes local apps from cloud-hosted assistants, which need different ways to obtain skill files. A folder on your laptop won’t necessarily appear in a web service automatically.

Finally, even with the same instructions and resources, you should check the output. A shared procedure gives you a common starting point; different assistants can still interpret it differently.

And a feature called “Skills” deserves a documentation check before you assume it supports this particular format.

Who should care now?

Pay attention if you repeatedly explain the same process to AI, especially if you already use several tools. Start by keeping one useful workflow and its reference files somewhere you control. If you move it, check whether the destination can access the resources and perform the important steps.

If your AI use is mostly occasional questions, you can wait. This announcement doesn’t create an urgent migration task.

My judgment: the promising part is being able to keep refining a way of working without tying all that effort to one app. How easily complete workflows travel remains something to verify.

Which recurring task would you most want to carry between AI tools?

Read next: Google Is Replacing Gems With Skills. Here’s What Gemini Users Need to Know., for the account-specific side of changing a saved AI setup.

I explain AI launches and product changes for everyday users, creators, and solo professionals. Follow me on Medium or find me on X. If this clarified the news, a clap is appreciated.

Anthropic Donated Agent Skills. Here’s What Could Travel Between AI Tools. was originally published in The Ai Studio on Medium, where people are continuing the conversation by highlighting and responding to this story.