Meeting with Steve. We spent some time talking about the mini private AI agent. We logged into the Nxtlinq backend and were looking at their context window. Josh jumped on for a little bit. Steve and I were making plans and talking about things. Where do we want to go and how are we going to get there?

We talked about some global context pieces and what we are hoping for. We would love the AI agent to help us with some videos, running comparisons, drawing (whiteboards what to do).

Steve has a couple of other projects going on right now. We flipped over to them and went through them for a bit. We talked about three other projects and went over some questions that he has. One of the projects is that Steve had questions about the Grok AI as an AI agent. We talked about getting new session variables on the login, logout, change corp, 3rd party solutions, footers, and sdk's files or pages.

Next, we flipped over to a small project that is dealing with ecommerce and part category settings. Currently, we have a setting that allows for a corporation or entity to select a sales mode. These are inventory level controls like show and sell parent inventory, show parents and sell subs, show sub and sell subs, etc. All of these are dealing with parent/child relationships within the inventory itself. Steve is working on a new setting that will allow that bigger master switch to be controlled on the part category level. Some categories tend more toward child or sub inventory than other ones. Anyways, he is working on changing out that master switch and making it more granular at the part/item category level.

The last project that he is working on is saving a custom report from inside the system. The new report has both normal FORM scope params as well as dynamic, on the fly params. We went over some options and did some comparing of the FORM scope values. It goes something like this... We use a normal web-based form to pull the report. At that point, we have all of the FORM scope values or variables. If the user wants to save the report, we send all of the data over to a save report page that putts all of that information into a JSON object for database storage. We then take the new database id number and use it as a URL scope variable. Basically, run report X based on the settings stored by id number Y. It works pretty slick. We have done this for years and years. This particular one has some other random dynamic that are making it a little bit more difficult. We are not sure, but it seems to be a case sensitive problem with what is being created (dynamic FORM values) and what is being saved in JSON format. We didn't quite finish this, but were getting close.