How I Tamed ServiceNow Custom AI Skills and Fixed the Limitations of Now Assist.
When I first started building custom generative AI experiences using the Now Assist Skill Kit, I expected a smooth ride. The platform promises beautiful visual tools to connect your enterprise data to large language models. However, when you actually start deploying these skills in a real environment with complex data and strict security requirements, you quickly hit a wall.
During my implementation journey, I ran into major frustrations with the native AI Retriever tool and the way the platform cuts up text data. I had to ditch the standard setup guidelines and find practical ways to make the system work accurately and safely. This is my experience on how I overcame these platform boundaries and what actually works in practice.
The Nightmare of Static AI Retrievers
My first big roadblock was the visual AI Retriever tool. This component is designed to let the AI search through your tables to find relevant information for the user. The major issue is that this tool only supports static filters. You cannot set up a dynamic condition that checks who the logged in user is at that exact moment, or what category is selected on the active ticket. The filter is completely locked in when you publish the skill.
This creates a massive compliance risk in a real enterprise. If a user asks a question, a static retriever might pull information from a restricted document that the user should not be allowed to see. In other cases, the AI gets confused because it retrieves data belonging to a completely different department, leading to incorrect answers.
To fix this, I stopped using the visual AI Retriever tool altogether for sensitive use cases. Instead, I used a standard Script Tool within the Skill Kit. By shifting the data gathering to a traditional ServiceNow script, I regained complete control. The script dynamically checks the user department and ticket fields, queries the database securely, and glues the text of the matching records together. This text block is then passed straight into the prompt. You do lose the advanced semantic search of the vector database this way, but you get perfect data security and pinpoint accuracy in return.
Solving the HTML Chunking Mess
My second major frustration was chunking, which is the process where ServiceNow automatically cuts long documents into smaller pieces for the AI search index. ServiceNow applies this to rich text HTML fields, which is how most knowledge articles are saved. If your articles contain formatting or data tables, the automatic chunking process will ruin them. The system blindly cuts the text in the middle of a table, separating column headers from their values. The AI then completely loses the context.
I solved this by creating a hidden, plain text field on the knowledge table. I set up a background process that triggers whenever an article is created or modified. This process takes the messy HTML layout and converts it into a clean, structured markdown format.
Instead of pointing the AI search engine to the standard HTML body, I configured it to index only this clean, hidden field. Because the text structure remains intact without the heavy HTML code, the AI cuts the pieces much more logically. This single change made the final answers generated by the AI significantly more accurate.
Keeping the Model in Check with Strict Prompts
The final lesson I learned is that the AI models inside ServiceNow need very tight boundaries. In my early attempts, I mixed user data, system rules, and the retrieved text all together in the prompt editor. The model frequently lost track of its instructions and started making things up when it could not find an immediate answer.
I fixed this by changing the way I write the prompt layout. I now separate the information using clear headers and keep the structure incredibly strict in md format. I put the main rules at the absolute top in capital letters, explicitly telling the AI that it must only use the provided text and that it is forbidden to guess. I place the dynamic text block from my script right below those rules, and I leave the actual question from the user at the very bottom. This clean separation stopped the AI from hallucinating and gave me the reliable results I needed.
By stepping away from the default visual setup and spending time cleaning up the data structure beforehand, you can successfully build custom AI skills that are both safe and highly effective.
E.g.
E.g.
## SYSTEM RULE
YOU ARE A SECURE CORPORATE ASSISTANT. YOU MUST RESOLVE THE USER REQUEST USING ONLY THE DATA PROVIDED WITHIN THE GROUNDING CONTEXT SECTION BELOW. IF THE PROVIDED TEXT DOES NOT CONTAIN THE ANSWER, YOU MUST REPLY EXACTLY WITH THE FOLLOWING PHRASE: I am unable to locate the solution in corporate documentation. YOU ARE STRICTLY FORBIDDEN FROM GUESSING, MAKING THINGS UP, OR EXTRAPOLATING ACCORDING TO DATA OUTSIDE OF THE PROVIDED TEXT.
YOU ARE A SECURE CORPORATE ASSISTANT. YOU MUST RESOLVE THE USER REQUEST USING ONLY THE DATA PROVIDED WITHIN THE GROUNDING CONTEXT SECTION BELOW. IF THE PROVIDED TEXT DOES NOT CONTAIN THE ANSWER, YOU MUST REPLY EXACTLY WITH THE FOLLOWING PHRASE: I am unable to locate the solution in corporate documentation. YOU ARE STRICTLY FORBIDDEN FROM GUESSING, MAKING THINGS UP, OR EXTRAPOLATING ACCORDING TO DATA OUTSIDE OF THE PROVIDED TEXT.
## GROUNDING CONTEX
{dynamic_grounding_text}
{dynamic_grounding_text}
## REQUEST
{user_query}
{user_query}
