Skip to content

Tech Stack Assesment

Jump to bottom
Sujay Singh edited this page Oct 27, 2026 · 2 revisions

  1. Audience and ask. Who is in the room, CIO, security leadership, or both? Are you asking for a mandate, budget, headcount, or all three? A: I would be used by everyone. Basically the idea is have robust, reliable, continuous documentation which then can be pointed to approved AI agent for easy retrieval. User with Admin access to agent ( or may be with periodic review for articles) will get pop to mark KB approved, retired, needs review based on KB creation and edited date.

  2. Plan and licenses. Which Freshservice plan, and which Freddy pieces are live today: Copilot, AI Agent, Insights? Is the M365 Copilot connector for Freshservice already enabled? We have High tier subscript with more budget line to but extra features. It’s already enabled for Copilot, I have API access to Freshservcie to scrape KBs. I also think if it requires RAG/Topic for easy retrieval - I can index KB data in AWS RedShift with continuous update and then point that RedShift table through Custom MCP to Agents would be sound workflow. Becuase of storage, we can also correct, iterate, SME approve this articles/KBs.

  3. KB state. Rough article count, who owns them, is approval workflow on, and what does usage look like? Any existing deflection or helpfulness numbers? A: will be owned by SMEs and Project Owners

  4. Doc classes in scope. End user how to, agent resolution articles, ops runbooks, remediation guides, architecture and design records? My recommendation is the first four in the KB, design records stay in git. Agree? My main goal is MVP where I can leverage Freshservice KB, auto generation, upload/auto update new approved KBs, automate auto update/approval etc.

  5. Where docs live today. Confluence, SharePoint, git, Teams wiki, Word? Which of those must survive, and which can become read only mirrors? A:

  6. The vuln agent. Is it a Copilot Studio agent? Can its notification carry links today? Does it read Fabric only, or also Freshservice? Yes it’s a copilot agent, reads from RedShift table over MCP for bulbs data. Yes it can carry links. It doesn’t have to be the same agent. I shared that for your context. I was thinking of deploying a a subagent just for KB

  7. Owner. Is there a candidate team or person to run the service? Any appetite for a technical writer, even fractional? A: If the architecture is sound and seamless, I don’t think in Today’s time maintenance is a big deal . We have high subscription Cursor access, unlimited Github copilot license - so maintaining a code base, workflow shouldn’t be that difficult.

  8. Policy levers. Are you willing to propose that every problem record closure produces a known error article, and every change record links a runbook? Those two rules drive adoption more than any tool. A: I am not sure, my goal is to implement like a Freshservice golden asset record vSphere sync which worked for other collector development as well because of reconciliation engine. I am thinking of something similar. May be one aggregator that gets feedback, can do periodic scarping, maintain timely, relevancy etc. and then go from there Just brainstorming, feel free to rebut.

  9. Security content. Does the security team co own remediation articles, and who approves what requesters can see? A: I think it should be irrelevant because once the product is ready, we can build the narrative, define ownership etc.

  10. Metrics you already report. QuickSight and Fabric dashboards exist. Should KB health metrics land there, or inside Freddy Insights? A: If possible, why not. I would prefer either QuickSight or Grafana.

  11. Timeline. Is this a 90 day pilot pitch or a 12 month program pitch? The slide count you asked for says pilot. Confirm. A: Yes it’s a pilot/MVP pitch with seamless potential to integrate any system. I am being industrious here

Checked Freshservice docs and prior context. Here is my honest take, then the questions I need answered before I build anything.

Assessment

The idea is sound. The name is the risk. "Documentation as a service" is an operating model: ownership, lifecycle, review gates, metrics. Freddy is a drafting accelerator inside that model. If the pitch lands as "AI writes our docs", you will have a KB full of duplicate half right drafts in six months and leadership asking why deflection did not move.

