Custom AI Assistant: How to Build One for Work

A custom AI assistant is a general AI model configured with instructions, context, and tools for a specific job. The model itself comes from a provider like Anthropic, OpenAI, or Google. The custom part is the system prompt that tells it its role, the tools it can use, and the rules it must follow. Tools like fenbs supply the shared project context and reusable instructions that the assistant reads when it starts, so you do not have to paste a briefing into every new chat.

This guide covers the four steps to build a custom assistant that is actually useful: defining the job, writing the instructions, choosing the tools, and testing with real cases.

Step 1: Define the job clearly

The most common mistake in building a custom assistant is defining the job too broadly. An assistant for everything tends to be good at nothing. Start with one specific task that you do often, that has a clear output, and that you can check.

Write a one-sentence job description: "This assistant reviews contract drafts and flags clauses that need a lawyer's attention" is more useful than "This assistant helps with legal work." The narrower the job, the easier it is to write instructions that fit and tests that cover it.

• Pick a task with a clear output: a draft, a list, a summary, a decision, a piece of code.
• Name the person it serves: the person writing legal briefs, the developer working in Python, the marketer drafting social posts.
• State what is out of scope: what it should refuse or redirect to a person.
• Describe the approval step: which outputs can be used directly, and which need a person to review first.

Step 2: Write instructions that hold up

Instructions for a custom assistant are written in the system prompt: the invisible text the assistant reads before every conversation. Good instructions are specific, testable, and short enough that the assistant can hold them in mind throughout a conversation.

Write the instructions in second person ("You review contract drafts...") and in present tense. State the goal first, then the format of the output, then any standing constraints. Avoid vague instructions like "be thorough" or "use good judgment." Replace them with specific behaviors: "flag every clause that assigns liability without a cap" or "always cite the specific section you are commenting on."

Test the instructions by trying to break them before users do. Ask the assistant to do something outside its job. Ask it a question that requires judgment you have not specified. Where it goes wrong, revise the instructions rather than expecting the assistant to guess your intent.

Step 3: Choose the tools it needs

Tools are what an AI assistant uses to take actions beyond text: web search, code execution, file reading, database lookup, or connections to outside services. Give the assistant only the tools it needs for the defined job. An assistant with access to tools it does not use is harder to supervise and easier to misuse.

• Web search: for tasks that require current information or external sources.
• Code execution: for tasks that produce or check code outputs.
• File reading: for tasks that require analyzing uploaded documents.
• External connections: for tasks that require reading or writing to an outside service.

MCP is the standard way for an AI app to use an outside tool. An assistant connected to fenbs over MCP can read the project context, current tasks, and standing rules before it works, and save its progress when it stops. Check Integrations for the apps that support this connection.

For coding-focused assistants, what is Cursor AI covers how a purpose-built coding assistant uses tools differently from a general assistant.

Step 4: Test with real cases before you rely on it

Testing a custom assistant means using the inputs it will actually receive, not examples you designed to make it succeed. Find three to five real examples of the task: a typical case, a hard case, and a case that is outside its scope. Check the output for each.

A typical case should succeed cleanly. A hard case should show where the instructions need more precision. An out-of-scope case should produce a clear refusal or redirect, not a confident wrong answer. If the out-of-scope case returns a plausible-looking result, your scope statement is too vague.

Keeping prompts and context shared

If more than one person will use or maintain a custom assistant, the instructions need to live somewhere everyone can find them. A system prompt written in one person's local notes is a single point of failure. When that person leaves or forgets the reasoning behind a constraint, the assistant's behavior becomes unexplainable.

The same applies to project context. An assistant that needs to know the current state of a project should read that state from a shared record, not from a briefing pasted in at the start of each session. For AI desktop assistants, that guide compares the general-purpose tools you might build on top of.

How to do this with fenbs

fenbs does not host or run a custom assistant, but it gives the assistant a shared project record to work from and a place to store its instructions.

1. Create a free account at fenbs and add your project.
2. Write the assistant's job description in Decisions and rules: its scope, its constraints, and the approval steps.
3. Add the assistant's reusable instructions to Skills and prompts.
4. Connect the AI app you are building on from Integrations.
5. Ask the connected assistant to read the project context and the relevant prompts at the start of each session before it works.

When a custom assistant is not the right approach

A custom assistant adds value when you do a task often enough to justify writing and maintaining instructions for it. For one-off tasks, a general AI chat tool with a good prompt is faster. For tasks that need a deployed chatbot others interact with, AI call assistants and dedicated bot platforms serve the user-facing case better than a configured chat tool.