DEV Community: Dmitry Bogomolov

Building FatAdvisor: A .NET Nutrition AI Agent. Part 2: Agent goes outside

Dmitry Bogomolov — Sat, 10 Jan 2026 13:11:21 +0000

In the previous episodes…
- Plugins
Coding
- Interfaces and Stubs
- Plugin implementation
Dependency Injection
Running the Application
Conclusions

In the previous episodes...

we created a .Net application powered by Semantic Kernel. We connected it to GitHub Models and added a basic system message asking it to act as a nutrition and fitness assistant.

From the technical standpoint, we also created a basic "architecture", splitting the solution into three projects:

AI — AI-related logic,
FatSecretAPI — for integrating FatSecret API,
Console — a simple basic interface for user interactions.

So far the app runs and answers our questions, but it still doesn't know anything about us! It's time to give it some hints, showing who we are and what do we eat.

In this chapter we will create a Plugin for Semantic Kernel. But first, let’s quickly discuss what a Plugin actually is.

Plugins

In Semantic Kernel documentation we can read that Plugins "encapsulate your existing APIs into a collection that can be used by AI". Basically, there are two main types of things we can encapsulate in a Plugin: something to fetch and something to do. For example, AI agent in your IDE can read your codebase ("fetch data") and make changes in the code ("do actions").
This concept is what makes an agent an agent: a language model itself is like a head in a jar (any Futurama fans?), and Plugin is an interface that connects this "head" with the world around it.

In general, there are four ways of providing a plugin to your app:

adding native code plugin (Microsoft documentation),
adding OpenAPI as a plugin (Microsoft documentation),
adding plugin from an MCP server (Microsoft documentation),
integrating with Azure Logic Apps (Microsoft documentation).

Our application's main goal is actually to learn, so we will go with the first option - a native code plugin. This means that we will implement a C# class with all the logic we need.

The other three options are more specific. They can be useful, but I don't want to concentrate on them now, so we don't get distracted from our basic application.

Just a small remark: the OpenAPI option looks too interesting to completely ignore. If you have created some HTTP APIs you probably know what Swagger/OpenAPI is. In Semantic Kernel you can introduce your OpenAPI specification by providing a link to it. And then, your LLM can send HTTP requests to the endpoints described in your specification. Sounds like a fun thing to try out one day! See the link above to read more about this way of introducing a Plugin.

Anyway, let's get back to our FatAdvisor and to our decision to implement the Plugin as a native code (a C# class).

We want our LLM to be able to fetch some knowledge from the outside. In this version of the app, we won't teach our agent to invoke any actions, we will only let it receive the data it needs. We create what is, from the programming language's point of view, a class with methods. Each of these methods will provide some functionality for the LLM to use. Though "method" is a common concept in OOP and in C# in particular, in AI agent terminology you will find such entry points called "functions", "tools" or "actions". Semantic Kernel allows us to provide descriptions for these methods via attributes. The LLM then reads these descriptions, and it should be enough for it to understand for which purposes which function can be invoked.

We will implement our Plugin as a C# class, so we can inject any services (HTTP clients, DB connections etc.) in it. In our case, the Plugin that we're going to make will be a wrapper over the FatSecret API. We will add only those functions that our application really needs.

Coding

Interfaces and Stubs

To keep this chapter from becoming too long and to concentrate on the Plugin itself, we will not implement the real integration with third-party services such as the FatSecret API or any others. We will define interfaces and create stub implementation of it imitating the desired behavior. Don't worry — the real implementation will be described in the next chapter. In addition, with these mocking services I can lie to our FatSecret giving it much better impression of what I'm eating than my real diet.

Let's define what interfaces we need:

IFatSecretApiClient - the most important interface for us. It will contain the methods that we can invoke in FatSecret API. The real version sends HTTP requests, while the stub simply returns predefined responses.
IFatSecretOAuth - the authorization workflow for FatSecret.
IProfileTokenStorage - not really mandatory, but we want to store our token returned by IFatSecretOAuth, so we can reuse and refresh them properly.

And for each of them let's create a stub implementation that returns static data.

Now the FatAdvisor.FatSecretApi project structure will look like this:

Stubs
- ApiStubData
  - FoodLog0.json
  - WeightLog0.json
- FatSecretApiClientStub.cs
- FatSecretOAuthStub.cs
- ProfileTokenStorageStub.cs
FatSecretApiModule.cs

In the ApiStubData folder there are JSON files that imitate responses from the FatSecret API.

FatAdvisor.FatSecretApi/Stubs/ApiStubData/FoodLog0.json:
(full sample JSON file is available in the repository)

{
  "food_entries": {
    "food_entry": [
      {
        "calories": "64",
        "carbohydrate": "13.32",
        "date_int": "20394",
        "fat": "0.24",
        "food_entry_description": "0.3 serving 30 g Bread slice",
        "food_entry_id": "72145983012",
        "food_entry_name": "Bread slice",
        "food_id": "84213058",
        "meal": "Breakfast",
        "number_of_units": "0.300",
        "protein": "2.19",
        "serving_id": "29396720"
      },
      ...
    ]
  }
}

FatAdvisor.FatSecretApi/Stubs/ApiStubData/WeightLog0.json:
(full sample JSON file is available in the repository)

{
  "month": {
    "day": [
      {
        "date_int": "20362",
        "weight_kg": "60.7000"
      },
      ...
    ],
    "from_date_int": "20362",
    "to_date_int": "20392"
  }
}

