Tag reference

You probably don’t need to read this chapter. Tags are an under-the-hood mechanism your AI uses to take structured actions in its responses. You don’t type them yourself in normal use. This reference exists for the rare customer who wants to write very specific system instructions, or who’s debugging behavior and wants to know what their AI is actually doing.

What a tag is

A tag is a bracketed instruction in your AI’s response that triggers a specific action when the response is processed.

For example, when you ask your AI to remember something, its response includes a line like:

[REMEMBER: Shane prefers outbound calls between 9 and 11am, not after lunch.]

The [REMEMBER: …] line is the tag. When your AI’s response is processed, that line triggers a write to the knowledge graph. The rest of the response is the human-readable conversation; the tag is the structured side effect.

Tags happen at the end of (or interspersed in) responses. They’re parsed out before the response is shown to you (in most cases), so you don’t see them unless you’re specifically looking at the raw response.

Why tags exist

The pattern lets your AI signal structured intent without needing a separate API call or tool invocation. The same chat turn that explains “I’ll remember that” is the chat turn that writes to memory, with the tag as the connecting bridge.

It also makes the action visible and reviewable. You can see exactly what your AI just wrote to memory by looking at the [REMEMBER: …] line.

The major tags

What’s listed here is current as of the time of writing; the canonical set is the one your AI actually emits, which can evolve.

[REMEMBER: <fact>]

Writes a fact to the knowledge graph (long-term memory). Used when:

• You ask your AI to remember something explicitly.
• Your AI judges that a fact you stated is durable enough to deserve a memory write.

[LIST: <name> | <action> | <items>]

Operates on a list. The action can be create, add, check, uncheck, delete, attach. The items are the items in question.

Example: [LIST: Beach trip packing | add | sunscreen, paperbacks, swimsuit] creates or extends the named list.

[TASK: <description> | <metadata>]

Creates a task. Metadata can include project, due date, owner.

Example: [TASK: Call the bank about the wire transfer | due:tomorrow | project:household]

[PROJECT: <action> | <metadata>]

Creates or modifies a project. Actions include create, update, archive, graduate-from-idea.

[PROGRAM: <action> | <metadata>]

Creates or modifies a program. Same shape as PROJECT but for ongoing containers.

[ENTITY: <type> | <name> | <fields>]

Creates or updates an entity of a specific type. Used for contacts, custom entities, anything that isn’t covered by a specific tag.

Example: [ENTITY: Contact | Mike Reynolds | role:contractor, phone:555-1234, project:kitchen]

[LINK: <a> | <b> | <relationship>]

Creates a relationship in the knowledge graph between two entities. Example: [LINK: Mike Reynolds | Kitchen renovation | contractor-on]

[ARTIFACT: <action> | <title> | <metadata>]

Produces or modifies an artifact. Common actions are create, revise, approve, publish.

[REMINDER: <when> | <message>]

Sets a one-time reminder.

[GOAL: <action> | <name> | <schedule> | <rules>]

Creates or modifies a goal (the scheduled, recurring kind).

[FOLLOWUP: <condition> | <action>]

Creates a follow-up: a watcher that fires when a condition is met.

[SET_PREF: <preference>]

Records a standing preference. Similar to REMEMBER but typed as a preference rather than a fact.

[CHANNEL_PREF: <channel> | <rules>]

Records channel-specific preferences (when to use Telegram, when to default to email, etc.).

[DASHBOARD: <layout>]

Configures the dashboard view based on context. Used when a project’s dashboard widgets should change in response to what’s happening.

[INBOX: <action>], [READDOC: <action>], [IMAGE: <action>], [EMAIL: <action>]

Internal handler tags for specific kinds of work (processing inbox messages, reading documents, handling images, sending email). You wouldn’t typically encounter these in user-visible responses.

[FORGET: <reference>]

The inverse of REMEMBER. Removes a fact or memory by reference.

Seeing the tags in a response

Most customers never see the raw tags. They’re processed before the response renders.

If you want to see them for debugging, there’s a developer mode toggle in Settings → Advanced → “Show raw responses”. This shows the unprocessed response with tags inline. It’s noisy but useful when you’re investigating behavior.

Writing your own system instructions

The reason this reference might matter to you is if you’re writing system instructions that specifically reference these tags. For example, in a custom toolkit you might write a playbook step like:

“When the user describes a new contact, emit a [ENTITY: Contact | ...] tag with their name, relationship, and any context provided.”

This is a developer/power-user case. Most customers don’t write at this level; they just describe what they want and let their AI pick the right tag.

Tags are an implementation detail

A friendly reminder: the tag system is the current mechanism. It could change. If a new release of Jootle uses a different mechanism (function calling, structured outputs, something else), your AI’s responses would still be the same shape to you, but the internal hooks would be different.

If you’re writing toolkit code that depends on specific tag formats, watch the changelog for breaking changes. Most updates are additive and backward-compatible; some refactor enough that toolkit authors need to adjust.

Where to learn more

For more detail on tags as they relate to building toolkits, see the developer reference (the JTF spec). It’s the technical document, not part of this customer handbook.