Frequently Asked Questions
How is Drayvn different from a traditional chatbot platform?
Drayvn should be positioned as a broader enterprise AI platform. It supports not only conversational experiences, but also agent orchestration, workflow execution, knowledge grounding, governance controls, administrative management, and extensibility across systems. The key distinction is that Drayvn is designed for operational AI, not only scripted interactions.
Do users need to know how to code to use Drayvn?
No. Drayvn should be described as accessible to both technical and non-technical teams. Visual builders, reusable templates, guided configuration, and modular tools help reduce the barrier to entry, while more advanced teams still have room to extend the platform when deeper customization is needed.
Can Drayvn work with our existing systems?
Yes. Public documentation should make clear that Drayvn is intended to fit into enterprise environments by connecting to existing systems, data sources, tools, and workflows. The message is compatibility and adaptability, not rip-and-replace.
How does Drayvn handle governance and oversight?
Drayvn includes governance capabilities across access control, guardrails, monitoring, auditability, and workspace administration. This helps organizations introduce AI in a controlled way and maintain visibility as adoption expands.
Is Drayvn only useful for one type of use case?
No. The platform is intentionally flexible. It can support conversational assistants, retrieval-backed experiences, governed research workflows, operational copilots, and agent-driven automation patterns across multiple teams and business functions.
Can Drayvn support both pilots and enterprise-scale deployments?
Yes. A strong way to phrase this publicly is that Drayvn supports phased adoption. Teams can begin with a focused initial use case, then expand into additional workflows, users, and systems over time without changing platforms.
How does Drayvn help improve quality over time?
Drayvn supports review and iteration through visibility into usage, executions, workflows, and governance outcomes. The platform should be framed as something teams can continuously refine rather than a one-time deployment.
What does the website documentation cover versus the in-platform documentation?
The website documentation is intended to provide a high-level understanding of platform capabilities, architecture, governance, and integration options. The in-platform documentation is intended for authenticated users who need deeper product instructions, configuration details, and operational guidance.