We stopped building agents last month. Everyone started building skill systems.

This is not a minor shift. For three years every agent demo was a one-off workflow hardcoded into prompts, impossible to reuse, debug or improve. That era ended over the last 90 days. Four separate working implementations landed this month, all converging on the same core model: declarative, named, inspectable skills that can be composed, tested, patched and evolved independent of the base LLM.

Nobody is arguing about this any more. The argument now is about how you build them correctly.

We stopped hardcoding workflows

STORM was the peak of the old model. It wrote very good Wikipedia articles by spinning up 8 specialized role agents, passing messages between them, and following a fixed 12 step pipeline. It worked. It also could not be changed. If you wanted to adjust how citations were formatted you had to dig through 7 nested prompts, and any fix would break three other parts of the workflow.

Every production agent built in 2025 had this exact problem. Capabilities were entangled. There was no way to improve one part without retesting everything. There was no versioning. There was no way to take a working component from one agent and drop it into another.

Skills solve this. A skill is a standalone, atomic unit of agent capability. It has a name, a trigger condition, input schema, output schema, validation rules, and a complete audit trail. It does one thing. It can be tested in isolation. It can be replaced. It can be upgraded while the rest of the system runs.

GEIS: The first working improvement loop

GEIS is the first published system that demonstrates this working end to end for a non trivial task.

The paper published last week does exactly what everyone said was impossible: it takes a writing skill, runs it, evaluates the output, generates a patch for the skill, and applies that patch permanently. No human in the loop. Over 20 test runs the system got better every single time on average.

GEIS runs three steps on repeat:

1. Generation: run the current version of the skill against a test topic
2. Evaluation: run an independent pairwise evaluation skill to produce a structured failure report
3. Improvement: map observed failures into permanent edits to the original skill definition

This is not fine tuning. This is not prompt engineering. The system is modifying its own source code. And it works.

On the standard Wikipedia featured article rubric the baseline skill started at 82.9/100. After 20 iteration loops it reached 86.95. 17 out of 20 topics improved. All gains came from content quality, not cosmetic changes.

Crucially: all improvements generalized. Patches applied for one topic improved performance on all others. This was not overfitting.

LASKO: Skill optimization is not vector space

Everyone working on skill improvement hit the same wall last quarter. Edits do not commute.

If you have two changes to make to a skill: fix the output schema, and add a validation rule. Applying them in one order works. Applying them the other order breaks the skill completely.

Brute force testing every possible order of edits is prohibitively expensive. Every test requires a full LLM rollout.

This is the problem LASKO solves. It does not model skills as points in a vector space. It models them as objects on a Lie algebroid. The anchor map describes the visible effect of an edit. The kernel describes the hidden state that does not show up in output. The bracket measures if two edits will commute.

You run the bracket check first. It runs in 12 microseconds. Only if edits pass this check do you run the expensive LLM validation.

The result is 15x speedup on skill optimization. This is not an incremental improvement. This changes what is possible. Before LASKO you could run 10 improvement iterations per day. Now you can run 150.

Cangjie: You do not have to write skills

The most important skill repository on Github right now was not built by Google or OpenAI. It was built by an independent developer in Kunming.

cangjie-skill does one thing: it takes any book, podcast, long video or interview, extracts every reusable methodological principle, and turns them into standalone agent skills.

It does not make summaries. It does not make embeddings. It makes working, testable skills that your agent can call when it encounters a matching situation.

This solves the single biggest unspoken problem with LLMs right now. You can read 100 books. You can watch 1000 hours of lectures. None of that knowledge will ever be reliably available to your agent unless someone turns it into a skill.

cangjie will do this automatically. It runs 7 extraction stages, triple validation, and pressure tests every skill before it is exported. On average 30% of the source material survives this process. The rest is discarded.

Source material	Extracted skills	Survival rate
Poor Charlie's Almanack	12	27%
Buffett Shareholder Letters 1957-2023	20	31%
Mao Selected Works Vol 1-5	25	22%
Influence, Cialdini	12	34%
Sun Tzu Art of War	8	41%

This is not compression. This is filtering. Most of what is written is not reusable. Most of what is taught is not actionable. Cangjie throws all of it away.

Google just standardized the skill interface

Google dropped their public skill repository two days ago. This is not a research project. This is production infrastructure.

Every single Google Cloud product now has an official agent skill. You install them with one command. They follow a common schema. They can be composed. They are versioned.

This is the moment this became standard. Google did not invent skill systems. But they just normalized the interface.

There are no longer 12 incompatible ways to package an agent skill. There is one. Everyone will adopt it. That is how this works.

The three layer skill stack

All four implementations converge on exactly the same architecture. Nobody coordinated this. Everyone arrived at the same design independently.

There are no roles. There are no agents. There are only three things:

1. A stateless router that selects the correct skill for the current context
2. A registry of immutable, versioned, tested skills
3. An independent improvement loop that writes new versions of skills in the background

That is the entire agent architecture for 2026. Everything else is implementation detail.

What does not work

We already know what dead ends to avoid.

Hardcoded multi-agent role play is dead. It will never scale. It will never be maintainable. Anyone still building this is working on last year's problems.

Vector databases alone will never give you usable knowledge. Embeddings tell you what is similar. They do not tell you when to use something, what the boundaries are, or how to apply it correctly. That is what skills are for.

Fine tuning is for behaviour. It is not for capability. You will never fine tune a model to correctly apply the principles from a single book. You will always get better results by writing one good skill.

The next thing that will break

Right now every skill is independent. We do not yet have good models for skill composition failure.

We know that two skills that each work perfectly in isolation will regularly produce garbage when used together. We have no theory for why this happens. We have no good way to test for it.

That is the next problem. That is what all the good groups are working on right now.

Closing observation

Six months ago everyone was arguing about whether agents would ever be useful. Today we have working production systems that improve themselves. Nobody is arguing any more.

This is moving faster than any previous part of LLM development. Most of the code you will use to build agents next year does not exist yet. Most of the papers that will define this field have not been written.

If you are still building prompt chains, stop. This is the new baseline.