Here's the implementation of FatSecret API client that reads data from these stub files:

FatAdvisor.FatSecretApi/Stubs/FatSecretApiClientStub.cs:

using FatAdvisor.Ai;
using FatAdvisor.Ai.Models;

namespace FatAdvisor.FatSecretApi.Stubs
{
    public class FatSecretApiClientStub : IFatSecretApiClient
    {
        private static Task<string> ReadDataFromFile(string fileName)
        {
            var filePath = Path.Combine("Stubs", "ApiStubData", fileName);
            return File.ReadAllTextAsync(filePath);
        }

        public Task<string> GetFoodsForDateAsync(DateTime date) => ReadDataFromFile("FoodLog0.json");

        public Task<string> GetWeightDiary(DateTime date) => ReadDataFromFile("WeightLog0.json");

        public void SetAccessToken(TokenInfo tokenInfo)
        {
            // Do nothing
        }
    }
}

We also need to make temporary fake services for authorization. We need just to return something, any string will work.

FatAdvisor.FatSecretApi/Stubs/FatSecretOAuthStub.cs:

using FatAdvisor.Ai;
using FatAdvisor.Ai.Models;

namespace FatAdvisor.FatSecretApi.Stubs
{
    public class FatSecretOAuthStub : IFatSecretOAuth
    {
        public Task<TokenInfo> GetAccessTokenAsync(string requestToken, string requestTokenSecret, string verifier) => 
            Task.FromResult(new TokenInfo("access_token_stub", "access_token_secret_stub") );

        public string GetAuthorizationUrl(string requestToken, string? callbackUrl) => $"http://localhost?token={requestToken}";

        public Task<TokenInfo> GetRequestTokenAsync(string? callbackUrl) => 
            Task.FromResult(new TokenInfo("request_token_stub", "request_token_secret_stub") ); 
    }
}

The same with the token storage service. Earlier we pretended to receive a token, now we pretend to store it:

FatAdvisor.FatSecretApi/Stubs/ProfileTokenStorageStub.cs:

using FatAdvisor.Ai;
using FatAdvisor.Ai.Models;

namespace FatAdvisor.FatSecretApi.Stubs
{
    public class ProfileTokenStorageStub : IProfileTokenStorage
    {
        public Task<TokenInfo> FindTokenInStorage() => Task.FromResult(
            new TokenInfo("access_token_stub", "access_token_secret_stub"));

        public Task SaveTokenToStorage(TokenInfo accessTokenInfo) => Task.CompletedTask;
    }
}

Plugin implementation

We have created a fake implementation of external services and now we are ready for the most interesting part of this chapter. We are going to create The Plugin!

There are two main functions we need for our agent to start with:

get_consumed_food – get all the consumed food (food log) for the selected day.
get_weight_diary – get the weight diary for the month until the specified date

They will help us find the answer to the main nutrition questions: what did I eat and what are the consequences of it? We will explain to the agent that it can use these functions when it needs them.

So here's the implementation. Let's take a look at it, and then we will walk through it. It's very simple:

FatAdvisor.Ai/FatSecretProfileDataPlugin.cs:

using FatAdvisor.Ai.Models;
using Microsoft.SemanticKernel;
using System.ComponentModel;

namespace FatAdvisor.Ai
{
    public class FatSecretProfileDataPlugin
    {
        private readonly IFatSecretApiClient _fatSecretApiClient;
        private readonly IFatSecretOAuth _fatSecretOAuth;
        private readonly IProfileTokenStorage _profileTokenStorage;

        public FatSecretProfileDataPlugin(
            IFatSecretApiClient fatSecretApiClient,
            IFatSecretOAuth fatSecretOAuth,
            IProfileTokenStorage profileTokenStorage)
        {
            _fatSecretApiClient = fatSecretApiClient;
            _fatSecretOAuth = fatSecretOAuth;
            _profileTokenStorage = profileTokenStorage;
        }

        [KernelFunction("get_consumed_food")]
        [Description("Get all the consumed food (food log) for selected day")]
        public async Task<string> GetConsumedFood(DateTime date)
        {
            var accessTokenInfo = await _profileTokenStorage.FindTokenInStorage();
            if (accessTokenInfo == null)
            {
                // If no token is found, we need to authorize the user
                accessTokenInfo = await AuthorizeAndSaveToken();
            }

            _fatSecretApiClient.SetAccessToken(accessTokenInfo);

            var todaysFood = await _fatSecretApiClient.GetFoodsForDateAsync(date);
            return todaysFood;
        }

        [KernelFunction("get_weight_diary")]
        [Description("Get the weight diary for month due to the specified date")]
        public async Task<string> GetWeightDiaryForMonth(DateTime date)
        {
            var accessTokenInfo = await _profileTokenStorage.FindTokenInStorage();
            if (accessTokenInfo == null)
            {
                // If no token is found, we need to authorize the user
                accessTokenInfo = await AuthorizeAndSaveToken();
            }

            _fatSecretApiClient.SetAccessToken(accessTokenInfo);

            var todaysFood = await _fatSecretApiClient.GetWeightDiary(date);
            return todaysFood;
        }

