Hi guys,
When using the Forge Teamwork Graph connector module to ingest external PDF content as atlassian:document objects, can a Rovo Agent be scoped to use only the objects from that specific connector as its knowledge source?
Our use case requires a strict knowledge boundary: the agent must answer only from approved documentation and must not mix in other Atlassian or external sources.
We are exploring Teamwork Graph ingestion as a way to avoid current PDF size limitations in Rovo (Google Drive) connectors. Today we prototype this by extracting PDFs into Confluence pages and scoping the agent to a specific page/space, which works, but may not be the most scalable production approach.
Is Teamwork Graph currently suitable for this kind of scoped Rovo knowledge use case, or would we still need a custom Rovo action/search index to enforce the source boundary?
@MartinFischer,
Maybe?
At this time, the Studio capabilities do not yet provide fine-grained TWG query controls that would specify a knowledge source by source & media type (eg PDF). We do know this exists in the TWG, because we can see filters by sources (aka connectors) and type in Rovo Search. Only “by source” is exposed in Studio right now.
Meanwhile, Forge does not have anything specific as a “knowledge source”. One must write a “GET Action” as a Forge function to gather context. There’s not yet a production way to query the TWG or to leverage Rovo Search. The most I have been able to accomplish is create GET Actions that approximate those behaviors by querying remote APIs (more like a “federated” connector than a TWG native one).
For now, I think your Confluence extraction seems like a pretty good solution, as long as the content is slow changing and constrained in size. We have plans for more/better with both Forge and Studio but I have nothing to which I can point as “watch this space”.
Thank you, this is very helpful.
If we simplify the use case to just source scoping - if we use a Forge Teamwork Graph connector, would a Rovo Agent’s knowledge be strictly scoped to that connector as its source (so it only uses that data and nothing else)?
@MartinFischer,
Yes, but with some caveats:
- Users can still add their own context explicitly. Like writing questions and comments, or pasting in a PDF to chat. I don’t know of any LLM chat tool that doesn’t have that caveat.
- Actions may bring in context too. While most Actions are actions (like create a page or workitem), others are themselves mini-knowledge-sources. For example, I have written quite a few Actions where the sole job is a bit of “context engineering” to navigate the Jira REST APIs in a very specific way and bring the information back as Markdown.
Hope that still fits your constraints.
