System prompt and persona assembly

Before DataMind Oda starts any task, the request it sends opens with its instructions: who it is, how it should work, and what its tools are. This page shows how that text is assembled for a deployment of Oda: the parts it is built from, the order they take, and the pieces around them. It is for the people who configure a deployment; the guidance you write yourself lives on Create a custom preset.

What the assembled prompt is made of

The instructions are not one fixed text. They are assembled when a request is built, from parts registered with the deployment, and the result travels as the opening message of the conversation.

• Sections: blocks of guidance, such as how to plan, how to work with a team, and how to use each tool. Each section has a placement number that fixes where it renders.
• The runtime context: a snapshot of the current situation, taken while the request is built and refreshed for each one.
• The persona: a prefix and a suffix that wrap everything else in the deployment's own voice.
• Tool descriptions: every tool an agent can see contributes its description to the text; registering a tool is enough to include it.

The text is part of the conversation rather than a hidden field, so a change to it arrives as a later message. The Oda agent runtime covers how agents are created and driven, and Tools and how they are offered covers what the tool descriptions are.

Sections and their order

• Placement numbers decide. Sections render in ascending order of their number, never in the order they were registered.
• Ties go by name. Two sections that share a number fall back to alphabetical order by name.
• Keep ten apart. A new section sits at least ten numbers away from its neighbours, so a later section can take a free number in between without renumbering the rest.
• A number is required. A placement that is not a number refuses the assembly with order must be a finite number.

The deployment layer and the scoped layers

Two kinds of registration feed the assembly: the deployment's own text, and text registered from a narrower scope, such as one agent's composition.

• The nearest scope wins by name. When a narrower scope registers a name that already exists, its version is used for that scope's assemblies only; every other scope keeps the wider text.
• A duplicate in one layer is refused. The same name registered twice in one layer is refused with prompt section "<name>" is already registered; within a scope the message ends already registered in this scope. A narrower scope is the way to give one agent its own version.
• A scope's text lives with the scope. When the scope is disposed, the sections, contexts, tools and variables it added go with it.
• One section can claim the whole prompt. A section marked as the complete prompt replaces everything else: the assembly renders exactly its text. Two sections claiming it at once refuse the assembly with multiple complete prompt sections are active: followed by both names.
• Adjustments run while the text is assembled. A listener can see the ordered text, add sections of its own, and return the version it wants; the version it returns is the one used, for the scope it is registered in. Two decisions stay outside its reach: a section that claims the whole prompt, and a runtime context the deployment has turned off.

The identity line

Oda carries an identity line, but a deployment does not have to use it. It is off by default, because the instructions your DataMind server supplies already set out who the agent is. Switch it on for a deployment whose server instructions carry no identity; the prompt then opens with:

You are an AI agent powered by DataMind Oda.

The runtime context

The runtime context is on by default. It is a snapshot of the current situation, and each new snapshot supersedes the earlier ones. Its heading makes that clear:

Current runtime context. This snapshot supersedes earlier runtime-context snapshots.

• Off for one scope. Where a scope should run without it, the context is left out of that scope's assemblies. The parts that feed it are not disabled, and it returns when the scope ends.
• Off for the deployment. Turned off entirely, nothing that would feed the context is run, and nothing can add to it.
• Empty. When everything in it has been cleared, it reads: Current runtime context: none. Earlier runtime-context snapshots no longer apply.

The persona prefix and suffix

The persona is two pieces of text around the assembled prompt. Both are empty by default, so a deployment that wants neither gets its sections alone.

• The prefix opens the text, right after the identity line and before the shared sections.
• The suffix closes it, after everything else.
• A narrower scope can replace either piece by name for its own assemblies only; other scopes keep the deployment's text.

Tool descriptions in the prompt

• Registered means included. A tool's description joins the text automatically when the tool is registered; there is no second step.
• Alphabetical by default. Tool descriptions render in name order, whatever order they were registered in.
• A named order overrides that. A deployment can list the order it wants. Listed tools take their listed positions, and everything else goes where the rest entry stands, in name order among themselves.
• The rest entry is reserved. It is called <unlisted-tools> and must be present in any named order; a tool may not take that name.
• Checked, not best-effort. A name listed twice, a name that matches no tool, or a missing rest entry refuses the assembly rather than being skipped, and the refusal names the offending entries and the tools that exist.