        private async Task<TokenInfo> AuthorizeAndSaveToken()
        {
            string? callbackUrl = null; //For prototype we could use null.

            var requestTokenInfo = await _fatSecretOAuth.GetRequestTokenAsync(callbackUrl);
            var authorizationUrl = _fatSecretOAuth.GetAuthorizationUrl(
                requestTokenInfo.Token,
                callbackUrl);

            Console.WriteLine($"Please visit: {authorizationUrl}");

            Console.WriteLine("\nPaste the verifier code here:");
            string verifier = Console.ReadLine() ?? "";

            var accessTokenInfo = await _fatSecretOAuth.GetAccessTokenAsync(
                requestTokenInfo.Token,
                requestTokenInfo.TokenSecret,
                verifier);

            await _profileTokenStorage.SaveTokenToStorage(accessTokenInfo);

            return accessTokenInfo;
        }
    }
}

In the constructor there's nothing extraordinary. We just inject our interfaces (the rules for resolving them will be specified in the Autofac module).

Speaking of Task<TokenInfo> AuthorizeAndSaveToken(), inside this method we call _fatSecretOAuth to execute the 3-legged OAuth logic. We will discuss it in the next chapter where we will talk about real integration with the FatSecret API. But for now it's enough to understand that this method receives an access token for the FatSecret API and stores it (via _profileTokenStorage abstraction).

But the real shiny stars of our plugin are these two tiny Functions: GetConsumedFood and GetWeightDiaryForMonth. What's going on inside is very straightforward:

Try to find an access token for the FatSecret API in the storage.
If it's not there, authorize via OAuth dance and store the received token in the storage. Thus, on the upcoming iteration we will save some resources by not requesting OAuth endpoints again and again.
Invoke the appropriate method of FatSecret API.

A piece of cake, right?
What is interesting here, first, the attributes. These two small guys tell the LLM something important:

[KernelFunction("get_consumed_food")]
[Description("Get all the consumed food (food log) for selected day")]
public async Task<string> GetConsumedFood(DateTime date)

Actually, they provide metadata to LLM.
The KernelFunction attribute is needed to mark this C# method as a SemanticKernel's function. In other words, that's how we tell the LLM that this method is for it to invoke.

The Description attribute serves to give more context. Let's admit, we're living in the future. Through all these years of evolution of programming languages we learned and learned to speak with computers in a formal, deterministic way, through these programming languages. But now we have to decorate our beautiful C# code with wordy, redundant human language. This is the future — but are we happy?

Ok, just kidding.

But I hope you got the idea: with this attribute we can describe the function for the LLM, providing more information — like what this function is supposed to do, or in which situation the LLM might consider running it.

Unless KernelFunction, which is required in the general case for Semantic Kernel functions, the Description attribute is optional. And as the documentations says, we should rely more on concise and understandable function names (and parameter names as well), and use the Description attribute "only when necessary to minimize token consumption."

DI

That's how we register our Semantic Kernel and plugins in the DI container:

FatAdvisor.Ai/FatSecretAiModule.cs:

using Autofac;
using Microsoft.Extensions.Configuration;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Logging;
using Microsoft.SemanticKernel;

namespace FatAdvisor.Ai
{
    public class FatSecretAiModule : Module
    {
        private readonly IConfiguration _config;

        public FatSecretAiModule(IConfiguration config) => _config = config;

        protected override void Load(ContainerBuilder builder)
        {
            var apiKey = _config["GitHubModels:ApiKey"];
            var endpoint = _config["GitHubModels:Endpoint"];
            var modelId = "gpt-4o-mini";

            builder
                .Register(ctx =>
                {
                    var loggerFactory = ctx.Resolve<ILoggerFactory>();

                    var kernelBuilder = Kernel.CreateBuilder();

                    kernelBuilder.Services.AddSingleton(loggerFactory);

                    kernelBuilder.AddOpenAIChatCompletion(
                        modelId: modelId,
                        apiKey: apiKey,
                        endpoint: new Uri(endpoint));

                    // Register plugins during Kernel construction
                    var fatSecretPlugin = ctx.Resolve<FatSecretProfileDataPlugin>();
                    kernelBuilder.Plugins.AddFromObject(fatSecretPlugin);

                    return kernelBuilder.Build();
                })
                .As<Kernel>()
                .SingleInstance();

            builder.RegisterType<FatSecretProfileDataPlugin>().AsSelf().SingleInstance();
        }
    }
}

And that's how we register our stubs:

FatAdvisor.FatSecretApi/FatSecretApiModule.cs

using Autofac;
using FatAdvisor.Ai;
using FatAdvisor.FatSecretApi.Stubs;
using Microsoft.Extensions.Configuration;

namespace FatAdvisor.FatSecretApi
{
    public class FatSecretApiModule : Module
    {
        private readonly IConfiguration _config; // Not used right now, but will be useful later.

        public FatSecretApiModule(IConfiguration config) => _config = config;

        protected override void Load(ContainerBuilder builder)
        {
            builder.RegisterType<FatSecretOAuthStub>().As<IFatSecretOAuth>().SingleInstance();

            builder.RegisterType<FatSecretApiClientStub>().As<IFatSecretApiClient>().SingleInstance();

            builder.RegisterType<ProfileTokenStorageStub>().As<IProfileTokenStorage>().SingleInstance();
        }
    }
}

Running!

It seems like we are ready to run the app and ask the Fat Advisor some questions. I've modified the ConsoleAppRunner class to formulate both the system and user messages a bit more concretely.
I won't put the whole code of this class here (you can find it in the repo).
Just to highlight the most important parts of the messages:

