A coding session is a sprint. You start an agent, watch it work, approve a few tool calls, and when the task is done the session ends and its context evaporates. That is exactly what you want for a one-off change. It is exactly the wrong shape for the work that never really ends — triaging the inbox, sweeping pull requests, keeping the changelog honest, answering the same setup question for the tenth time.
That work wants a coworker, not a sprint. So we built assistants.
A session is temporary. An assistant is not.
An assistant is a persistent identity that lives on your machine and wakes when there is something to do. Each one carries four things, all written to disk as plain files you can read, edit, and version:
- A persona — who it is, how it writes, what it is for.
- A constitution — the rules it must follow, layered under your org’s rules.
- Memory — what it has learned, as typed markdown files in a local git repo.
- A workspace — where it actually does the work.
None of this is locked in a database or a vendor’s cloud. Open the assistant’s directory and you will find its persona.md, its constitution.md, its memory, and an AGENTS.md that any supported harness reads on startup. If you want to change how an assistant behaves, you edit a file. If you want to know what it did, you read one.
Memory that survives the restart
The thing that separates an assistant from a chat window is that it remembers. Glueprint gives each assistant a real memory system, not a scrollback buffer:
- Long-term memory is a set of typed files — facts about you, the project, your feedback, and reference material — each rebuilt into an auto-generated index so the assistant can find what it knows.
- A daily journal captures what happened, day by day. Today and yesterday load on every wake; older entries stay searchable.
- Every write is committed to a per-assistant git repo, separate from your project’s history. Memory is inspectable, diffable, and revertible. If an assistant learns something wrong, you can see exactly when it learned it and roll it back.
Assistants manage this themselves through a small set of built-in tools — gp_remember to file a durable fact, gp_journal to log progress, gp_recall to search everything they know — so memory grows as a deliberate act, mid-task, not as an undifferentiated transcript. Read more in the memory guide.
They wake on their own
You do not babysit an assistant. You give it routines — cron-driven instructions that wake it on a schedule. Triage the inbox every thirty minutes. Sweep open PRs at 9am. Run the nightly cleanup. When a routine fires and there is genuinely nothing to do, the assistant notes it and goes back to sleep without burning tokens.
They also wake when you need them: mention one in a channel, or just open its chat and talk. On Claude Code, the session resumes across restarts, so context carries over for weeks rather than resetting every morning.
Run them on any harness
An assistant is an identity, not a model. The same persona, constitution, and memory drive a session on Claude Code, Codex, Gemini CLI, or any ACP-compatible harness in the registry. Pick the runtime that fits the task; the assistant comes along unchanged. Its login and subscription belong to the underlying CLI — Glueprint spawns the agent and carries the identity, it does not sit between you and the model provider.
Governed by default
Autonomy without guardrails is a pager incident waiting to happen. Every assistant runs inside an enforced governance layer:
- Permission tiers — Allow, Ask, or Deny — layered org to host to team to assistant.
- Tool filters and token budgets, so an assistant can only reach for what it is allowed and only spends what you have allotted.
- Quiet hours, so the night-shift routine does not page anyone at 3am.
- Constitutions as files on disk — versioned and reviewable — and an audit log that records every action.
The rules are not buried in a settings panel. They are text, in git, where you can review a change before it ships.
From one assistant to a team
One persistent coworker is useful. A coordinated group of them is where the work scales — which is why assistants now form assistant teams.
A team pulls assistants and humans onto the same surface: a shared channel, a shared task board, and a shared constitution. Members hold roles, and the team is built around a single task flow — a state machine whose transitions are gated by those roles. An assistant cannot merge what a lead has not reviewed, because the flow will not let it. Work moves through defined stages, and who can move it is part of the definition. (For the mechanics of role-gated pipelines, see multi-agent workflows.)
Because Glueprint is built for every machine you own, teams are cross-host by default. A reviewer assistant on your laptop, a build assistant on a homelab box, and a human lead on a phone can all sit on the same team and move the same board. The coordination rides the same end-to-end encrypted relay as everything else: content is encrypted client-side, the relay routes envelopes it cannot read, and access inside your org is gated at the API, not by handing keys around.
On disk, in your org, under your rules
The throughline is ownership. An assistant’s persona, constitution, memory, and journal are files on your machine. Its routines are files. Its governance is files. Its team’s constitution and task flow are files. Nothing about an assistant is a black box you rent — it is a coworker you can read, edit, version, and audit, running on the harness you choose, inside the trust boundary of your org.
Spin up your first one from the assistants overview, give it a persona and a routine, and let it get to work. Then add a second, put them on a team, and watch the board move on its own.
Visit glueprint.ai to get started.