In an earlier post I wrote about using Semantic Kernel to create an Agentic AI solution, all using C#. Of course, similar flows can be created with Python. To try this, I’ve created a sample solution to update a resume so it’s more likely to pass the ATS requirements used by various companies nowadays.

My sample is heavilly inspired by Gian Paolo Santopaolo his CV-Pilot repository, which I was not able to use due to the CrewAI tooling phoning home and my DNS (PiHole) blocking those requests. Even after disabling the tracking features, the library/ies still tracked ‘something’, which caused the logic to break so I decided to create something myself using Semantic Kernel.

What did I create?

A tool/flow to update a resume so it can pass the ATS (Applicant Tracking System), based on the job description. These systems ofen check for specific wording and skills. For a human, it takes quite a bit of time to (re)write a resume to pass the ATS requirements. It’s the perfect job for a LLM to perform, as it’s built to create text based on other text input.

You can try doing this in a single prompt, but there’s a high probability this won’t perform the way you like. In my sample, I’ve created a ‘Project Manager’-, ‘Job Market Analyst’- and ‘Strategist’-agent. Each with their own specific job and goals.

We are finally at a state in the GenAI-space where we can create agentic AI solutions with ease.
I’m most familiar with Semantic Kernel, when working with LLMs, and this library works great for creating these solutions.

In a nutshell, what you need to do is create a group chat, add your agents to it, and then let them work together to solve a problem.
Do keep in mind, at the time of this writing, version 1.58.0 of the Semantic Kernel library is used. Development is going fast in this space, so behavior might change in future versions.
For my proof of concept, I’ve created a simple solution capable of creating a Fibonacci sequence, validate if a number is part of that sequence or answer random questions you would also ask to a regular LLM-powered chatbot. If you’re interested, the full sourcecode can be found on GitHub in my console-agent repository.

Create the agents

Agents are created with the ChatCompletionAgent class. You should provide the instructions & the kernel to use.
The instructions is just a regular prompt we all know and love when working with an LLM and specifies what the agent should do. I won’t repeat it over here as it’s not relevant for this post.

I’m very happy GitHub Copilot exists and lately with the Agent-mode it’s even better. It’s making sure I can focus on the relevant pieces of my solutions and not have to worry too much about the plumbing part.

The models it’s using are quite powerful and contains a lot of (old) data. When using new libraries or versions of already existing libraries, the LLMs used under the hood often don’t provide useful suggestions or edits. Currently, telling GitHub Copilot to check the repository of the library to as reference material doesn’t work the way I’d like it to.
I’ve tried this, but it only fetched the contents of the readme file of the repository and didn’t traverse all files and searching for relevant bits.

What I’d like is for GitHub Copilot to index the entire repository/repositories of my libraries of choice and provide me suggestions or edits based on the codebase or documentation.
I figured this can be achieved by adding this capability as an MCP server. Turns out, I’m not the only one who wants this. Leonid Bugaev has created an MCP server solution, docs-mcp, that can be used to search through repositories. It’s powered by Probe, also created by him.

Create an MCP server to search in repositories

The readme of the docs-mcp repository contains all the information to set up your MCP server.

It’s not something a lot of people need to do on a regular basis, but when you do, you don’t want to spend a lot of time doing it. I’m referring to the process of “create an SDK for your APIs”.
When your service is exposing endpoints for your consumers to use, it’s easy to refer them to using raw endpoints and let them figure out how to deal with it based on the Open API specifications (formerly known as Swagger) provided. This requires quite a bit of plumbing on their part. Needless to say, invoking endpoints from your API by using HTTP-calls isn’t very user-friendly and quite error prone. Providing your consumers with a proper SDK is much better from an onboarding perspective.

How to start building an SDK?

As mentioned, either you or your customer needs to do quite a bit of plumbing to invoke your API endpoints properly. This isn’t something anyone will enjoy, so automation is everyones friend over here.

To start, you first need to make sure you are generating Open API specs for the API. Just about every ecosystem has generators for this process. In het .NET ecosystem we’ve been using Swashbuckle for a couple of years now, and with the release of .NET 9 there’s also out-of-the-box capabilities to generate the API specifications.
With these files generated, you’re already halfway of creating an SDK. For best results, be as complete as possible with your Open API specs. Provide descriptions, all error codes, use DTOs, adhere to the HTTP specifications, etc.