How to Write Custom AI Assistant Instructions

How to Write Instructions for a Custom AI Assistant

Strong custom AI instructions define an observable job, trusted evidence, required output, non-goals, uncertainty behavior, permission limits, and escalation path. They do not depend on telling the model to become a fictional expert.

Write the assistant contract first. Then turn it into a compact behavior specification that can be tested.

flowchart TD
    A["Assistant contract"] --> B["Job and intended user"]
    B --> C["Inputs and source hierarchy"]
    C --> D["Process and output"]
    D --> E["Non-goals and permissions"]
    E --> F["Uncertainty and escalation"]
    F --> G["Examples and test cases"]
    G --> H["Versioned instruction file"]

Begin with the job

The first lines should state what the assistant does, who uses it, and where its responsibility ends.

A useful version might say:

Turn Dalton's approved episode notes and transcript-derived claims into a draft podcast outline that follows the current Venture Step structure. The output is a draft for Dalton's review. Do not publish, invent guest facts, or treat current product claims as verified unless an approved current source is supplied.

That instruction names a user, transformation, source boundary, output state, and prohibited actions.

"You are a world-class podcast strategist" does none of those things. It may change tone, but it does not create knowledge, permission, or accountability.

Define accepted inputs

Tell the assistant what it may receive and what makes an input usable.

For an episode-outline assistant, accepted inputs might include an immutable transcript, approved notes, a title, the current outline template, and a source ledger. If the transcript is missing or the file is only a production outline, the assistant should say so.

Describe what to do with malformed or unexpected input. A system that silently guesses a date, speaker, source, or field can turn a small omission into a polished error.

Create a source hierarchy

Name which sources control. The instruction should distinguish direct evidence, official current documentation, secondary context, and unsupported ideas.

For example, a recording-derived transcript controls what was said. A production outline establishes what was planned. A vendor help page establishes the vendor's current stated behavior. None of them independently proves performance or compliance.

If sources conflict, require the assistant to preserve the conflict and identify what would resolve it. If no approved source supports a claim, require omission or a visible research gap.

This is more useful than "cite your sources." A citation can still be irrelevant, outdated, or misread.

Specify process only where it aids inspection

Do not fill the instruction with hidden reasoning demands. Describe the visible checks the work requires.

An editorial assistant might identify source-backed claims, separate dated experience from current facts, draft an answer-first opening, add direct links, check for unsupported claims, and return unresolved questions.

A reporting assistant might validate the period, reconcile totals, flag missing rows, draft commentary, and stop before distribution.

The process should help a reviewer see whether the important work occurred.

Describe the output in natural terms

State the artifact, required sections, tone, attribution, and review markers. Include machine-readable fields only if another system genuinely needs them.

Avoid formatting instructions that make the output look automated. E033 captured the Venture Episode Engine turning too much text bold. The result looked organized, but it was harder for Dalton to scan.

Formatting should serve the reader. For public Venture Step drafts, that means natural Markdown, answer-first prose, focused headings, useful tables or diagrams, and visible source and review boundaries. It does not mean repetitive label-and-colon bullets.

Write non-goals as explicit behavior

The assistant should know what not to do.

If it is a drafting tool, tell it not to publish or send. If it uses a transcript, tell it not to invent quotations. If it handles product documentation, tell it not to treat a vendor claim as independent validation. If current facts are required but browsing is unavailable, tell it to stop and request a current source.

Non-goals protect the task from scope drift.

Add uncertainty and escalation

"Do not hallucinate" is not an executable rule. Models can be wrong without recognizing it.

Define what the system should do when evidence is absent, ambiguous, contradictory, stale, or outside scope. It can mark the claim unsupported, ask one narrow question, produce a partial draft, or route the issue to a named owner.

The escalation path should identify who decides. "Check with a professional" may be appropriate for a public warning, but an operating instruction should name the actual reviewer or team.

Separate permission from capability

An assistant may be technically capable of drafting an email, calling a tool, or searching a connected drive. That does not mean it is authorized to do so.

Write the allowed reads and writes. Identify the account and destination. Require approval immediately before a consequential action. Define whether a retry is safe and how duplicate actions are prevented.

For a simple custom assistant, the safest instruction may be that it produces text only and has no external write authority.

Use examples to expose the boundary

Examples should show behavior, not just style.

Include a normal input, a missing-source input, a conflicting-source input, and an out-of-scope request. Show the expected properties of the response.

One good example can demonstrate attribution and structure. One refusal example can show how the assistant handles private data or unauthorized publication. Avoid adding so many examples that they become a hidden and unmaintained rule set.

Review AI-rewritten instructions as a diff

Google's current Gem help describes an option to use Gemini to rewrite instructions. E033 showed why that is appealing. A few rough sentences became a structured configuration quickly.

Treat the result as an editorial suggestion. Compare it with the human-written contract. Look for new assumptions, exaggerated expertise, missing non-goals, weakened source rules, additional actions, and formatting noise.

Google's current Gem sharing help says users with access can see Gem instructions and uploaded files. Do not place secrets, credentials, or private operational details in instructions that may be shared.

A compact instruction structure

Keep the instruction as short as the task permits. Length does not create clarity.

Test behavior, not eloquence

Run the same cases before and after the instruction change. Score whether the assistant used the right evidence, followed the boundary, produced the required artifact, and made review easier.

NIST's Generative AI Profile recommends risk-relevant evaluation before deployment and on an ongoing basis. That applies even when the configuration is only a prompt field.

The next step is [[How to Test an AI Assistant on a Bounded Task]]. If the instruction still describes broad authority, return to [[Saved Prompt, Custom Assistant, Workflow, or Agent]] and name the actual system.

This task guide was developed with AI assistance from E033, current Google documentation, the linked instruction specification, and NIST guidance. Dalton Anderson remains the author. Product, technical, privacy, safety, current-source, and founder review are mandatory before publication. Publication is not authorized.