How to Make an AI Bot with Clear Instructions and Limits

An AI bot is an assistant configured to handle a specific task — answering support questions, qualifying leads, processing a form, triaging a shared inbox — without a person stepping in for every request. Making one that works reliably means starting narrow, writing precise instructions, connecting only the tools it needs, and testing it against real inputs before it handles live traffic. Tools like fenbs keep the shared work context and prompt rules where your team can read them, so the people building and reviewing the bot start from the same brief.

Most bot problems come from an unclear task definition. A bot told to "handle customer questions" will eventually face a question its creator did not anticipate. A bot told to "answer questions about order status using the orders API, and escalate anything else to the support queue" is much easier to test, correct, and hand off.

Step 1: Define one task

Write the bot's task in one sentence before you build anything. That sentence should name the input (what triggers the bot), the action (what it does), and the output (what it produces or where it sends the result). "When a customer submits a contact form, read the inquiry type, draft a reply using the approved template for that type, and add the inquiry to the follow-up queue."

If the task sentence has more than one "and" in it, split it. A bot that handles inquiry routing, reply drafting, and CRM updates is three bots until you have tested all three functions individually. Start with one and add functions only after the first works reliably.

Step 2: Choose your platform

The platform you choose shapes everything else: the tools available, the integrations you can make, and how the bot connects to your users. Common choices include chatbot builders like Copilot Studio, Voiceflow, or Botpress for no-code or low-code setups; API-based setups using Claude, ChatGPT, or Gemini for developer-built bots; and AI platforms that include a bot interface for embedding on a website or in a Slack channel.

Match the platform to your task. A bot that needs to update a database or call an internal API needs developer-friendly API access. A bot that only needs to answer questions from a document set can use a no-code tool with knowledge base support. What is Cursor AI and how to use AI at work cover related tool choices for developer contexts.

Step 3: Write the system instructions

The system instruction is what the bot reads before every conversation. It defines its role, the rules it always follows, and the limits of its authority. A good system instruction is specific enough that you can predict how the bot will handle a message you have not seen yet.

• State the role: "You are the order status assistant for Acme Supply. You answer questions about orders placed on the Acme website."
• List the approved actions: "You can look up orders by order number or email address. You can provide status, estimated delivery date, and tracking information."
• Write the escalation rule: "For any question not about order status, say: 'That's outside what I can help with — please contact support at [link].'"
• Add any tone or format rules: "Replies should be under 100 words. Use plain language. No jargon."
• Include the limits: "Do not speculate about why an order is delayed. If status is unavailable, say so and offer to connect to support."

Step 4: Grant only the tools the bot needs

A bot that can read your orders database is useful. A bot that can also create orders, delete records, and update payment information is risky if those actions are not tested and approved. Grant the minimum set of tool permissions needed for the defined task, and add more only when you have tested the narrow version thoroughly.

Write each tool permission as a decision: what the bot is allowed to do, what it is not allowed to do, and who approved the permission. This record is useful when a new team member asks why the bot has certain access, or when something goes wrong and you need to trace the decision.

Step 5: Test with real inputs before going live

Collect 20-30 real examples of the inputs the bot will handle. Include the common cases, the edge cases, and at least five examples of inputs the bot should escalate rather than handle. Run each one and check the output. Fix the instructions based on what you see before going live.

Pay particular attention to the escalation cases. A bot that confidently attempts to handle things outside its scope is more damaging than one that correctly says "I can't help with that." Test the limits before they appear in front of real users. AI agents phone calls covers testing considerations for voice bots, which have additional requirements.

How to do this with fenbs

1. Create a free account and add a project for the bot build.
2. Add the task definition and the system instructions as tasks and Decisions and rules in the project.
3. Add a task for each testing phase: approved inputs, edge cases, escalation cases.
4. Record the tool permission decisions: what the bot can do, what it cannot, and who approved each.
5. After go-live, save any updates to the instructions as revised Decisions and rules so the record stays current.