Conference talk by Yogendra Miraje (FactSet) on treating agent skills as shippable features: the role of skill.md name and description as routing signals, a minimal skill registry, progressive disclosure, and trigger-word-based skill routing. Covers lessons at scale: evaluating skills as contracts to prevent drift with new models, using search and embeddings beyond ~10 skills, and governance (admission, ownership, audits, change management) past ~100 skills, framing skills as the interface to agentic products. # Video Identity Observations — "Skills are new features: Building Skill-Centric Harness" ## Explicit Self-Description Evidence - **Speaker role and employer**: "I am Yogi. I work at FactSet as principal AI engineer. We are a financial data and research company." - **Prior engagement with the event series**: "In the last year's talk in this very conference I talked about blueprints" — indicating a returning conference speaker. - **Personal social handle**: "That's my X handle, yogi, not the bear" (paraphrased; speaker invites connection via his handle). ## Observable Presentation Evidence ### Intended Audience - **Practitioners who build AI agents/skills**: The speaker polls the room — "How many of you really build skills here? So almost all of you" — showing the audience is assumed to be agent/skill builders. - **Specifically, builders of custom harnesses, not coding-tool users**: "Raise your hand if you have built your own harness and added skills to that… the reason I'm asking is most of the online discourse is about coding harnesses… today I'm not going to talk about that." - **Enterprise/product engineering audience**: Focus is on "skills in the context of agentic products and how to scale it at enterprise scale." ### Claimed Scope of the Talk - Teaching-oriented: "I'm going to talk about how to build skill-centric agentic products and… share some of my learnings from that journey." - Ends with explicit takeaway framing: "Skills are the features in your agentic products. Our role is shifting from shipping features to shipping harnesses… at enterprise scale the skill library governance is really non-negotiable." ### Demonstrated Domain Positioning - **Finance-domain examples**: "Equity research and wealth management are two very important workflows in finance and these all used to be the buttons, dropdowns and screens and now they are merely skills." - **Track record of internal adoption**: Describes migrating from a proprietary "blueprints" standard to Anthropic's open-sourced skills — "there was no point in trying to maintain our own standards." - **Practical production learnings**: Shares concrete operational lessons (e.g., "Skills without evals are really just wishful thinking"; a model upgrade causing skill-following failures). ## Notes on Claim vs. Demonstration - All audience-size observations ("almost all of you", "a few hands") are the speaker's in-room reports, not independently verifiable from the transcript. - Enterprise-scale claims (hundreds of skills, governance frameworks) are presented as learnings from the speaker's own experience; no specific internal metrics are cited. # Delivery Observations: Yogendra Miraje — "Skills are new features" ## Tone - **Conversational and informal** throughout, with light humor: > "So that's my exandle yogi not the bear. Um so let's connect there and uh let's begin." > "even warned us not to build agents. But on serious note..." - **Self-positioned as a practitioner sharing learnings**, not a lecture: > "I'm going to share some of my learnings from that journey." ## Vocabulary - Repeated domain jargon: **"skills," "harness," "agents," "agentic products," "blueprints," "evals," "governance"** — used consistently without re-definition after first introduction. - Occasional finance-specific examples: "equity research," "wealth management," "earnings preparation," "pre-market briefing." ## Recurring Phrases & Rhetorical Patterns - **Question-driven framing** — repeatedly poses a question, then answers it: > "Now if the agent becomes the main interface for your product then where do features live?" > "So what is a skill registry?" > "What does admission even mean? What it means that should this skill even exist..." > "what's the role of engineer? Then the role of engineer is shifting from shipping features to shipping harnesses." - **"So" as a discourse connector** — begins a large share of sentences ("So in the last year's talk...", "So a quick raise of hands", "So let's see how to add a skill support", "So what are the main takeaways"). This is the most frequent verbal habit in the transcript. - **"really" as an intensifier**, used many times: > "skills are really the contracts versioned to a model" > "skills without evals are really just wishful thinking" > "The real trouble really starts when you have hundreds of skills" - **"like" as a filler**, moderate frequency: > "like a good point to think start thinking about, you know, how can you shortlist" > "if you noticed I had like two different skills" ## Teaching Habits - **Audience interaction** — live hand-raising poll early on: > "So a quick raise of hands. How many of you really build skills here?" - **Signposting of scope** — explicitly excludes topics: > "so we need that but today I'm not going to talk about that what I'm going to focus on is skills in the context of agentic products" - **Concrete worked example** — three registry skills carried through the talk: > "Company research skill... a report HTML skill... A report PDF skill" - **Naming and unpacking lists** — enumerated frameworks given memorable labels: > "admission, ownership, boundaries, life cycle and coherence" - **Learning-from-failure storytelling** — cites a real incident to justify a practice: > "we updated our uh stack to a new model and our agent start uh failing... not a single line in the skill was changed but still it failed." - **Memorable aphorisms/punchlines** punctuating sections: > "skills without evals are really just wishful thinking" > "Skills are not the documentation... skills are really the contracts versioned to a model" - **Analogy to established software practice** — repeated comparison to code/PR review: > "we can borrow a lot of good practices from code and apply them to the skills" > "This is very analog log to how we do the PR review process." ## Structure & Closing - **Explicit takeaway summary** at the end — numbered-idea recap: > "So what are the main takeaways? The main takeaways are skills are the features in your agentic products..." - Closes with a brief, direct thanks: "That was my talk. Thank you very much for listening." ## Stability vs. Isolated Moments - **Stable patterns** (high repetition): "So"-initiated sentences, question-then-answer framing, "really" intensifier, list-based structure. - **Isolated moments** (insufficient repetition to call habits): the "yogi not the bear" joke, the hand-raising poll, and the "Sounds very enterprisey right" aside — each appears once, so these are single occurrences rather than patterns. - **Uncertainty note:** filler words ("um," "uh") appear throughout, but transcript-based counts of them may be imprecise due to transcription. # Observation Record: "Skills are new features: Building Skill-Centric Harness" — Yogendra Miraje, FactSet ## Speaker - **Yogendra ("Yogi") Miraje**, Principal AI Engineer at FactSet (transcript renders as "Faxet"), a financial data and research company. ## Central Thesis - **Skills are the new features** in agentic products; engineers' role shifts from shipping features to shipping harnesses. - Framing: **Prompts** define *who* the agent is, **tools** define *what* it connects to, **skills** define *how* a task gets done — skills are where business logic lives. ## Background & Evolution - Last year at this conference he presented **"blueprints"** — recipes handed to agents to avoid re-discovering paths. In retrospect, "it was simply a skill in a very naive form." - Since Anthropic shipped skills (October) and open-sourced them, "there was no point in trying to maintain our own standards" — the team **dropped blueprints and adopted skills fully**. - Scope note: he explicitly excludes coding-agent/coding-harness skill discussion; focus is skills in **agentic products** and **scaling at enterprise level**. ## Definition of a Skill - Dictionary sense: "the ability to do something well" — the model *can* live without it, but does better with it. - Working definition: **a standardized way to teach AI agents how to do a specific task well**. - Structure: `SKILL.md` is the heart; **name and description** in front matter drive discovery; body holds business logic, instructions, and references to files/scripts. ## Minimal Harness Support Three bare-minimum components: - **Skill registry** (name, description, path) - **System prompt** (concatenated registry entries — not skill bodies) - **Basic file read tool**; plus bash/sandbox if running scripts **Discovery mechanism — progressive disclosure:** only name/description/path in system prompt; agent selects and reads full skills as needed. **Agentic loop:** track messages array; call model with messages + tools; append tool calls; on no tool call, end and output result. **Demo (NVDA report):** agent activates company-research skill (web search → markdown), then report-HTML skill. ## Key Learnings / Claims - **Descriptions are routing signals**: e.g., PDF skill description said "use only when user asks for a PDF report" — "PDF" is the trigger word. Descriptions must align with **user requests**, not the skill itself, and be distinct and non-stale. - **Model-driven skills** in agentic products: for non-technical users, skills are not surfaced explicitly to avoid cognitive load (contrast with coding harnesses). - **Cut skills by user intent, not data model**: initial narrow skills (estimation analysis, fundamentals) didn't match real use cases; refactoring is expected. Prefer **"earnings preparation"** over "estimation analysis"; **"pre-market briefing"** over separate news/ratings skills. - **Model upgrades break skills**: after a model update, agent failed to obey skills despite no skill changes — new model focused on the beginning of the skill while critical instructions were at the end. Lesson: **"skills without evals are really just wishful thinking."** - **Skills are not documentation**; they are **contracts versioned to a model** — rerun evals on model upgrades. ## Scaling - **< ~10 skills**: shove into system prompt. - **10+**: shortlist via embeddings/similarity search or a smaller model. - **Hundreds**: need **skill hierarchy, metadata filters, governance**. - Scaling changes routing **mechanism itself**, not just tuning. ## Skill Library Governance — Five Aspects 1. **Admission** — should the skill exist or merge? Automated gate for registries with human-in-the-loop, analogous to PR review. 2. **Ownership** — named maintainers (skill owners), like code owners; maintained by application teams. 3. **Boundaries** — allow-list tools in skills; tools enforce access control. 4. **Life cycle** — semantic versioning, deprecation warnings, change logs. 5. **Coherence** — periodic audits and validation checks so the library makes sense. - Governance "doesn't need to be a red tape bottleneck" — depends on automation and human-in-the-loop design; borrow decades-old code practices. ## Takeaways (as stated) - Skills are the features in agentic products. - Engineer role shifts from shipping features to shipping harnesses. - Routing mechanism changes qualitatively with scale. - At enterprise scale, **skill library governance is non-negotiable**. ## Preserved Qualifications / Tensions - "Even [Anthropic] warned us not to build agents. But on serious note…" — aside, not a substantive claim. - Audience check: most attendees had built skills, few had built their **own harness** with skills. - Refactoring the skill library "multiple times" is framed as acceptable, not a failure. - The 10-skill threshold is stated tentatively ("maybe that's like a good point"). # Speaker Attribution — Skills are new features: Building Skill-Centric Harness ## Speakers - **Yogendra "Yogi" Miraje** — **Creator / sole speaker** - Self-identified: *"Hi everyone, I am Yogi. I work at FactSet as principal AI engineer."* - Note: company name rendered as "Faxet" in the transcript; the title metadata identifies it as **FactSet**. - Delivers the entire talk; no guests, narrators, or other speakers appear. ## Referenced Sources & Third-Party Claims - **Anthropic**: Credited with shipping **skills** (October, per speaker) and open-sourcing them; the speaker states Anthropic "warned us not to build agents." FactSet's adoption of skills over internal "blueprints" is attributed to this release. - **Prior talk (same conference, prior year)**: Speaker references his own earlier presentation on "blueprints." - **Example skills described (illustrative, not cited external works)**: company research skill, report HTML skill, report PDF skill. ## Promotional Segments - **None flagged.** The speaker briefly mentions sharing slides and a personal handle ("that's my handle, yogi not the bear") — informational, not promotional. ## Availability & Uncertainty - **Comment availability**: Not indicated in the supplied material. - **Curated metadata**: Only the title and transcript were supplied; no timestamps available. - **Uncertainty**: Speaker role and employer are explicit in the transcript; no other roles are claimed. Hi everyone, I am Yogi. I work at Faxet as principal AI engineer. We are a financial data and research company. I'm going to talk about how to build skill centric agentic products and I'm going to post slides so you don't have to keep uh taking photos. So that's my exandle yogi not the bear. Um so let's connect there and uh let's begin. So in the last year's talk in this very conference I talked about blueprints and what blueprints were really a simple set of steps or recipe that you can hand over to agents so that agent doesn't have to discover its path every time and when I look back it was simply a skill in a very naive form and a lot has changed since Then Antropic has shipped skills in last year October and even warned us not to build agents. But on serious note since Antropic had already open source the skills there was no point in trying to maintain our own standards. So we moved away from blueprints and just adopted skills fully. And this talk really inspired me to build skill centric agent and I'm going to share some of my learnings from that journey. So a quick raise of hands. How many of you really build skills here? So almost all of you. Now lower your hands if you have built that only in context of cloud code and codeex. and raise your hand if you have like built your own harness and added you know skills to that. So okay so I see a few hands. So reason I'm asking is when I see most of the online discourse it's about you know coding harnesses and skills in context of the coding agents and how to write great skills like so we need that but today I'm not going to talk about that what I'm going to focus on is skills in the context of agentic products and how do you really add support for skills in in your own harness and how to scale it at enterprise scale. So traditionally product used to look like this. A surface made of screens, buttons, forms and dashboards. The user navigated this UI. But nowadays we are seeing more and more these kind of interfaces where agent is at the forefront. The user either talks to the agent or agent behind the scene is the main decision maker helping users navigate your product. Now if the agent becomes the main interface for your product then where do features live? This framing of who, what, and how really helps to answer that question. Prompts define who the agent is. Tools define what it can connect to. And skills really tell you how a task gets done. And this is the great place to keep your business logic that shapes your agents behavior. So skills are the new features. And you can see this with this example. So equity research and wealth management are two very important workflows in uh finance and these all used to be the buttons, dropdowns and screens and now they are merely skills. One of the most uh underrated thing about skills especially when talking about agentric products is how it has enabled to build skills for anyone who has good understanding of the products. So if skills are new features and this new features can be shipped by anyone in the company. The question is what's the role of engineer? Then the role of engineer is shifting from shipping features to shipping harnesses. Harnesses that are smooth vehicles for your skills to run. But before diving into that, let's just get to the basics and try to understand what skill is. The dictionary meaning of skill is the ability to do something well. And what it means is that your model can live with it without it. But it obviously going to do better in presence of skill. A better definition for agent skill is a standardized way to teach AI agents how to do a specific task well. And a simple skill could contain just like a markdown but a very complex can have multiple references to the files and executable scripts. The skill.md is the heart of your skill. Name and description in the front matter are the key uh things that will help you to discover the skill and the business logic and instruction goes into the body of the skill and which will also contain references to the files and scripts. So let's see how to add a skill support in your harness. So what do you need to do like a bare minimum skill in your harness? You only need these three things like skill registry, a system prompt, and a basic file read tool. If you're running scripts, then obviously you're going to need either bash or maybe a code uh running sandbox environment. But this is the bare minimum requirement for adding support of skills like in your harness. A simple skill registry looks like this. So what is a skill registry? It just like collection of skills with their name, description and path. And we are going to see this with three example skills. Company research skill which is supposed to do a very basic web search for a company and produce a markdown. a report HTML skill that will turn the markdown into an HTML. A report PDF skill that will take that markdown and turn into PDF. Now how does really the agent discover the skill? So you have your registry then you form a skill concat concatenating the name description path and put it in your system prompt. So if you notice like we are only using the name and description path in in this system prompt and not the skill body and that's what what they call about is progressive disclosure. Agent is going to read the skills and only pick the skills that it is going to read and follow the instructions from there. And then you need your agentic loop that will run this system prompt. Here we're keeping track of all the messages in uh in that messages array and we're going to call the model with messages and agent tools and for every turn it's either looking for like making a tool call and all the tool calls get appended to the messages and if there is like no tool call we are just going to output the end of the uh program and going to show the output. So in this case what does like agent see in our example. So it sees that the skills that are available and then the activation part is when it looks for the company research skill for take this example of if you're asking to publish a report of NVDI it is going to call company research do the web searches and then use the build report skill to produce the report HTML And the output looks like something like this. Now what are the learnings from some of this is the descriptions are really the routing signals. And what I mean by that if you noticed I had like two different skills report HTML and report PDF. But when I showed the example, you saw only HTML. And the reason is I have this description saying that use the skill only when user ask for a PDF report. Focus on this word PDF. Right? So that is the trigger word that helps agent to know which skill to pick and that's why descriptions are called routing signals. And it's very important to keep your descriptions aligned to the user request and not about the skill itself. It's also important to keep your descriptions distinct enough so that agent doesn't get confused and make sure don't let your skills get stale because these are the reasons why your skills don't get triggered. One more like very important difference between like skills when we talk in agentic product context is most of the skills are only model driven because for nontechnical users we're not adding that cognitive load to remember them uh to keep the track of all the skills. Another learning that had was cut by user intent and not by data model. So when I started building the skill library, I had very narrow use cases. So add skill for estimation analysis or add for fundamentals. But I got real use cases and those use cases were not reflecting the data model. Those were really about the real use cases and I had to refactor this multiple times and that is okay, right? you start simply with narrower use cases and as you discover more use cases you start refactoring your skill library. So in practice it means that you know instead of having an estimate analysis skill you should have earning preparation skill instead of having a skill for news and analysis analyst rating skill you should have a pre-market briefing skill. So we updated our uh stack to a new model and our agent start uh failing because it was not obeying the skills. Nothing was changed. Not a single line in the skill was changed but still it failed. And when when we dig under the hood what was happening it was that this like new model was very focusing on beginning of the skill and we had very critical instruction at the end of the skill. So that's why it's very important to run evals and skills without evals are really just wishful thinking. Skills are not the documentation and a lot of people treat them like that and skills are really the contracts versioned to a model. So whenever you're upgrading a model, make sure to rerun uh your eval. So when you have like a few skills, shoving them in the system prompt really works. But as soon as you start growing your skill stack, this falls apart. When you have like more than 10 skill, maybe that's like a good point to think start thinking about, you know, how can you shortlist the skills that you're going to add to the system prompt. And this could mean just like having embeddings and have similarity search and short lists or a smaller model that can shortlist the skills and add to the system prompt. The real trouble really starts when you have hundreds of skills. At that point, you really need hierarchy of skills and metadata filters and the governance in the place to keep your uh library searchable and coherent. So there are like five aspect of skill library governance and these are admission, ownership, boundaries, life cycle and coherence. Sounds very enterprisey right but each of this really answer like a very core question and we will get to that in a second. But when you hear governance, it really doesn't need to be a red tape bottleneck. It really depends on how you're implementing it. How much automation is in place with proper human in the loop. And the good news is that we can borrow a lot of good practices from code and apply them to the skills. And these coding practices like has worked for decades. So what does admission even mean? What it means that should this skill even exist or it should go to an already existing skill. And in practice we build automated get for the registries with human in the loop. And this is very analog log to how we do the PR review process. Who maintains your skill? Just like how features are maintained by application teams, we need skills to be maintained by application teams. And like code owners, we need to have a dedicated skill owners like named maintainers for your skills. What happens to the skill over time? You need to have semantic version of the skills and also whenever you're getting rid of skills you need to have deprecation warnings and make sure that your changes are reflected in the change logs. So when you have large number of skills, the library should still make sense. And just like features are cohesive in a good product, we need to make sure that we are conducting periodic audits and skill validation checks so that your skills would really make sense. Whenever you have a lot of skills, it's important to have the allow list tools in in the skills and your tools are supposed to be access control and this is very important to keep the correct boundaries around skills. So what are the main takeaways? The main takeaways are skills are the features in your agentic products. Our role is shifting from features that is shipping features to shipping harnesses and routing mechanism doesn't get tuned as you scale. It changes the mechanism itself and at enterprise scale the skill library governance is really non-negotiable. That was my talk. Thank you very much for listening. \>\> \[music\]