var yesterday = DateTime.Now.AddDays(-1);

var chatHistory = new ChatHistory();
chatHistory.AddSystemMessage("You are a nutrition and training assistant. " +
    "When answering the user, always consider user's FatSecret profile data including: " +
    $"FatSecret food log for the last 2 days (check it for every day in the range of last 2 days until {yesterday}. " +
    "If available, consider user's weight diary (for the last month) to understand what " +
    "amount of food should be taken. In your response display weight diary and consumed food diary. ");

var userMessage = "Please review my nutrition habits and give me advice on what I should change to gain muscle without gaining fat.";

Let's run the app, and that's what we see in the console:

dbug: Microsoft.SemanticKernel.Connectors.OpenAI.OpenAIChatCompletionService[0]
      Function choice behavior configuration: Choice:auto, AutoInvoke:True, AllowConcurrentInvocation:False, AllowParallelCalls:(null) Functions:FatSecretProfileDataPlugin-get_consumed_food, FatSecretProfileDataPlugin-get_weight_diary
info: Microsoft.SemanticKernel.Connectors.OpenAI.OpenAIChatCompletionService[0]
      Prompt tokens: 224. Completion tokens: 116. Total tokens: 340.

Ok, this should look familiar and was discussed in the Part 1. There's a summary of tokens consumption and the basic configuration.

Next, we can see the log of Function calls like that:

info: Microsoft.SemanticKernel.KernelFunction[0]
      Function FatSecretProfileDataPlugin-get_consumed_food invoking.
info: Microsoft.SemanticKernel.KernelFunction[0]
      Function FatSecretProfileDataPlugin-get_consumed_food succeeded.
info: Microsoft.SemanticKernel.KernelFunction[0]
      Function FatSecretProfileDataPlugin-get_consumed_food completed. Duration: 0.0447523s

We see similar logs for every function invocation, which is good and shows that the model correctly selected which functions to call based on the prompt and available plugins.

And finally, after all these log records, we see the model's response! Here I'll put just some fragments of it, not the whole text.

### Your Nutrition and Weight Diary Overview

#### Weight Diary (Last Month)
| Date       | Weight (kg) |
|------------|-------------|
| 2025-05-03 | 60.7        |
| 2025-05-10 | 60.3        |
| 2025-05-12 | 61.1        |
| 2025-05-22 | 60.8        |
| 2025-05-27 | 61.0        |

#### Consumed Food Diary
**June 3, 2025:**
| Meal      | Food Description                      | Calories | Protein | Carbohydrates | Fat  |
|-----------|--------------------------------------|----------|---------|---------------|------|
| Breakfast | Caramel pastry (50g)                 | 275      | 4.00    | 20.75         | 19.75|
| Breakfast | Bread slice (30g)                    | 64       | 2.19    | 13.32         | 0.24 |
...

### Nutrition Advice for Muscle Gain without Fat Gain

1. **Increase Protein Intake**: Your protein intake for each day (~49g) is relatively low for muscle gain. Aim for at least **1.6 to 2.2 grams of protein per kilogram of body weight**, which, considering your weight (around 61 kg), should be approximately **100g to 130g** of protein daily.

2. **Quality Carbohydrates**: The carbohydrates in your diet are significant; however, focus on complex carbs (whole grains, oats, sweet potatoes, legumes) rather than sugars and processed foods like the milk chocolate. These will provide sustainable energy for your workouts.

...

Well, that looks pretty fair!

Conclusions

Today we learned how to introduce some Functions to an AI agent. They are pretty simple and only cover the data retrieval part. We know that AI agents can also perform actions, but we haven't implemented anything like that yet. Maybe later we can add it, at least as an example.

We taught our agent to receive data about our food intake and weight. The data is still fake, so we kind of lie to the agent — but it's in the name of research!

In the next chapter I'm going to make a couple of steps from AI and Semantic Kernel itself and focus on implementing real interaction with the FatSecret API. This part will be more for those who want to play with the FatSecret API on their own, rather than for those who are learning Semantic Kernel. But I think it should be fun. We want to make things real, right?

[Boost]

Dmitry Bogomolov — Fri, 17 Oct 2025 08:25:21 +0000

Building FatAdvisor: A .NET Nutrition AI Agent. Part 1: Building the Foundation

Dmitry Bogomolov ・ Oct 15

#dotnet #programming #ai #semantickernel

Building FatAdvisor: A .NET Nutrition AI Agent. Part 1: Building the Foundation

Dmitry Bogomolov — Wed, 15 Oct 2025 16:23:13 +0000

Intro
- AI agents
- The project
It goes technical
- Choosing the technologies
- Solution structure
  - AI model
- Starting coding!
  - DI
  - Program.cs
  - ConsoleAppRunner
  - Running
Conclusions

Intro

AI agents

AI is a pretty big deal nowadays, right? Large Language Models (LLMs) help us everyday with various tasks. Popular models are already replacing search engine interfaces. Also, if you're a programmer, you probably already use AI-powered features in your IDEs.

For a user, an LLM feels a bit like a huge, smart database you can query in natural language. But it's also quite intriguing, how can we make it not only answer our questions, but do things. And that's where AI agents come in.

There are many nice well-written articles and courses about AI agents, so I won't repeat definitions or theory here too much. We're here for some practice, aren't we? The only thing I think is crucial to understand is that a "Tool" can be basically anything that can provide data for an LLM (for example, an external database) or provide the ability to make actions (e.g. a 3rd party API allowing to modify data in an external system).

