AI Assistants

An Assistant is a persistent AI teammate. Unlike a one-off session, an assistant has a name, a personality, a set of rules it follows, long-term memory, and a queue of tasks. The same assistant launches many sessions over time, picking up context from the last one.

What an assistant is good for

• A focused worker on one project. A “ledger-engine” assistant that lives in your billing repo, knows the codebase deeply, and is who you bring tasks to.
• A role on a team. A “reviewer” assistant that takes pull requests off a board and writes review comments.
• A scheduled job with judgment. An “ops-watch” assistant that wakes every hour, checks logs, and only files a task if something looks off.
• A long-running researcher. An “rfc-drafter” assistant whose conversation history is a knowledge base you can search.

Assistants are not the only way to use Glueprint — a one-off session is fine for one-off work. Use an assistant when continuity matters.

What gives an assistant continuity

Three things, all editable:

• Persona — a paragraph or two describing the assistant’s voice, role, and style. Read it as the assistant’s character sheet.
• Constitution — the rules the assistant follows, in plain language. Your organization’s constitution applies on top of every assistant’s own.
• Memory — a structured store the assistant writes to itself, with typed long-term entries, a daily journal, user-seeded reference files, and an auto-generated index. See Memory.

The persona and constitution are loaded every time the assistant wakes; the assistant reads its own memory and journal as part of the wake-up briefing.

What an assistant has

Surface	What you’ll find
Chat	A persistent conversation with you. Send a message, the assistant wakes, replies, and the message becomes part of its memory.
Tasks	The assistant’s personal queue. See Tasks and boards.
Routines	Scheduled instructions that wake the assistant on a cron. See Routines.
Memory	Long-term, journal, reference, and index. See Memory.
Workbench	A working folder where the assistant can put drafts, notes, and intermediate artifacts.
Sessions	The history of sessions this assistant has launched.
Prompts	Tune the system prompt, overlay, and per-trigger wake message. See Prompting settings.
Extensions	Plug in skills, subagents, and MCP servers. See Extensions and The built-in MCP server.

Where assistants live

An assistant lives on one host. The folder it works in is its working directory. When you chat with the assistant, the session it spawns runs on that host.

You can run different assistants on different hosts. Cross-host teams (where assistants on different machines work together) are covered under Assistant Teams.

Working with an assistant

The most common pattern:

1. You send a chat message describing what you want.
2. The assistant wakes, reads your message + its memory + its tasks + any due routines, and decides what to do.
3. If the work needs an actual coding session, the assistant starts one in its working directory.
4. You watch the session as it runs, approve any risky actions, and see the assistant reply on chat when it’s done.

You don’t have to be online for any of this. If you queue a task or send a chat message and walk away, the assistant works while you’re gone.

What an assistant is not

• Not its own model. Assistants delegate to Claude Code, Codex, or Gemini under the hood. Pick the agent on the assistant’s settings.
• Not tied to a project. Assistants don’t have a “project ID.” They have a working directory, and tasks can pull them into any project that makes sense.
• Not stateless. Every wake reads memory and the recent transcript. Your context survives across days, machine restarts, and engine updates.

Next step

• Set one up: Create an assistant.
• See how persona and constitution work: Persona & constitution.
• Understand the memory model: Memory.