Auto extracted Skills from observed work

The AI agent market in 2026 is hot. Every product is launching agents. Microsoft has Copilot agents. Salesforce has Agentforce. Glean has agents. Atlassian has Rovo agents. Coworker.ai sells a library of 98+ pre built agent templates.

Every one of these systems shares the same architectural choice: humans author the agents. A subject matter expert writes a procedure document. The document gets formatted as an agent definition. The agent runs based on the human written specification.

This sounds reasonable in theory. In practice, it fails for three structural reasons.

The agent problem nobody talks about

Humans do not write down what they actually do. When you ask a senior engineer “how do you investigate a database performance issue?”, they give you a sanitized version of their process. They omit the steps they do not realize they are doing. They include best practices they aspire to but rarely follow. They forget the workarounds that have become muscle memory. The documented procedure and the actual procedure diverge from the moment of writing.

Documentation drifts from reality. Even if the original document was perfectly accurate, it becomes stale immediately. Tools change. Conventions evolve. Team members come and go. After six months, the documented procedure no longer matches what the team does. After a year, it is actively misleading.

Authoring is a tax. Every documented procedure costs human time to create. For a team with 100 distinct workflows, this is hundreds of hours of writing time, plus ongoing maintenance time. Most teams do not have this time. So most workflows never get documented, which means most agents never get built.

The result: agent platforms today are powerful for the small handful of workflows where humans have invested in good documentation. They are useless for the much larger universe of work the team does every day that has never been written down.

What auto extracted Skills are

Auto extracted Skills solve this by inverting the model. Instead of asking humans to write procedures and feeding them to agents, the system watches how the team actually works and extracts procedures automatically.

Here is the basic mechanism. As the team uses connected tools (Slack, GitHub, Linear, Notion), every action gets captured in the process graph as structured entities (decisions, commitments, failures, outcomes). When the same pattern of work happens repeatedly (say, the team has handled customer refunds 8 times in similar ways) the system detects this cluster of similar entities and compiles them into a Skill.

The Skill is a procedure: the steps the team takes, the triggers that initiate it, the decision points along the way, the typical outcomes. It is formatted as a SKILL.md file in Anthropic’s Agent Skills standard, which means it can be loaded by Claude Desktop, Cursor, ChatGPT custom GPTs, or any other Skills compatible AI tool.

The new engineer who joins the team three months later does not need to ask a senior person how to handle a customer refund. They open their AI tool, load the team’s customer_refund Skill, and walk through the procedure that emerged from how the team actually handles refunds.

The seven layers of a real Skills compiler

Auto extraction sounds simple. Doing it well is not. The Skills compiler we built has seven layers, each solving a specific problem that emerges when you try to extract real procedures from real team work.

1. Pattern detection. The system scans the process graph for clusters of structurally similar entities. Eight customer refund situations, all sharing the same shape (request, eligibility check, decision, execution, documentation) get clustered. Three incident response sequences with similar trigger patterns and resolution flows get clustered. The clustering is statistical, not exact: similar enough is enough.
2. Compilation. Each cluster is passed to Claude Sonnet with a structured prompt. Sonnet generates a draft Skill from the cluster with steps, triggers, and decision points.
3. Drift detection. The team keeps working after the Skill is generated. Their behavior continues to evolve. The drift detector compares new instances of similar work to the original Skill, scoring divergence. If reality diverges from the Skill beyond a threshold (we use 0.6 cosine distance over a 14 day rolling window), the Skill flips to DRIFTED status and is flagged for review.
4. Confidence calibration. Each Skill invocation has an outcome. Did the procedure work? Was the result what the team expected? Over many invocations, we calibrate per Skill confidence. A Skill that has succeeded in 87 of its last 100 invocations has different calibrated confidence than one that has succeeded in 34 of 100. Calibration is non negotiable: agents that do not know how confident to be cause real damage.
5. Permission aware compilation. Different team members have different access to source systems. The same Skill renders differently for users with different permissions. Steps the user cannot see (because they do not have access to the referenced channel, project, or system) get redacted. This is how the Skill stays useful for someone with limited access without leaking what they should not see.
6. Conflict detection. Sometimes two different Skills describe overlapping work. Two teams might both have compiled procedures for handling escalations, with subtle differences. Conflict detection identifies high cosine similarity Skills (greater than 0.8) and flags them for resolution: keep both as separate Skills, merge them, or archive one.
7. Shadow mode harness. Before a newly compiled Skill is allowed to execute actions on connected tools, it runs in shadow mode. The Skill watches similar work happen and predicts what it would do; the team executes the work as normal; the system compares predictions to outcomes. Once shadow mode validates the Skill, it graduates to ACTIVE status.

This is not a weekend project. The Skills compiler is roughly 5,000 lines of code, took 8 weeks to get right, and continues to evolve. The complexity is the moat.

What this unlocks for teams

Three specific outcomes emerge when Skills are auto extracted rather than human authored.

Coverage scales without authoring tax. A typical software team has 50 to 100 distinct workflows that could become Skills. Human authored systems get 5 to 10 of these documented. Auto extracted systems get most of them, because the cost per Skill is near zero (the team is going to do the work anyway; the system just observes and extracts).

Skills stay current.When the team’s behavior evolves (they switch from DataDog to Grafana, they change their refund policy from 60 days to 90 days), drift detection catches the divergence and prompts an update. The Skill reflects how the team actually works today, not how they worked when someone wrote the document a year ago.

Skills become portable institutional knowledge. Because Skills are SKILL.md files in a standard format, they can be loaded by any compatible AI tool. The team’s institutional knowledge is not locked inside Pulse: it is deployable to whichever AI tool the team uses. When someone uses Claude Desktop for individual work, the team’s Skills are available to Claude. Same for Cursor, ChatGPT, and any other Skills compatible system.

What this means for the AI ecosystem

The Anthropic Agent Skills standard is a significant moment for the AI ecosystem. By creating a portable file format for procedures, Anthropic made it possible for AI tools to share procedural knowledge in a way that was not possible before.

Most products will treat Skills as something humans author. They will provide editors, templates, marketplaces. This is the obvious path.

The non obvious path is making Skills emerge from observed work. The product that gets this right becomes the upstream source of Skills for the entire AI ecosystem. Every AI tool downstream becomes more useful because the Skills it loads were extracted from real team behavior, not authored by aspirational documentation.

Pulse is making this bet. Our Skills compiler is the most sophisticated auto extraction system we know of. The output is portable to every Skills compatible AI tool. The architecture is designed to compound: as more workspaces use Pulse, the Skills compiler learns more about how different teams handle similar work, and the compilation quality improves for everyone.

Closing: why the Skills bet matters

The agent platforms shipping today are powerful but limited. They give you turnkey workflows for the procedures humans bothered to document. They do not help you with the much larger universe of work your team does every day that has never been written down.

Auto extracted Skills cover that gap. They make AI agents useful not just for the workflows you have documented, but for the workflows you actually run. They keep current as your team evolves. They travel across AI tools, making your team’s institutional knowledge accessible wherever your team works.

This is what we believe the next generation of AI agents will look like. Skills emerging from observed work, calibrated against real outcomes, portable across the AI ecosystem, evolving as teams evolve.

If you are a software team running on Linear, Notion, GitHub, and Slack, Pulse’s Skills compiler is live at pulsehq.tech. The demo workspace includes sample compiled Skills you can browse. No signup required.