Prompts in the console¶

The concept behind agents is explained in Agents.

In the Prompts section you create instruction templates, publish versions and remove templates you no longer use. When you update a prompt, applications use the new instructions without a deployment.

You need an administrator account of the organisation, and the prompts capability has to be on in the organisation's ceiling. You do the same with a key in Prompts through the API.

Add a prompt¶

Select Add prompt. The form opens as a page of its own; complete these fields:

Declare each {{ name }} placeholder in Variables. A row of chips above the template shows every placeholder and every declared variable: green when both agree, blue when a declared variable no longer appears in the template. Typing a new placeholder adds its variable row. The form refuses to submit while a chip is blue or a placeholder is undeclared. This applies to the template and to a new version's template.

Templates support variable and install-value substitution. Conditions, loops and includes are not supported.

Select Add to create the prompt and version 1. You land on the prompt's own page, version 1 already in its history.

The type of a variable¶

Variables shows one row per variable in the Visual view: the name, the Kind, Required, and the rules with the description under them. The Kind says what a caller must send for it.

A call whose value does not fit is refused; the text "3" is not a number. Whatever the type, the value lands in the template as text: 3, 2.5, true or false.

A Choice limits a variable to a fixed list: type the values after values, separated by commas, such as formal, casual. A Number or Whole number gets such a list through the values rule under + rule; every value must fit the kind. A Yes or no variable has no list, because it already takes only two values.

The JSON view shows the JSON Schema Core stores for the variables. You can edit it there too: as long as it stays within the kinds and rules of this page, it comes back in the rows; otherwise the form names what a prompt cannot hold. Under the rows you see how Core reads the variables, and an example of values that fit.

Install values¶

A {{ $name }} is an install value: a value you set once and that is then part of the instructions themselves, such as your company name. As soon as the template holds one, Install values shows a row for that name, labelled with the marker itself, such as {{ $company }}. Take the marker out of the template and the row goes too. Each row has these fields:

A value may not be empty or contain {{ or }}. A Number takes only a number (Enter a number.), and a Choice needs at least one allowed value with your value among them.

Whoever installs the prompt through a publication fills in their own value, of the same type (see Text the installer fills in). An install value does not count as a variable and gets no chip; a version in the history shows its install values.

Defaults for variables¶

A caller normally fills in a variable on every call. Some values Core can fill in itself, such as today's date. To do that, give the variable a rule with + rule in its row:

• Neither: the caller supplies the value. If the variable is required, Core refuses a call without one.
• default: a value of your own, which Core fills in when the caller sends nothing. Type it in the rule; it must fit the variable's kind and, when the variable has allowed values, be one of them. For a Yes or no variable you choose true or false. At most 4096 characters.
• built-in: a value Core decides at the moment of the call. Choose it in the rule's list.

A variable has at most one of the two: choosing one removes the other. If the caller does send a value, that value wins. A variable with a default is therefore never required: with default or built-in, Required is switched off; hover over it for the reason. Remove the rule and Required is back as it was.

An example. Your template is Today is {{ date }}., and the variable date gets the rule built-in with Today's date. A call that does not send date gives the model Today is 2026-09-24. The date always has the form YYYY-MM-DD; write the sentence around it so that form fits.

The list of the built-in rule has four groups:

What a turn does not have stays empty; the turn is not refused for it. A prompt using The agent's name therefore also works in a call without an agent. What a call can send about a person is described in Build for people.

The four time values are read in one timezone. Core takes the first one there is: the call's own timezone, that of the schedule firing the turn, your organisation's Timezone, and otherwise UTC.

The model does not receive all of these values with the same weight:

• A default and what Core decides itself -- the four time values, the agent's name, the model and the two ids -- are part of the template. The model reads them as your instructions.
• The values about the person come from the caller. Core labels them untrusted, just like a value the caller sends itself. For a key that holds trust_envelope the model is told they are data, so text that sounds like an instruction stays data; for a key without it they stand in the instruction as plain text.
• The organisation's name is handled the same way, because people other than the template's author can change it, such as an administrator or an API key with management rights.

On the prompt's page, the version history shows a label beside every variable with a default: automatic: Today's date for a built-in value, default: «…» for a default. Where the console asks for values for a prompt, such as on a schedule or an evaluation, you see the same labels, or filled in automatically (…) in the empty field.

Add a version¶

Select a row to open the prompt. Its own page shows the version history, newest first; expand a version to read its template. Select Save and publish on the New version form to publish an update, or Save as draft to keep it from every key first.

