A useful AI knowledge assistant must do more than find a convincing paragraph: it must find information the employee is allowed to see. Glean documents permission-aware answers, Onyx explicitly places source-permission synchronization in its Enterprise offering, and Dust separates agent data access from permission to use the agent.[1][3][6]
For a builder, the commercial opportunity is not another unrestricted “chat with company documents” demo. My recommended starting point is a paid, narrow internal-knowledge deployment with access tests, source ownership and measurable answer quality. This guide compares three relevant platforms and proposes a service blueprint, not a ranking of proven profitability.
Sources checked October 23, 2026. Product capabilities below are vendor-documented, not independently benchmarked. Proposed offers, time estimates and economics are editorial examples, not vendor prices or revenue claims.
Why this AI project category matters now
Dust's October 1, 2026 article describes collaborative AI as shared work involving people and agents, with governed context, review points and accountable handoffs.[5] Glean's current administration documentation also exposes a practical governance distinction: hiding premium models from a picker is not the same as blocking their use throughout the system.[2]
My interpretation: an implementation business can sell the operational work around these products—access design, evaluation and maintenance—rather than competing to build a general-purpose model. For this article, the target buyer is an IT or operations team that repeatedly searches internal runbooks and procedures. The first deliverable should be an evidence-backed answer with a source link, not an autonomous infrastructure change.
1. Glean: enterprise knowledge with configurable model access
What it does. Glean Assistant answers questions using organizational information and user access permissions; its setup guide also covers document summaries and Slack or Microsoft Teams entry points.[1]
Model evidence. The guide names GPT, Claude and Gemini model families and describes provider access through services such as AWS Bedrock and Google Cloud Vertex AI.[1] That confirms documented options—not the exact model processing a particular customer's question. Record the selected model and provider during the pilot rather than inferring them from branding.
Commercial angle: proposed service. For a customer already buying Glean, offer a bounded rollout: connect the agreed knowledge sources, establish document ownership, assemble a role-specific question set and train the pilot group. Keep software procurement separate from your implementation fee.
Limits to test. Glean says initial connector crawling and machine-learning workflows must finish before Assistant can respond correctly.[1] Its documentation also warns that custom instructions change response generation rather than retrieval, so a prompt saying “do not reveal confidential information” is not a substitute for access controls.[1]
A second useful acceptance check concerns models: Glean documents separate exclusion controls and notes that hiding premium models in pickers does not necessarily prevent automatic routing to them.[2] Test the intended policy, not merely the appearance of the user interface.
2. Onyx: indexed internal search, with an edition boundary to check
What it does. Onyx describes background indexing, hybrid keyword-and-semantic retrieval, and cloud or self-hosted deployment.[3] Its connector documentation says connectors synchronize external information and metadata so answers can be grounded in company knowledge.[4]
Model evidence. The connector documentation discusses optional LLM or third-party processing during indexing, but does not establish a single universal answer-generation model.[4] No specific generation model is attributed to Onyx here. For a proposed installation, choose and document the provider, model and indexing configuration explicitly.
Commercial angle: proposed service. Package a managed internal-search pilot for an engineering team with a clearly bounded document collection. Sell connector operation, evaluation, upgrades and incident handling—not a promise that self-hosting removes every possible external dependency.
Important limit. Both the connector page and documentation identify source-permission synchronization or respect for user permissions as an Enterprise feature.[3][4] Do not assume that a freely deployed edition automatically inherits all upstream access controls.
For a shared demonstration, use an authorized, uniformly accessible corpus. For mixed-permission production documents, verify the licensed feature set and actual connector behavior before ingestion. My recommendation is to make that decision a procurement gate, not a cleanup task after the demo.
3. Dust: reusable internal agents with human review
What it does. Dust presents shared agents connected to company systems, reusable skills and human review, with controls for tools, data and agent access.[6]
Model evidence. Dust publicly names OpenAI, Anthropic, Google and Mistral among its model providers.[6] This supports a multi-provider platform description; it does not prove which model a named customer's agent uses. Treat the chosen model and fallback behavior as deployment settings to verify.
Commercial angle: proposed service. Build a handover-preparation agent for an operations team. It would retrieve approved runbooks and relevant internal notes, prepare a source-linked briefing and flag missing information for a human owner. This is a proposed architecture, not a claim that Dust ships that exact workflow.
Limits to test. Dust describes a dual-layer permission system separating agent access to information from users' access to agents.[6] Validate both layers with representative accounts. Its collaborative-AI guide also discusses unreliable outputs, incomplete context and unclear accountability.[5] Keep review responsibility explicit, especially before an answer becomes an operational instruction.
Which project could realistically make money?
The cited technical and product pages do not disclose revenue or profit for the specific implementations proposed here. Project revenue: not public in the reviewed sources. That is not a claim that these vendors have never disclosed company-wide revenue elsewhere. There is no evidence here for calling any one platform the “most profitable.”
My commercial preference is a paid knowledge-access pilot followed by an optional maintenance contract. It gives the buyer a finite deliverable and gives the builder a way to discover support costs before promising a fixed recurring price.
| Proposed offer | Target buyer | Platform or tooling | Monetization proposal | Difficulty | Main risk to test |
|---|---|---|---|---|---|
| Runbook answer pilot | IT operations team | Glean with approved model configuration | Fixed-scope implementation | Medium | Incorrect access or stale procedures |
| Managed engineering search | Engineering team | Onyx with verified edition and model setup | Setup plus ongoing operations | High | Permission-sync assumptions and maintenance burden |
| Shift-handover drafting | Operations manager | Dust with selected provider and reviewer | Workflow build plus maintenance | Medium | Unsupported summaries and unclear ownership |
| Cross-role acceptance testing | Existing AI deployment owner | Test accounts, question set and audit evidence | Fixed assessment or periodic retest | Medium | Treating a passing sample as proof of total security |
The table is an editorial offer design and risk assessment, not a vendor feature comparison or measured demand forecast.
A practical builder stack: read-only before action-taking
The following is a proposed reference design, not a description of every vendor's internals:
Approved document sources + identity/group information
-> connector and indexing pipeline
-> authorization-aware retrieval
-> selected language model
-> source-linked answer or explicit abstention
-> human review and feedback
Add a separate evaluation store for test questions, permitted source IDs, expected exclusions, answer grades, timings and reviewer notes. Restrict that store as carefully as the documents because its outputs may contain sensitive information.
For the first pilot, I would choose one department, two sources and a small named test group. Budget two to four weeks as an initial planning assumption, conditional on working identity integration, approved contracts and available document owners. A deployment with unresolved source permissions should be re-scoped rather than squeezed into that estimate.
Do not give the prototype device credentials or write access to production systems. If action-taking is added later, design a separate approval and rollback process instead of treating a reliable search answer as authorization to execute it.
Reusable acceptance checklist
Use this as a starting test plan, not a security certification:
- Known answer: ask an owner-validated question; require the correct answer and the specific supporting document.
- Cross-role isolation: run the same question as two users with different access. Check the answer, snippets and citations for prohibited content.
- Revocation: remove access upstream, observe the synchronization interval, and record when results stop exposing the document. Agree the acceptable delay before rollout.
- Deletion and stale content: delete a test document and replace an obsolete runbook. Verify that the old text no longer drives answers after the agreed refresh window.
- Unanswerable question: require an explicit “not enough evidence” outcome rather than a fabricated procedure.
- Conflicting procedures: provide two inconsistent test documents. Require the conflict to be surfaced and routed to the owner.
- Hostile document text: include an instruction in a synthetic document that asks the assistant to disclose unrelated information. Confirm it does not override access or tool restrictions.
- Provider change: repeat the question set after changing the selected model; compare correctness, supported citations and cost.
- Connector outage: stop a test connector and check that stale data is not presented as newly verified information.
- Review workload: time corrections as well as successful answers. Include maintenance and exception handling in the business case.
Suggested pilot gates: no prohibited disclosures in the designed test set, owner-approved answers for the agreed critical questions, and documented behavior for missing or stale information. Passing these gates does not prove the absence of every vulnerability; it establishes a reproducible baseline for this deployment.
Illustrative service economics—not a profit claim
Assume a customer pays $1,500 per month for your management service, buys platform licenses separately, and your remaining monthly service costs are $250 plus 10 hours of labor at $60 per hour.
Monthly service contribution = fee - direct costs - delivery labor
= $1,500 - $250 - (10 × $60)
= $650
If delivery labor rises to 20 hours:
= $1,500 - $250 - (20 × $60)
= $50
These are invented planning inputs, not observed prices, wages or earnings. Contribution is before sales effort, tax, insurance, general overhead and initial build-cost recovery. Any platform or model fees you pay must also be included rather than silently excluded.
The decision rule I would use: do not offer a recurring fixed price until the pilot reveals the actual correction and maintenance workload. Track customer value separately—minutes saved are not automatically cash savings or an approved budget.
Bottom line
My recommended project is a narrow, read-only knowledge assistant whose access behavior and answer quality can be demonstrated to a buyer. Glean, Onyx and Dust offer different implementation paths; the source-supported distinctions above are more useful than guessing their hidden model stacks. The paid deliverable should be a tested workflow with accountable ownership, not a chatbot demo presented as a guaranteed profitable business.
Related reading
AI Customer Support Projects That Can Make Money: Fin, Zendesk and Sierra
AI Meeting Automation Projects That Can Make Money: Fireflies, Granola and Fathom
Sources
- [1] Configure Glean Assistant (accessed 2026-10-23)
- [2] Glean model controls (accessed 2026-10-23)
- [3] Onyx connectors and Enterprise permission sync (accessed 2026-10-23)
- [4] Onyx connector documentation (accessed 2026-10-23)
- [5] Dust collaborative AI (accessed 2026-10-23)
- [6] Dust product, models and connected tools (accessed 2026-10-23)
Post a Comment