Frequently Asked Questions ========================== .. contents:: :local: :depth: 1 ---- Platform -------- What is OneByZero Neo? ~~~~~~~~~~~~~~~~~~~~~~ OneByZero Neo is an enterprise AI agent platform. It enables organisations to design, build, deploy, and govern AI agents at scale — across three modalities: Chatbot, Agentic Flow, and Voice Agent. Neo is built natively on AWS and provides the infrastructure, tooling, and governance controls that enterprise teams need to operationalise AI in production — including knowledge bases, guardrails, 15+ deployment channels, real-time monitoring, and multi-workspace access control. Does Neo require AWS? ~~~~~~~~~~~~~~~~~~~~~ Yes. Neo is AWS-native by design. It deploys into your own AWS account and uses Amazon EKS for compute, S3 for storage, and optionally Amazon Bedrock for managed LLMs and knowledge bases. Your data stays within your AWS environment at all times. Which LLMs are supported? ~~~~~~~~~~~~~~~~~~~~~~~~~~ LLMs are configured by your Super Admin in the platform-level LLM management screen. Any model added there becomes available to all agents across workspaces. Supported providers include Amazon Bedrock models (Nova, Claude, Llama, and others), as well as custom endpoints for self-hosted or enterprise-approved models. Model choice is decoupled from agent logic — you can swap or test models without rebuilding your agent. Is Neo suitable for production workloads? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Yes. Neo is designed for mission-critical, production-grade deployments. It supports high-availability EKS deployments, versioned agent publishing with rollback, real-time cost and usage tracking, and full conversation and LLM trace history across all agents. How does Neo handle security and data isolation? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Neo is built with enterprise isolation by default: * **Workspace isolation** — each team or project operates in its own workspace with its own members, agents, and resources. One workspace cannot access another's data. * **Role-based access control** — fine-grained permissions are defined per role and assigned to workspace members by a Workspace Admin. * **VPC-native deployment** — Neo runs entirely within your AWS VPC. No data leaves your cloud account. * **Secrets management** — API keys and credentials are stored centrally in Workspace Settings and never embedded in agent flows. Is my data used for model training? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ No. Neo runs within your AWS account and all data — conversations, documents, traces — remains in your environment. Nothing is shared with OneByZero or used for any model training purposes. ---- Getting Started --------------- What do I need before I can build an agent? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Three things: 1. A Super Admin must have configured at least one LLM model in the platform. 2. A Workspace Admin must have created a workspace and invited you as a member with a role that includes the ``canCreateAgents`` permission. 3. Your login credentials to access the workspace. If you have all three, follow the :doc:`Build Your First Agent ` guide. What is the difference between a Super Admin, Workspace Admin, and a Builder? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * **Super Admin** — manages the platform. Configures LLMs, creates workspaces, and assigns Workspace Admins. Has no visibility into what individual agents do. * **Workspace Admin** — manages a single workspace. Invites members, defines roles, and stores shared credentials and variables. Does not manage platform-level config. * **Builder / User** — creates and manages agents within a workspace. Can only see and do what their role permissions allow. See the :doc:`Getting Started ` guides for role-specific quickstarts. ---- Building Agents --------------- When should I use Chatbot vs Agentic Flow vs Voice Agent? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * **Chatbot** — rule-guided conversations with deterministic routing. Best for structured customer interactions, FAQs, and guided workflows where the conversation path is predictable. * **Agentic Flow** — multi-step reasoning agents built as a directed graph. Best for open-ended tasks that require tool use, data retrieval, conditional logic, and autonomous decision-making. * **Voice Agent** — phone-based agents using speech-to-text and text-to-speech. Best for call centre automation, outbound campaigns, and voice-first workflows. If you are unsure, start with Agentic Flow — it is the most flexible modality. How does publishing work? ~~~~~~~~~~~~~~~~~~~~~~~~~~ Publishing has three steps: 1. **Validate** — the platform checks the flow for structural errors. Fix any issues flagged before proceeding. 2. **Request Review** — submits the agent for approval. Status changes to Pending Approval. 3. **Approve and Publish** — a user with approval permissions reviews and approves. Publishing to EKS deploys the agent to the live environment. In some workspace configurations, the reviewer is a different team member from the builder. If you cannot approve your own submission, ask a colleague with approval permissions. Can I test an agent before publishing it? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Yes. The **Playground** button (play icon) in the top-right of the agent editor opens an interactive chat session against the current draft — no publishing required. This works for Chatbot and Agentic Flow agents. For Voice Agents, a simulation mode is available in the agent settings to test call flows before going live. Can I roll back a published agent? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Yes. Each time you publish, a new version is created. You can re-publish a previous approved version at any time from the agent's version history, which reverts the live agent to that version's behaviour. Can I use an agent I built outside the platform? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Yes — register it as a **Neo Code Agent**. Your service keeps running your code; the platform forwards requests to it and adds access control, versioning, and monitoring around it. Your service needs to answer a single endpoint, and you can either host it yourself or supply a container image for the platform to run. See :doc:`/neo_code_agents/index`. Why does my Neo Code Agent show no cost or token figures? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Because the model calls happen inside your own service, using your own credentials, the platform never sees them. Latency and conversation counts still reflect the proxied requests, but token and cost accounting only covers usage the platform itself performs. See :doc:`/neo_code_agents/monitoring`. ---- Foundry ------- What is the Foundry and who manages it? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The Foundry is the shared resource layer of Neo. It is where knowledge bases, guardrails, integrations (tools), datasets, and evaluations are created and managed — once — and made available to any agent in the workspace. Foundry resources are typically managed by a Workspace Admin or a designated platform team. Builders reference Foundry resources in their agents but do not need to create or maintain them. What is the difference between In-House Tools and Custom Tools? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * **In-House Tools** — pre-built tools provided by the platform (e.g. web search, calculator, Python REPL, Tavily, Twilio SMS). Available immediately with no configuration required beyond enabling them. * **Custom Tools** — REST API endpoints you define yourself. You provide the URL, HTTP method, request schema, and authentication. Custom Tools let agents call any internal or external API. Both types are added to agents via the **Integrations** component in the Agentic Flow canvas, or enabled in agent settings. Do guardrails apply automatically to my agents? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ No. Guardrails must be created in the Foundry first, and then explicitly configured at the agent level. A guardrail defined in the Foundry has no effect until it is attached to a specific agent. There is no automatic or workspace-wide guardrail inheritance. What is the difference between an In-House and a Bedrock knowledge base? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * **In-House Knowledge Base** — documents are uploaded directly into Neo, chunked, embedded, and stored in Neo's own vector store. Fully managed within the platform. * **Bedrock Knowledge Base** — knowledge is stored and managed in Amazon Bedrock, with S3 as the data source. Neo connects to an existing Bedrock KB using its ID and region. Best suited for organisations already using Bedrock for data management. Both types are used in agents via the **Knowledge Retrieval** component in the Agentic Flow canvas. Can an agent use more than one knowledge base? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Yes. The Knowledge Retrieval component supports multiple knowledge bases in a single instance. You can also configure a **Fallback KB** — a secondary knowledge base queried automatically if the primary returns no results. ---- Administration -------------- How do I give a team member access to build agents? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1. In **Workspace Settings**, go to the **Roles** tab and ensure a role exists with the ``canCreateAgents`` permission. Create one if needed. 2. Go to the **Members** tab and click **+ Invite Member**. 3. Enter the user's email address, assign the role, and save. The user will receive an invitation and can log in immediately. See :doc:`/7_workspace_admin/member_management` for full details. Where do I store API keys and credentials? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In **Workspace Settings**, under the **Secrets** tab for sensitive values (API keys, tokens, passwords) and the **Variables** tab for non-sensitive configuration values. Values stored here can be referenced by agents at runtime without being embedded in the flow. See :doc:`/7_workspace_admin/variables_secrets` for full details. ---- Monitoring ---------- Where do I see conversations and LLM traces for my live agents? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In the **Command Center**: * **Conversations** — full conversation history for every agent, filterable by date, channel, and agent type. Click any session to see the full message exchange and any KPI results. * **LLM Traces** — a detailed log of every LLM call made during a conversation, including latency, token usage, cost, and the full prompt/response. Available per session from the conversation detail view. * **Analytics** — aggregated dashboards showing message volume, session counts, token usage, and cost — at both workspace and per-agent level. See :doc:`/11_command_center/index` for full details. ---- Digital Co-Workers ------------------ What is a Digital Co-Worker, and how is it different from the three agent builders? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ A Digital Co-Worker is a configurable AI colleague that works across channels (NeoGPT, Microsoft Teams, and Outlook email), remembers context across sessions, and chooses the right skill for each request at run time. It is a separate construct, not a fourth modality: where the Chatbot, Agentic Flow, and Voice builders each produce one agent of a specific kind, a Co-Worker is assembled from skills and governed with guardrails and human-in-the-loop approvals. When you publish a Co-Worker, it is compiled into an orchestrating agentic flow. See :doc:`/coworkers/index` for the full guide. Can a Co-Worker reuse agents I have already built? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Yes. Open an Agentic Flow or Voice agent's Settings page and use **Expose as Skill**; it then appears in the Custom Skills sub-tab of every Co-Worker in the workspace, ready to enable. See :doc:`/coworkers/skills` for details.