Writing Instructions

The quality of your instructions directly determines the quality of the knowledge graph and AI responses. Vague instructions produce vague results. Specific, well-structured instructions produce graphs and answers you can trust.

Ingestion instructions
Retrieval instructions

Be specific about entity types

List the exact types you want extracted. Vague instructions leave Along guessing, and the graph will reflect that ambiguity.Don’t say “extract important people and organizations.” Say “Extract: Person (name, title, company), Organization (name, industry, headquarters).”

Specify exclusions explicitly

It’s often more effective to state what to skip than what to include. Along’s defaults are broad by design. Exclusions help you trim noise without having to enumerate every entity type you do want.

One instruction per concern

Break complex requirements into separate sentences rather than compound clauses. Long compound instructions are harder to follow consistently. “Extract deals and link them to their participants and their companies and their competitors but not internal stakeholders” is four separate rules — write them as four sentences.

Test incrementally

Add a small batch of representative content, inspect what the graph captures, then refine. Don’t try to write perfect instructions for content you haven’t seen yet. The graph’s entity and relationship counts are visible from the Safe dashboard — use them as feedback signals.

Good vs. bad example

Bad:

Extract important things and make connections between them.

Good:

Extract: Person (name, title, company), Organization (name, industry), Deal (name, stage, value).
Create WORKS_AT relationships between Person and Organization.
Create INVOLVED_IN relationships between Person and Deal when they are mentioned as a participant.
Skip: internal HR documents, financial reports, meeting invites without an agenda.

The bad example gives Along nothing actionable. The good example specifies types, relationships, and exclusions — each as a discrete instruction.

Lead with the persona

Define who the AI is in one sentence before anything else. This anchors all downstream behavior. “You are a technical support assistant for [Product]” is more reliable than scattering persona cues throughout the instructions.

Set scope before style

Scope constraints (what questions to answer) should come before format rules (how to answer them). The AI needs to know what it’s allowed to do before it can follow style guidance.

Use “always/never” for hard rules

Hard rules expressed as “always” or “never” are followed more reliably than hedged language like “try to” or “when possible.” If citation is non-negotiable, write “Always cite the source document.” If speculation is off-limits, write “Never speculate beyond what the documents state.”

Keep it under 2,000 characters

Longer instructions are followed less consistently. The most important rules should come first — if the AI has to choose which instructions to follow due to context pressure, you want the critical ones to win.

Avoid conflicting rules

If your instructions say “be concise” and also “always provide full context,” the AI will pick one interpretation. Audit your instructions for contradictions before deploying them.

Good vs. bad example

Bad:

Be helpful and answer questions as best you can using the available information in a friendly and professional manner while also making sure to cite sources when possible and keeping answers concise but also thorough.

Good:

Answer questions using only information in this Safe.
Cite the source document for every factual claim (format: [Document Title, Date]).
If the answer is not in the knowledge base, say "I don't have that information in this Safe."
Keep answers under 300 words unless the user asks for detail.

The bad example is a single run-on sentence with soft language (“when possible”) and conflicting guidance (“concise but also thorough”). The good example has four clear, ordered rules — each unambiguous and independently actionable.

Common patterns

Common instruction starters

Citation enforcement

Cite the source document for every factual claim. Use the format [Document Title, Date].
If no source is available for a claim, do not include the claim.

Scope limiting

Only answer questions about [topic or domain]. If the user asks about something outside this scope, say "That's outside what this Safe covers" and do not attempt an answer.

Tone setting

You are a [role] for [team or company]. Communicate in a [formal/conversational/technical] tone.
Assume the reader has [basic/intermediate/expert] familiarity with [domain].

Recency preference

Prefer information from documents dated within the last 90 days.
When citing older documents, note the date and flag that the information may be outdated.

Structured output format

Format all [deal/account/issue] summaries with the following fields:
- [Field 1]
- [Field 2]
- [Field 3]
If a field is not documented in the knowledge base, write "Not recorded" — do not omit the field.

Overview

Safe Context

MCP Connection

MCP Tools

Writing Instructions

Be specific about entity types

Specify exclusions explicitly

One instruction per concern

Test incrementally

Good vs. bad example

Lead with the persona

Set scope before style

Use “always/never” for hard rules

Keep it under 2,000 characters

Avoid conflicting rules

Good vs. bad example

Common patterns

​Be specific about entity types

​Specify exclusions explicitly

​One instruction per concern

​Test incrementally

​Good vs. bad example

​Lead with the persona

​Set scope before style

​Use “always/never” for hard rules

​Keep it under 2,000 characters

​Avoid conflicting rules

​Good vs. bad example

​Common patterns

Be specific about entity types

Specify exclusions explicitly

One instruction per concern

Test incrementally

Good vs. bad example

Lead with the persona

Set scope before style

Use “always/never” for hard rules

Keep it under 2,000 characters

Avoid conflicting rules

Good vs. bad example

Common patterns