What excites me is that an agentic AI can decide by itself whether to use any of the available tools, in what order, and for what purposes. As developers we just provide some "handlebars", but it's up to the LLM how and when to use it.

Driven by a desire to build an agent by myself in educational purposes, I looked for a personally useful use case... and that's where FatAdvisor appears.

The project

Ok, FatAdvisor might sound a bit rude, I admit it. But let me explain! This agent will use the API of the FatSecret app. FatSecret is an amazing app for those who try to track their food intake. I mean, come on — I'm in my mid-30s. I want... no, I have to care about what I consume!

In general, it's great to see your calories, fats, carbs and proteins if you have specific goals — whether it’s losing some weight, gaining muscle mass, or just being curious (and nerdy) enough to track your diet no matter what.

Thus, I've been using the app for quite a while, and I became curious: how could I use this data that’s already being collected there?

So the idea was to give an AI model the access to my FatSecret profile and ask it for advice about my nutritional habits. And that’s how the name FatAdvisor appeared.

The first use case scenario for it would be:

retrieve my food diary for the last couple of days,
retrieve my weight diary for the same period,
analyze them and answer my questions like: “What should I eat for dinner today?” or “What should I change in my habits?”

Fortunately, FatSecret provides an HTTP REST API that can provide this data.

It goes technical

Choosing the technologies

Ok, now let's move on to the real world and choose the technologies for our project.

I am a .Net developer. I love it so much that writing C# for eight hours a day at work isn’t enough — I still want to keep coding in my personal time!

But seriously, I just feel like I can focus more on the agentic AI part of my projectif I use a language and framework I’m already comfortable with. Besides, .Net is a very stable and mature stack for building maintainable, production-ready solutions.

.NET already provides several great tools for integrating AI into applications. For this project, I chose Semantic Kernel — an SDK designed for creating and orchestrating AI agents. Sounds exactly like what we need!

With the help of Semantic Kernel connectors we can use different AI model providers.
Speaking of which, I'm currently playing with GitHub Models. Free usage is available, and that is good for a Proof-of-Concept type of project.

For prototyping goals I decided not to implement a web UI yet and instead start with a simple console app.

In this first article, we’ll focus on wiring up Semantic Kernel with GitHub Models in a minimal console application. Later, we’ll expand the solution with a plugin for the FatSecret API.

Solution structure

Our system design will be very simple — I don’t want to overcomplicate things at this prototype stage. Let’s create a Visual Studio solution with three projects::

FatAdvisor.Console - a console application that will act as a very basic "UI" for user interaction.
FatAdvisor.Ai - the core project of the solution. It contains all the logic fpr working with Semantic Kernel and other AI-related things.
FatAdvisor.FatSecretApi - let's locate all the details of working with FatSecret API inside this project. You know, DTOs for HTTP requests/responses, HTTP clients, well, all the things you do when integrating with a third-party API.

Let's create the solution, add the projects, and set up the references between them:

dotnet new sln -n FatAdvisor

dotnet new console -o FatAdvisor.Console
dotnet new classlib -o FatAdvisor.Ai
dotnet new classlib -o FatAdvisor.FatSecretApi

dotnet sln FatAdvisor.sln add ./FatAdvisor.Console/FatAdvisor.Console.csproj
dotnet sln FatAdvisor.sln add ./FatAdvisor.Ai/FatAdvisor.Ai.csproj
dotnet sln FatAdvisor.sln add ./FatAdvisor.FatSecretApi/FatAdvisor.FatSecretApi.csproj

dotnet add ./FatAdvisor.Console/FatAdvisor.Console.csproj reference ./FatAdvisor.Ai/FatAdvisor.Ai.csproj
dotnet add ./FatAdvisor.Console/FatAdvisor.Console.csproj reference ./FatAdvisor.FatSecretApi/FatAdvisor.FatSecretApi.csproj

Next, let’s install the required NuGet packages:

dotnet add FatAdvisor.Console package Autofac
dotnet add FatAdvisor.Console package Autofac.Extensions.DependencyInjection
dotnet add FatAdvisor.Console package Microsoft.Extensions.Configuration.EnvironmentVariables
dotnet add FatAdvisor.Console package Microsoft.Extensions.Configuration.UserSecrets
dotnet add FatAdvisor.Console package Microsoft.Extensions.Hosting
dotnet add FatAdvisor.Console package Microsoft.Extensions.Logging
dotnet add FatAdvisor.Console package Microsoft.Extensions.Logging.Console
dotnet add FatAdvisor.Console package Microsoft.SemanticKernel

dotnet add FatAdvisor.FatSecretApi package Autofac
dotnet add FatAdvisor.FatSecretApi package Microsoft.Extensions.Configuration.Abstractions
dotnet add FatAdvisor.FatSecretApi package Microsoft.Extensions.Http

dotnet add FatAdvisor.Ai package Autofac
dotnet add FatAdvisor.Ai package Microsoft.Extensions.Configuration.Abstractions
dotnet add FatAdvisor.Ai package Microsoft.SemanticKernel

Note: The solution was tested with the following versions:

Autofac – 8.1.0
Autofac.Extensions.DependencyInjection – 10.0.0
Microsoft.Extensions.* – 9.0.8
Microsoft.SemanticKernel – 1.62.0

AI model

