How to Create a Custom AI Assistant: A Production-Ready Setup Guide

Begin with a sentence that names the user, trigger, deliverable, and reviewer. For example: “When an account executive enters a company and opportunity context, produce a sourced account brief for review before the discovery call.” That is more actionable than “help with sales” because it establishes when the assistant starts and what completion means.

Keep adjacent tasks out of version one. Researching an account, drafting outreach, updating a CRM, and sending an email have different evidence and permission requirements. Prove one outcome, then decide whether to add a controlled handoff to the next specialist or tool.

Organize instructions in a stable sequence: role, objective, source boundary, method, output contract, uncertainty behavior, escalation, and prohibitions. Use direct language and observable requirements. “Cite every material market claim” is testable. “Be accurate” is an aspiration. “Never infer private company metrics” defines a useful boundary.

Avoid hiding essential business rules inside examples or personality prose. OpenAI recommends clear instructions and well-defined tools as agent foundations. Anthropic similarly emphasizes simple, composable patterns and careful tool interfaces. The assistant should understand which instruction wins when speed, completeness, and evidence conflict.^{[1] [2]}

Context should be relevant, current, and authorized. Give the assistant the minimum company facts, reference documents, and connector scope required for its job. More context is not automatically better: stale policies and unrelated files can create conflict, increase cost, and make source attribution harder.

Classify tools by effect. Web search and read-only connectors gather information. Code can calculate or transform. Canvas can create an artifact. A connector write can alter an external system. OWASP recommends least privilege and explicit approval for security-relevant changes; the same principle is useful across operational business tools.^{[6] [11] [10]}

An evaluation case contains an input, environment, and success criteria. Start with ten to twenty representative cases: common work, incomplete information, conflicting sources, an out-of-scope request, a tool failure, and a request for a prohibited action. Run more than one trial for cases where model variability matters.

Grade both the final outcome and the trajectory. Deterministic checks can confirm required sections, calculations, links, and prohibited tool calls. A rubric can assess usefulness and judgment. Human reviewers calibrate the rubric and examine sensitive edge cases. This mixed approach follows current agent-evaluation guidance.^[3]

Save the first configuration that passes the launch rubric as a known-good version. When instructions, models, tools, or connector scopes change, run the regression set and record why the change was made. Do not silently replace behavior that other workflows rely on.

Kona supports private assistants, controlled sharing, publication, and forking. A shared version can remain stable while another user forks it for a different segment or output. Run history helps identify whether a problem came from routing, instructions, a specialist, a tool, or verification.^{[8] [3]}