I love coding my own stuff, and my clients typically have lots of internal specifications and libraries to use.
But since LLMs haven't been traine...
For further actions, you may consider blocking this person and/or reporting abuse
Giving agents knowledge they were never trained on is the whole game for real-world usefulness, because the training cutoff and the absence of your private/proprietary data are the two biggest gaps between a clever general model and something useful in your actual business. Retrieval is the right lever, and the framing I'd stress is that you're not teaching the model, you're feeding it: the knowledge lives in an external, updatable store and you surface the relevant slice at inference time, which is why RAG beats fine-tuning for facts that change (you update the source, not the weights). Two things decide whether this works: retrieval quality (the model can only use what you actually fetch, so chunking and ranking are the ceiling) and grounding discipline (prefer the retrieved knowledge over the model's priors, and abstain when the docs don't cover it, rather than blending in a confident guess). The nice property is freshness, your agent's knowledge is as current as your store, no retraining required. Feed it the right external knowledge at query time, ground answers in it, and keep the source updatable. That retrieve-don't-retrain-for-changing-knowledge instinct is core to how I think about Moonshift. For the knowledge it was never trained on, are you leaning on RAG retrieval, or also doing any lightweight fine-tuning for the domain style?
The key is separating knowledge from authority. Giving an agent private docs or current state is useful, but it should know where that knowledge came from, how fresh it is, and whether it is allowed to act on it. Otherwise retrieval turns into another source of confident stale answers.
Since you control which sources you give it, you most likely know how stale they are. It's a simple config
Agreed—the config can be simple. The part worth making explicit is that freshness is a property of each source, not of the agent: a page can change outside a deploy. I like storing the retrieval time/version with the source so the agent can surface uncertainty instead of quietly treating old context as current.
fair point. I'll see what I can do.
v1.2.0 checks freshness
That is a useful freshness contract. I’d make the check observable too: record the source revision and validation timestamp next to the memory, so an agent can explain why v1.2.0 is still trusted—or why it was rejected.
This is a practical MCP use case because it solves a real developer pain: agents guessing APIs they were never trained on. I like the scoped-docs approach, especially the ability to expose TypeDoc JSON and schemas without giving the agent the whole repo. A useful next layer could be tracing which docs/tools the agent consulted before producing code, so teams can debug bad generations more easily. That is close to what I’m exploring with agent-inspect for TypeScript agent execution inspection.
I got a MCP server for typescript too, including code quality inspection to find the next mess to fix ;) I'll write about it next. github.com/jgauffin/ts-language-mcp
Your benchmarks are making my laptop feel personally attacked 😂 Did you consider any alternatives before settling on this?
Great stuff — followed for more! 👍
Which benchmarks are you referring to? I have a 5090 so I can play with local models 😁
Hahaha, I actually waited three months for this reply! My laptop has a 4070S GPU, I’m genuinely jealous of yours.🤣