Now we need to choose what we'll use as the "brain" of our system. Since this project is more about self-education than building a real production-ready app, I was looking for a free, easy-to-use solution — and chose GitHub Models. This platform gives us a chance to play with various LLMs. You need to create one single token, and then you can quickly switch between models whenever you want.

For more information about GitHub Models, including limits, quick start examples and much more please visit GitHub Docs page.

First we need to create a token. There are two options: fine-grained tokens and classic tokens.. GitHub recommends to switch to fine-grained tokens when possible. The difference is that a classic token would have access to all your repositories, while for a fine-grained one, you can restrict which repositories it can access, or even grant no repository access at all (which is what we need here).

Go to https://github.com/settings/personal-access-tokens
Select "Fine-grained tokens" and click "Generate new token".
Choose any name for your token, set an expiration time, and adjust the settings as you prefer.
Under “Permissions”, click “Add permissions”, then choose “Models”.

Click “Generate token”. After the token is generated, copy it and store it securely, because you won’t be able to view it again later.

Finally, we need to pick which model to use. Here's the Marketplace for GitHub Models where you can see what is available. For my project, I'll start with GPT‑4o mini.

Starting coding!

Dependency Injection (DI)

First, let's create an Autofac module in both Ai and Api projects. We use Autofac for dependency injection across our solution. Initially, the DI configuration will be pretty small, but in the next chapters the modules will be useful for registering new components.

By the way, if you're not familiar with the concept of modules in Autofac — they are classes that help you break down dependency injection configuration into logically isolated files. You can read more about them in the Autofac documentation.

FatAdvisor.Api/FatSecretApiModule.cs

using Autofac;
using Microsoft.Extensions.Configuration;

namespace FatAdvisor.FatSecretApi
{
    public class FatSecretApiModule : Module
    {
        private readonly IConfiguration _config;

        public FatSecretApiModule(IConfiguration config) => _config = config;

        protected override void Load(ContainerBuilder builder)
        {
        }
    }
}

That's it for now for the Api module. It's empty cause we don't have anything to register yet.

The Ai module is a bit more interesting:

FatAdvisor.Ai/FatSecretAiModule.cs

using Autofac;
using Microsoft.Extensions.Configuration;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Logging;
using Microsoft.SemanticKernel;

namespace FatAdvisor.Ai
{
    public class FatSecretAiModule : Module
    {
        private readonly IConfiguration _config;

        public FatSecretAiModule(IConfiguration config) => _config = config;

        protected override void Load(ContainerBuilder builder)
        {
            var apiKey = _config["GitHubModels:ApiKey"];
            var endpoint = _config["GitHubModels:Endpoint"];
            var modelId = "gpt-4o-mini";

            builder.Register(ctx =>
            {
                var loggerFactory = ctx.Resolve<ILoggerFactory>();

                var kernelBuilder = Kernel.CreateBuilder();

                kernelBuilder.Services.AddSingleton(loggerFactory);

                kernelBuilder.AddOpenAIChatCompletion(
                    modelId: modelId,
                    apiKey: apiKey,
                    endpoint: new Uri(endpoint));

                return kernelBuilder.Build();
            }).As<Kernel>()
              .SingleInstance();
        }
    }
}

Here, we use configuration values to locate our GitHub Models settings (ApiKey and Endpoint). For now, the model ID is hardcoded to "gpt-4o-mini", though we could easily move it to configuration later.

Next, we register an instance of the Kernel class. This is a core class of SemanticKernel, and we will interact with the AI models through it. Also later we will register our agentic plugins here.

Program.cs

Now let's create an entry point for the console app — Program.cs.
I will describe what happens in the code through inline comments

FatAdvisor.Console/Program.cs:

using Microsoft.Extensions.Configuration;
using FatAdvisor.FatSecretApi;
using FatAdvisor.Ai;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Logging;
using Autofac.Extensions.DependencyInjection;
using Autofac;
using Microsoft.Extensions.Hosting;

namespace FatAdvisor.Console
{
    internal class Program
    {
        private static async Task Main(string[] args)
        {
            var host = Host.CreateDefaultBuilder(args)

                    // Adding Autofac for dependency injection
                    .UseServiceProviderFactory(
                        new AutofacServiceProviderFactory()) 

                    // Configure app settings (User Secrets 
                    // + Environment Variables)
                    .ConfigureAppConfiguration((context, config) =>
                    {
                        config.AddUserSecrets<Program>();
                        config.AddEnvironmentVariables();
                    })

                    // We want to log a lot of things
                    // to trace how it actually works
                    .ConfigureLogging(logging =>
                    {
                        logging.ClearProviders();
                        logging.AddConsole();
                        logging.SetMinimumLevel(LogLevel.Debug);
                    })

                    // Register Autofac modules and application services
                    .ConfigureContainer<ContainerBuilder>((context, builder) =>
                    {
                        // Register your modules here
                        builder.RegisterModule(
                            new FatSecretAiModule(context.Configuration));
                        builder.RegisterModule(
                            new FatSecretApiModule(context.Configuration));

                        builder.RegisterType<ConsoleAppRunner>().AsSelf();
                    })
                    .Build();

            // Create a scope and run the application
            using var scope = host.Services.CreateScope();
            var app = scope.ServiceProvider
                .GetRequiredService<ConsoleAppRunner>();
            await app.RunAsync();
        }
    }
}

ConsoleAppRunner