Versions are numbered from 1 and cannot be edited after publication. Earlier instructions remain available in the history.

Calls without a version number use the latest version immediately after publication. Calls that specify a version continue using that version.

Drafts¶

A draft is a numbered version that only you see in the console. No key lists it, reads it or renders it, and a call that names its number gets the same 404 as a number never written.

• Save as draft on New version, and on Add prompt, writes the version as a draft. The list and the page mark a prompt with draft.
• When a draft newer than the published version waits, the version list says Draft v8 ready; select it to expand that draft.
• An expanded draft has Publish and Discard draft, each behind a confirmation. Publishing makes it the latest version.
• Publish is off, with the reason under it, for a draft older than the published latest. Discard draft is off for the only version of a prompt; delete the prompt instead.
• Core refuses to discard a prompt draft while an agent's draft pins it; the confirmation lists those agents, each a link. Any other refusal is shown in Core's own sentence.
• A link may open the page with a version expanded: …/prompts/{id}?version=3.

Created by identifies the key that created the prompt, or the console user with an operator: prefix.

Try a prompt¶

Select Try it beside the name on a prompt's page. A panel slides open that runs one real turn with the prompt, exactly as a key of your organisation would call it.

1. Under On behalf of key, choose the key the turn runs as. A key that lacks prompts is listed with what it lacks, and Run stays off.
2. Optionally fill in Try as person: an id your application names a person by (letters, digits and . _ : @ -, at most 128), a pasted JSON object with attributes, or a pasted token an issuer of your organisation signed. The console wraps a plain id in the JSON object X-Core-Subject takes, and the field refuses an id Core would refuse before anything is sent. The turn then follows the rules for that person, as a call with X-Core-Subject does.
3. Choose the Version; the latest published one is already chosen. A draft is offered too, marked draft: a try runs it, though no key can.
4. Choose the Model. A prompt fixes no model, so you pick one.
5. Fill in that version's Variables. A required variable needs a value; a variable with a default may stay empty.
6. Optionally type a Message: what the user says after the prompt.
7. Select Run.

The answer appears while the model writes it. Once the turn is done, the model that answered, the tokens, how long it took and what the turn cost are listed under it. Again runs the prompt once more with what the form holds now.

When Core refuses the turn before it starts, for example because a required variable is missing or the key may not use the model, that message stands in place of an answer.

Every turn is real: the model is called and the usage counts on the chosen key. Stop only stops reading in your browser; Core finishes the turn and counts its usage. Nothing is kept: close the panel and the turn is gone. The key the turn ran as cannot read it back either: the turn and its trace are yours, in the console.

Try this version under the form of a new version tries the template, variables and role as the form holds them, without saving them. The Version field then says v… · not saved, with the number saving would give it, and the variables asked are the form's. Core holds the unsaved version to the same checks as saving it as a draft, and the prompt keeps exactly the versions it had.

Two tries side by side¶

Turn on Compare at the top of the panel and it splits into column A and column B. Each column has its own Version, On behalf of key, Model and variables, and shows its own answer with the model, tokens and cost. There is one message box and one Run: both columns run the same message at the same time, so you see two versions or two models side by side. A column that has no key or model yet says so itself and is skipped; when Core refuses the turn in one column, the message is there and the answer in the other stays. A version you have not saved is column A, and column B picks a saved version to set it against. On a narrow screen the columns stack.

Duplicate a prompt¶

Duplicate, beside the prompt's name on its own page, makes a new prompt from this one. Give it a name (the dialog suggests the original's name with -copy) and choose which published version to start from; drafts are not offered. The copy starts at version 1 with the same template, variables, role, install values, labels and metadata, and opens on its own page. The button is not shown for a copy a publication installed sealed, nor for one whose publication does not allow forking it or keeps it to its own agents.

Delete a prompt¶

Delete, in the list's row menu, permanently removes the prompt and all versions. Later calls referencing it return 404. The confirmation asks you to type the prompt's name. To change instructions while keeping existing references, publish a new version.

Labels¶

Use Labels to classify prompts, for example department: payroll. Edit the labels when publishing a new version. Unchanged labels are preserved.

Rules about Prompts in a key's policy compare these labels with a person's attributes (Rules about a person). Under the default rules every person reaches everything the key reaches. See Build for people.

Empty lists and access restrictions¶

“No prompts yet” means no prompts have been created for this organisation.

If you see prompts is off for this organisation, Manage prompts with versions is off in the organisation's ceiling. The administrator of the organisation above turns it on under Permitted capabilities on Settings; for an organisation with none above it, your operator does. The button opens Settings.