Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/cognigy/cognigy-plugin/knowledge-setupnpx skills add Cognigy/cognigy-plugin --skill knowledge-setupgit clone --depth 1 https://github.com/Cognigy/cognigy-pluginWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00049 | $0.01950 |
| Opus 5 | $0.00024 | $0.00975 |
| Sonnet 5 | $0.00010 | $0.00390 |
| Haiku 4.5 | $0.00005 | $0.00195 |
Grade A, and why
knowledge-setup scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 3d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 98 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Adding Knowledge to an Agent
Prerequisites
- An embedding model must be configured in the project before creating knowledge stores.
Use
setup_llmto create one first if the target project does not already have one (e.g.,setup_llm { projectId, provider: "openAI", modelType: "<embedding model type>", apiKey }). To check:list_resources { resourceType: "llm_model", projectId }and inspectmodelType. Use provider docs or an existing same-project model to identify the correct embedding-capable model type for the store index. - Configure the project's Knowledge AI Settings before creating the store in normal AI-agent knowledge flows.
Use
manage_settings { operation: "set_knowledge_ai", projectId, knowledgeSearchModelId: "<llm referenceId>" }. If you use the Azure content parser, also setcontentParser: "azure"andazureDIConnectionId.
Important Distinction
- The embedding model is for the knowledge store index itself.
knowledgeSearchModelIdis a separate project setting for Knowledge Search and must reference anllm_modelfrom the same project.- For normal AI-agent knowledge-store setups,
answerExtractionModelIdis usually not needed. - The model you pick for the AI Agent itself is a separate decision. The agent response model should not be reused for
knowledgeSearchModelIdjust because it is already available. - The accepted model type for
knowledgeSearchModelIdis instance-dependent. Start with existing same-project candidates and rely on the API response. - Model names shown in examples are not a whitelist for either role.
Steps
- list_resources { resourceType: "llm_model", projectId }
- For Knowledge Search, prefer
list_resources { resourceType: "llm_model", projectId, useCase: "knowledgeSearch" }so the candidates match the Settings UI dropdown - Refresh this after any package import
- Start with the source project's exact Knowledge Search model when reusing an existing setup
- Import the full required source-project model set before the first
manage_settings { operation: "set_knowledge_ai", ... }attempt - If multiple required models share one connection, import that connection once alongside all of those models
- For Knowledge Search, prefer
- manage_settings { operation: "set_knowledge_ai", projectId, knowledgeSearchModelId, contentParser }
- Do this before
manage_knowledge { operation: "create_store", ... }in normal AI-agent knowledge flows
- Do this before
- manage_knowledge { operation: "create_store", projectId, name }
- manage_knowledge { operation: "create_source", knowledgeStoreId, type, ... }
- type: "url" — scrape a web page. Provide
url. - type: "manual" — store text directly. Provide
text. - type: "file" — upload a local document. Provide
filePath(absolute path, e.g. "/Users/me/docs/report.pdf"). - IMPORTANT: URL and file ingestion is async. Content is NOT searchable immediately.
- Wait 10-60 seconds before searching.
- type: "url" — scrape a web page. Provide
- manage_knowledge { operation: "list_chunks", knowledgeStoreId }
- Verify content was ingested correctly
- If no results right after create_source, wait and retry
- Attach to agent as a TOOL (default approach):
- During agent creation — create_ai_agent { projectId, name, knowledgeStoreReferenceId: storeReferenceId } This automatically creates a knowledge search tool on the agent's Job Node.
- After agent creation — create_tool { aiAgentId, toolType: "knowledge", name: "Search KB", config: { knowledgeStoreId: storeReferenceId, toolId: "search_kb", description: "Search the knowledge base" } } This creates a dedicated search tool the agent can invoke to query the knowledge store.
- IMPORTANT: Always use the tool-based approach unless the user explicitly asks to attach knowledge to the agent persona.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 3d ago First seen · 98 lines · 49 tokens per session scan A 58ef59e1e269
knowledge-setup is a skill published in the GitHub repository Cognigy/cognigy-plugin (8 stars, last pushed 5d ago), licensed MIT. It adds 49 tokens to every session and 1,950 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
9router-embeddings
Generate vector embeddings via 9Router /v1/embeddings using OpenAI / Gemini / Mistral / Voyage / Nvidia / GitHub embedding models for RAG, semantic search, similarity. Use when the user wants embeddings, vectors, RAG, semantic search, or to embed text.
potpie-source-ingestion
Use when the user explicitly asks to ingest, refresh, or deeply understand a repository, PR, issue, ticket, runbook, incident report, document, or web link into Potpie. The harness performs todo-driven discovery, uses local/GitHub/integration tools and read-only subagents when available, builds evidence-backed…
embedding-strategies
Select and optimize embedding models for semantic search and RAG applications. Use when choosing embedding models, implementing chunking strategies, or optimizing embedding quality for specific domains.
generate-rag-dataset
Generate a synthetic evaluation dataset from your RAG knowledge base. Creates diverse Q&A pairs with expected answers and relevant context, ready for LangWatch experiments and platform import. Use when you need test data for your RAG pipeline.
embeddings
Vector embeddings configuration and semantic search.
session-rag-eval
Run and debug Chatbox session attachment RAG model evaluation with synthetic and real long-file fixtures.