Probably, it is the most interesting part of the first draft. Inside this class, we'll actually run our model — providing a system message, simulating user input, and observing the AI’s response through the ChatService.

FatAdvisor.Console/ConsoleAppRunner.cs:

using Microsoft.SemanticKernel;
using Microsoft.SemanticKernel.ChatCompletion;
using Microsoft.SemanticKernel.Connectors.OpenAI;

namespace FatAdvisor.Console
{
    public class ConsoleAppRunner
    {
        private readonly Kernel _kernel;

        // Injection is controled by Autofac
        public ConsoleAppRunner(Kernel kernel) 
        {
            _kernel = kernel;
        }

        public async Task RunAsync()
        {
            var chatHistory = new ChatHistory();
            chatHistory.AddSystemMessage(
                "You are a nutrition and training assistant. " +
                "Although you don’t have access to any external data, " +
                "pretend that you’re analyzing the user’s recent food " +
                "and training habits based on their description. " +
                "Provide practical, personalized advice."
            );

            var userMessage =
                "Imagine I’ve been eating quite a lot of carbs " +
                "recently and training hard at the gym. " +
                "Please evaluate how that could affect my weight " +
                "and energy levels, and suggest what I could adjust.";

            chatHistory.AddUserMessage(userMessage);

            var chatCompletion = _kernel
                .GetRequiredService<IChatCompletionService>();

            var settings = new OpenAIPromptExecutionSettings()
            {
                FunctionChoiceBehavior = FunctionChoiceBehavior.Auto(),
            };

            var response = await chatCompletion
                .GetChatMessageContentAsync(chatHistory, settings, _kernel);

            System.Console.WriteLine(response.Content);

            foreach (var kvp in response.Metadata)
                System.Console.WriteLine($"{kvp.Key}: {kvp.Value}");
        }
    }
}

In RunAsync(), we:

Create a chat history:
It contains both a system message (instructions for the assistant’s role and behavior) and a user message (the question or request). Together, they define the full context the model receives.
Resolve the chat completion service
From the instance of Kernel, we receive an implementation of IChatCompletionService. Since we registered OpenAIChatCompletionService in the FatSecretAiModule, this interface is automatically resolved to that implementation.
Configure prompt execution behavior
In the prompt execution settings we register only one setting, but pretty important one:
```
var settings = new OpenAIPromptExecutionSettings()
{
    FunctionChoiceBehavior = FunctionChoiceBehavior.Auto(),
};
```
What does it mean? We discussed the concept of AI agents in the beginning of this article. And though we haven't created an agentic plugin yet, we can already instruct the model how to behave when plugins are presented.

The available options are:
- None – well, our agent won't call any functions but may describe which one it would call (good for testing purposes and for research).
- Auto – the model decides on its own whether to call a function and how to use it.
- Required – with this option we could actually force the agent to call some functions.
In this exercise we prefer to use Auto mode, we will let our model shine and choose its own way to use available functions.

Print the results
Finally, we output both the model’s text response:

foreach (var kvp in response.Metadata)
    System.Console.WriteLine($"{kvp.Key}: {kvp.Value}");

Running

For storing tokens and other sensitive settings, we'll use User Secretsinstead of embedding them into appsettings.json or environment files. From your terminal navigate to the FatAdvisor.Console folder and run the following commands:

dotnet user-secrets init
dotnet user-secrets set "GitHubModels:ApiKey" "<your GitHub models token>"
dotnet user-secrets set "GitHubModels:Endpoint" "https://models.inference.ai.azure.com"

Now run the console app. Because we set up a pretty verbose log level, we will see some technical information along with the response by AI model:

dbug: Microsoft.SemanticKernel.Connectors.OpenAI.OpenAIChatCompletionService[0]

      Function choice behavior configuration: Choice:auto, AutoInvoke:True, AllowConcurrentInvocation:False, AllowParallelCalls:(null) Functions:None (Function calling is disabled)

info: Microsoft.SemanticKernel.Connectors.OpenAI.OpenAIChatCompletionService[0]

      Prompt tokens: 114. Completion tokens: 485. Total tokens: 599.

When you've been consuming a lot of carbohydrates and training hard at the gym, several factors come into play regarding your weight and energy levels:



### Effects on Weight:

1. **Glycogen Storage**: Carbohydrates are stored in your muscles and liver as glycogen. For every gram of glycogen, about 3 grams of water are stored as well. This can cause temporary weight gain as your body increases its glycogen stores.

...

Ok, I think there's no need to copy here the whole answer. We still don't provide any personal information from FatSecret, so the AI output here is mostly a general nutrition explanation.

Let’s highlight a couple of interesting details from the log:

Function choice behavior configuration: 
    Choice:auto,
    AutoInvoke:True,
    AllowConcurrentInvocation:False,
    AllowParallelCalls:(null)
    Functions:None (Function calling is disabled)

Here we can see that function calling is configured for “Auto” mode, but no functions are actually registered yet — which is expected at this stage of the project.

And here:

Prompt tokens: 114. Completion tokens: 485. Total tokens: 599.

we see that we sent 114 input tokens to the model, and received 485 in response (with 599 being a sum of input and output). Tracking these stats will help us later to optimize costs and usage when we integrate more complex prompts or larger models.

Conclusions

I'd like to stop here not to overload our journey by throwing too much information at once. We have created something that we now can improve and develop. Our system already has some basic structure and AI features.