What Freddy actually does today. The Help Article Generator creates draft knowledge articles from ticket context, and it generates solution articles from public sources and existing tickets to deflect commonly occurring issues. Drafts, not published articles. The review gate is yours to build.

Why the business case is stronger than it looks. Every Freddy feature reads from the KB. Reply suggester responses are sourced from help articles maintained in your knowledge base, and for the employee facing AI Agent, response quality depends heavily on the quality and completeness of your knowledge base. So KB quality is the ceiling on every AI dollar you spend in Freshservice. That is the pitch, not "better docs".

The org wide hook exists. Microsoft 365 Copilot can connect to Freshservice through a Copilot Connector to access IT service documentation, GA December 2025. It indexes solution articles for Microsoft Search and M365 Copilot. That means your vuln notification agent can carry a remediation article link in the same message that tells a user their asset has a finding. Detect, notify, remediate, close, one loop, one corpus. That is the demo that sells this.

Where it breaks, in order of likelihood:

  1. No review gate. Tickets contain wrong steps, workarounds, PII, sometimes credentials. Freddy drafts from them. Approval workflow with a named reviewer per category is mandatory, day one.
  2. Two sources of truth. Your engineering docs live in git and markdown (the handoff files, runbooks, AAP job template descriptions). Engineers will not author in a KB editor. You need a system of record per doc class, with one way push from git into the KB through the Solutions API for runbooks. Otherwise the KB drifts from reality within a quarter.
  3. Staleness at AI scale. A stale article used to mislead one agent. Served by Freddy and M365 Copilot it misleads everyone, confidently. Review dates, owners, expiry, and a freshness metric are not optional.
  4. No baseline. Leadership wants a delta. You need today's numbers: article count, articles touched in the last 180 days, ticket to article link rate, deflection, MTTR for linked vs unlinked tickets. Without a baseline the service cannot prove anything.
  5. Licensing. Copilot is an add on for Pro and Enterprise plans, at 29 dollars per agent per month billed annually, and the AI Agent is Enterprise only with 1200 sessions per year per license. If you do not already hold these, the pitch becomes a budget ask, which is a different slide.
  6. Ownership. "As a service" means someone runs it. If the answer is "everyone", it is no one.
  7. Security scoping. Remediation articles for vulns must not expose exploitability detail to requesters. KB visibility by group has to be designed, not defaulted.

Questions

  1. Audience and ask. Who is in the room, CIO, security leadership, or both? Are you asking for a mandate, budget, headcount, or all three?
  2. Plan and licenses. Which Freshservice plan, and which Freddy pieces are live today: Copilot, AI Agent, Insights? Is the M365 Copilot connector for Freshservice already enabled?
  3. KB state. Rough article count, who owns them, is approval workflow on, and what does usage look like? Any existing deflection or helpfulness numbers?
  4. Doc classes in scope. End user how to, agent resolution articles, ops runbooks, remediation guides, architecture and design records? My recommendation is the first four in the KB, design records stay in git. Agree?
  5. Where docs live today. Confluence, SharePoint, git, Teams wiki, Word? Which of those must survive, and which can become read only mirrors?
  6. The vuln agent. Is it a Copilot Studio agent? Can its notification carry links today? Does it read Fabric only, or also Freshservice?
  7. Owner. Is there a candidate team or person to run the service? Any appetite for a technical writer, even fractional?
  8. Policy levers. Are you willing to propose that every problem record closure produces a known error article, and every change record links a runbook? Those two rules drive adoption more than any tool.
  9. Security content. Does the security team co own remediation articles, and who approves what requesters can see?
  10. Metrics you already report. QuickSight and Fabric dashboards exist. Should KB health metrics land there, or inside Freddy Insights?
  11. Timeline. Is this a 90 day pilot pitch or a 12 month program pitch? The slide count you asked for says pilot. Confirm.

Answer what you can. Gaps I will mark as assumptions on the slide so leadership sees them.

Sources:

Clone this wiki locally