Variables inside the text

Instruction text can refer to values with double braces: {{name}}. A name starts with a lowercase letter and continues with lowercase letters, digits or underscores.

• Complete groups only. Spaces inside the braces, as in {{ model }}, and nested braces are malformed and refuse the assembly.
• Oda fills in what it supplies. The current model and the chat's working folder are filled in for each request, and a deployment can register more values.
• Rendering is strict. The text is refused rather than sent with a gap: an unknown name (unknown prompt variable "{{name}}" in section "...", with the registered names listed), a registered name with no value for this assembly (prompt variable "{{name}}" has no value for this assembly (section "...")), and a malformed reference each refuse it. A malformed prompt is worse than a loud failure.
• Values are not read twice. Text that arrives as a value is kept as written, braces included, and a lone {{ with no closing }} after it stays ordinary text.
• Some text keeps its braces. The tool instructions switch filling off on purpose, so tool descriptions can carry their own brace syntax literally.

When the text changes

• The assembled text is recorded in the conversation as its opening message; there is no separate hidden field for it.
• While the text renders the same from one request to the next, the unchanged beginning of each request stays reusable.
• When it changes while a chat continues, the new version is added later in the conversation; earlier messages are not rewritten, and the reuse of the unchanged beginning ends from the first point that changed.
• A change to shared text applies from the next assembly, for every scope that shares it.
• If a deployment renders no text at all, the earlier instruction message is cleared, so nothing out of date stays in force.

Questions, answered

Where does Oda's identity line come from?

It is part of the assembled prompt, and it is optional. The line reads You are an AI agent powered by DataMind Oda. and it is off by default, because the instructions your DataMind server supplies already carry the identity. A deployment whose server instructions have none can switch it on.

Can I change the instructions from inside a chat?

No. The text is assembled from what the deployment and its scopes register, and a chat has no editor for it. The guidance you write yourself goes into a preset's instructions instead; see Create a custom preset.

Can one preset run with its own persona?

Yes. A narrower scope can replace the persona prefix or suffix by name for its own assemblies, and every other scope keeps the deployment's text.

Is the runtime context always added?

It is on by default. It can be left out of one scope's assemblies without disabling what feeds it, or turned off for the deployment entirely, in which case nothing that would feed it runs and nothing can add to it.

What happens if a {{...}} reference cannot be filled?

The whole assembly is refused rather than rendered with a gap. An unknown name, a registered name with no value for this assembly, and a malformed reference each refuse it, and the messages name the reference, its section and the values that exist. When you edit preset instructions, the editor checks the braces as you save them; the checks on this page are the assembly's own.

How are tool descriptions ordered in the prompt?

Alphabetically by name by default, regardless of registration order. A deployment can name its own order: listed tools take their listed positions, and everything else goes at the rest entry, alphabetically among themselves. A name listed twice, a name that matches no tool, or a missing rest entry refuses the assembly.

What happens when the instructions change while a chat continues?

The new version is added later in the conversation; earlier messages are not rewritten, and the reuse of the unchanged beginning ends from the first point that changed.

Can a section replace the whole prompt?

Yes, one section can be marked as the complete prompt, and the assembly then renders exactly its text. Two sections claiming it at once refuse the assembly: multiple complete prompt sections are active:, followed by both names.

Why was my section refused as already registered?

The same name was registered twice in one layer. A narrower scope may shadow a wider name for itself, but a duplicate inside one layer is refused rather than merged; give the second registration to a narrower scope instead.

Does the section order depend on when sections were registered?

No. Placement numbers decide the order, and two sections that share a number fall back to name order. Registration order never matters.

How far apart do new sections have to sit?

At least ten numbers from their neighbours. The gap leaves room for a later section to take a free number in between without renumbering anything else, and a placement that is not a number refuses the assembly.