In the next chapters we will:

create a plugin for SemanticKernel containing functions that will allow our AI agent to access food and weight logs,
implement API integration with FatSecret to retrieve this data — including building an HTTP client, handling authentication, and adding a simple local token storage,
improve the prompts to make our FatAdvisor smarter and more helpful.

Thanks for reading — and see you in the next part!

gosli: a little attempt to bring a bit of LINQ to Golang

Dmitry Bogomolov — Fri, 17 Apr 2020 21:02:05 +0000

This post was originally posted on Medium: https://medium.com/@dmitrybogomolov/gosli-a-little-attempt-to-bring-a-bit-of-linq-to-golang-1e3fb4acfd04

First, let me admit that I really like Golang. I think it’s pretty elegant, easy-to-read and very powerful language. But also, I love C#.

Though I know that every language has its’ best practices and has its’ own way to create good software, there’s something from C# that I definitely miss in Golang. One of those things is LINQ (Language-Integrated Query).

LINQ allows us to manipulate with collections in C#, modifying, filtering, grouping them using anonymous (lambda) functions. Let’s see a little example how it looks:

The problem

One of the biggest inconveniences I met in Go was the fact that the language doesn’t have some standard way to filter a slice or to find an element of slice by one of its’ fields. I tried to find some way to do it, but everything I found was something like “Well, you have to write a loop for it”.

Once upon a time, I found myself having multiple loops in my program, and they were almost the same but working with different types. It was something like that.

It made me think that it should be the way to avoid code copying. One approach is to make common method receiving interface{}.

And there are at least a couple of problems I see in this implementation.
First, a lot of type assertions are there (like x.(B).FieldString… etc.). It doesn’t look very nice and it makes us create a lot of code to check if assertion can be made.

Also, it makes us use the reflect package. A lot of Go apps are made to be fast, I mean, really fast. And you could hear it here and there that reflect is not a great helper if you’re looking for good performance.

And another disadvantage is the underlying type returned by our filter method. Let’s check it with fmt.Printf(“%T”, filteredA) and it will return us: []interface {}. If we want to use this object it wouldn’t be to cool to do. We will need to iterate over it to convert every element’s type to A.

So, all these problems made me think that we shouldn’t make a pseudo-generic method for all the types. But writing a separated loop for every type (as we did in the first code example) doesn’t look too good as well.

I supposed that making a code generator to create some general methods that won’t use the reflect package inside of those methods could make a deal. That’s how we can avoid copying-and-pasting code all the time and also we could have nice and clear methods that receives and returns particular types instead of annoying interface{}.

Introducing gosli

These thoughts lead me to make a lib I called gosli. I didn’t really plan to make a big deal out of it, I just wrote some code that, I guess, could be useful for someone else.

TL;DR: check the source code and examples of usage here
https://github.com/doctornick42/gosli

Ok, let’s start. To get it we need to run this command:
go get github.com/doctornick42/gosli

Let’s create a new project with such a structure:

testtypes.go will contain our types from the previous examples:

After it, we should run this for Linux

$GOPATH/bin/gosli types/testtypes.go A

or this for Windows:

%GOPATH%\bin\gosli.exe types\testtypes.go A

As you can see, our types folder has been extended by adding 3 new files:

The only file of them we need to modify manually is a_equal.go, which is needed for gosli to understand how it can check if two instances of A are equal. From the scratch the code of this file looks like:

Let’s append after the //equalmethod has to be implemented manually comment a new line:

return r.FieldInt == another.FieldInt

That’s it. Now we can make some code to test the result, let’s just use the code we used in a previous example and put it in our main.go file:

And if we run the program we will see this output: [{“FieldInt”:1},{“FieldInt”:3}] which is correct.

The full code of this example is here.

Features of gosli

The library has 2 main approaches:

to provide methods for slice of custom types. This part uses code generation, it has been briefly described in the previous paragraph. The documentation showing all the methods and other details could be found here;
gosli also has all these methods for basic Golang types out-of-the box, it’s described here.

Also, every method of -Slice types returns such a type too, so the methods could be combined in a chain like this:

result, err := SomeTypeSlice(original).
    Where(filter1).
    Where(filter2).
    Page(1, 2)

So, thank you for reading. If you would like to check out gosli, feel free to ask me about it or create issues in the repository.

In the experiment folder there are some tests, benchmarks and examples, that I hope will help to understand how to use the library in your apps.

Also, you can find more awesome gopher images (like one I used in this article) by Egon Elbre under the CC0 license here https://github.com/egonelbre/gophers

DEV Community: Dmitry Bogomolov

Building FatAdvisor: A .NET Nutrition AI Agent. Part 2: Agent goes outside

Table of Contents

In the previous episodes...

Plugins

Coding

Interfaces and Stubs

Plugin implementation

DI

Running!

Conclusions

[Boost]

Building FatAdvisor: A .NET Nutrition AI Agent. Part 1: Building the Foundation

Dmitry Bogomolov ・ Oct 15

Building FatAdvisor: A .NET Nutrition AI Agent. Part 1: Building the Foundation

Table of Contents

Intro

AI agents

The project

It goes technical

Choosing the technologies

Solution structure

AI model

Starting coding!

Dependency Injection (DI)

Program.cs

ConsoleAppRunner

Running

Conclusions

gosli: a little attempt to bring a bit of LINQ to Golang

The problem

Introducing gosli

Features of gosli